Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / December 2005

Tip: Looking for answers? Try searching our database.

java reflection issues

Thread view: 
porter - 10 Dec 2005 19:17 GMT
Hi,

Could someone help me with this: I'm trying to get 2 applets to talk to
one another via reflection: I have 2 jar archives - one is third party,
the other is mine. The third party archive contains a class derived
from Applet (DerivedApplet say) that contains a public method called
'execute' and a public field called 'viewer'. I can use reflection to
run the execute() method just fine, but trying to use reflection to
gain access to the public field fails

                   // This works fine
                   Method meth =
app.getClass().getMethod("execute",types);
                   meth.invoke(app,new String("set color green"));

                   // But this fails at the cast below
                   Field field = app.getClass().getField("viewer");

                   // This prints out "xxx.Viewer"
                   System.out.println(
field.get(app).getClass().getName() );

                  Object ob = field.get(app);
                   // This throws ClassCastException
                   xxx.Viewer viewer = (xxx.Viewer) ob;

Can anyone see anything wrong? TIA

Jason
Jean-Francois Briere - 10 Dec 2005 20:22 GMT
Maybe that's because the object retreive from reflection, although
being of type xxx.Viewer,
is an instance of a class loaded from another class loader than the one
your applet is
currently using.

A quick test would be:

System.out.println(field.get(app).getClass() == xxx.Viewer.class);

If it returns false, then there is two class loaders involved for
xxx.Viewer.

Regards
porter - 10 Dec 2005 21:00 GMT
Did the test - this does appear to be the case. Any thought as to how
this might arise?
Roedy Green - 10 Dec 2005 21:53 GMT
>Did the test - this does appear to be the case. Any thought as to how
>this might arise?

How the browser works inside is its own business, but consider that
you can't very well recover the RAM from an Applet's static
code/fields unless you load it with a custom class loader.  

Also consider that Applets running on different pages are not supposed
to see each other.  So they should not be sharing common static
fields. I think they would have to be running under different class
loaders.

I have not yet taken the time to poke around to figure out exactly how
the various browsers work vis a vis multiple Applets per page, per
window, with tracking what really happens with destroy and init.

I have discovered I can communicate between Applets on the same page
with  getAppletContext().getApplets(); and just directly calling
methods, all of which appears to happen on the same thread.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

porter - 10 Dec 2005 22:34 GMT
Hi,

Thanks for this - it's quite interesting. My applets are in the same
web page intentionally - the point is that one of them is third party -
I can't change it, but it does expose components of itself in its
Applet A.P.I. which theoretically allow me to interface to it.

As you say above, the class loader issue does not affect you when
calling methods - in my example, the 'Method' based reflection using
invoke worked just fine.

In follow up to the earlier messages I went back and tried tweaking my
applet definitions - If I ensure that the code base and archive
instructions in the applet tags are identical, then the class cast
works fine in firefox. I'll have to try out some other browsers.

Thanks

Jase
porter - 10 Dec 2005 22:53 GMT
Oh yeah - P.S> I havent had to use signed applets to get java
reflection to work - the third party Applet I'm using provides a
reflection based API that allows the extender to add in commands
implemented as classes but called either via a javascript call or by
calling execute() on the Applet . The Applet has no signing in it, but
I've had no problems deploying it as an untrusted applet? I'm only ever
accessing reflection classes from the associated web server, so that
may be why.
Roedy Green - 10 Dec 2005 21:45 GMT
>Could someone help me with this: I'm trying to get 2 applets to talk to
>one another via reflection:

Reflection is not the normal tool for inter-Applet communication.  You
more commonly  use code like this:

for ( Enumeration other = getAppletContext().getApplets(); other
           .hasMoreElements(); )
           {
           Object otherApplet = other.nextElement();
               {
               if ( otherApplet instanceof CurrCon )
                   {
                   CurrCon otherCurrConApplet = (CurrCon)otherApplet;
                   otherCurrConApplet.currencyChangeListener();
                   }
               }
           }
       

Reflection likely requires a signed Applet.  See
http://mindprod.com/jgloss/signedapplets.html
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.