java reflection issues

[porter]

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]

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]

Did the test - this does appear to be the case. Any thought as to how
this might arise?

 

[Roedy Green]

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

 

[Roedy Green]

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.

 

[porter]

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]

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.