inter-applet communication problems

Thread view:

Eric Capps - 29 Jul 2006 21:46 GMT

I am trying to access the methods of one applet within another applet.
The first applet is Jmol, an open-source molecular modeling tool. A
sample of my code (the second applet) follows:

Applet a = this.getAppletContext().getApplet("jmolApplet0");
JmolAppletInterface ja = (JmolAppletInterface) a;

I have taken a look at a few websites dealing with this topic, and this
is generally the approach they use: getting the applet through the
getApplet() method of AppletContext, then typecasting it to its
appropriate type. The first line works fine for me, and when I debug, I
can see that the applet is obtained and is of the correct type,
JmolApplet. However, when I try to typecast, the code ultimately fails
(I have also tried typecasting as JmolApplet with identical results). I
am debugging from within eclipse, and when I attempt to execute the
second line of code, the debugger pauses in SecureInvocation.CallMethod.
If I step through, it then goes to PriviligedActionException. The cause
and detailMessage of this exception are null, however I notice the
following: java.security.PrivilegedActionException:
java.lang.reflect.InvocationTargetException. Stepping through further
doesn't show me anything interesting.

The Java API for PriviligedActionException hasn't told me anything that
seems helpful. I figure this is some weird issue of scope or something.

Can anyone offer any pointers?

Reply to this Message

Eric Capps - 30 Jul 2006 03:04 GMT

> I am trying to access the methods of one applet within another applet.
> The first applet is Jmol, an open-source molecular modeling tool. A
[quoted text clipped - 23 lines]
> Can anyone offer any pointers?
>

I think that I maybe should have posted this in
comp.lang.java.programmer instead. Rather than multipost, I have
crossposted this message to both groups. I hope that this doesn't cause
any problems.

Reply to this Message

Andrew Thompson - 30 Jul 2006 11:42 GMT

> > I am trying to access the methods of one applet within another applet.
> > The first applet is Jmol, an open-source molecular modeling tool. A
> > sample of my code (the second applet) follows:
> >
> > Applet a = this.getAppletContext().getApplet("jmolApplet0");
> > JmolAppletInterface ja = (JmolAppletInterface) a;

...

> > ...am debugging from within eclipse, and when I attempt to execute the
> > second line of code, the debugger pauses in SecureInvocation.CallMethod.

It sounds like your IDE might be enforcing the type
of 'sand-box' that faces an untrusted applet on the internet.

Where are all your resources (your applet, the
JMol applet, and any data files) coming from?

Better yet, why not drag the project out of the IDE
and put it on the net so we can look at it with our
browsers?

(X-Post continued)

Andrew T.

Reply to this Message

Eric Capps - 30 Jul 2006 17:45 GMT

> It sounds like your IDE might be enforcing the type
> of 'sand-box' that faces an untrusted applet on the internet.

One thing I forgot to mention is that I am not debugging this with
something like the Sun Applet Viewer, I am embedding it in HTML, loading
the page in my web browser, and using eclipse to connect to it & debug
remotely.

> Where are all your resources (your applet, the
> JMol applet, and any data files) coming from?

I'm not sure I understand the question. Could you be a bit more clear?
If you are asking where they are actually physically located, the Jmol
applet is in a .jar file, my applet (the second one embedded in the
page) is in a series of .class files, and both applets and all data
files can be considered to be in the same directory on a webserver.

I think something that may be causing this error is the method by which
I make the code in my applet aware of the code in Jmol, something I'm
doing because I want to call actual Jmol methods from within my applet.
Again, within eclipse: I have downloaded the source for Jmol (I've made
some modifications) and made it into a project in eclipse. The second
applet (mine) is also a separate eclipse project. In this project, I
have added the Jmol project to the build path. This allows me to import
classes declared in Jmol, for example, the JmolApplet class. However I
suspect it may also be responsible for the underlying antisocial
behavior between these applets. Again, both applets are declared
separately through the page, and I "get" the JmolApplet into my applet
with the this.getAppletContext().getApplet("jmolApplet0"); method.

Could this perhaps be responsible?

> Better yet, why not drag the project out of the IDE
> and put it on the net so we can look at it with our
> browsers?

What would help you most? To be able to see the actual execution of the
applet? Or the source, or the HTML that embeds it?

Thank you for your help.

Reply to this Message

Andrew Thompson - 02 Aug 2006 08:30 GMT

> > It sounds like your IDE might be enforcing the type
> > of 'sand-box' that faces an untrusted applet on the internet.
[quoted text clipped - 3 lines]
> the page in my web browser, and using eclipse to connect to it & debug
> remotely.

Thank you. That fills in some details.

> > Where are all your resources (your applet, the
> > JMol applet, and any data files) coming from?
>
> I'm not sure I understand the question. Could you be a bit more clear?

Your answer suggests you made a pretty good guess..

> If you are asking where they are actually physically located,

..or URLs would be superb, but..

>...the Jmol
> applet is in a .jar file, my applet (the second one embedded in the
> page) is in a series of .class files,

...hmm. That is interesting. While I've run plain old
class files in applets off the local disks & the web,
it is not something I'd recommend, as it can lead to
'unexpected' results.

It *might* have something to do with this problem,
though I strongly doubt it.

>..and both applets and all data
> files can be considered to be in the same directory on a webserver.

Yep - OK.

To get to the point you seem to have worked out..

If all the files are effectively 'in the same place', then no
security exception should result. That is apparently
*not* the problem.

> I think something that may be causing this error is the method by which
> I make the code in my applet aware of the code in Jmol, something I'm
> doing because I want to call actual Jmol methods from within my applet.

Maybe..

> Again, within eclipse: I have downloaded the source for Jmol (I've made
> some modifications) and made it into a project in eclipse. The second
> applet (mine) is also a separate eclipse project. In this project, I
> have added the Jmol project to the build path. This allows me to import
> classes declared in Jmol, for example, the JmolApplet class.

There is a little too much faith being placed in the IDE,
for my tastes. For instance, which classpath has precedence,
the one defined within eclipse, or the one defined in the HTML
used to launch the applet? Is that 'applet HTML' generated by
Eclipse - have you examined it?
..

> What would help you most? To be able to see the actual execution of the
> applet? Or the source, or the HTML that embeds it?

An URL that points to a page that embeds the applet and
links to the rest. It would be *best* if..
- the applet does not require acceptance of code signatures
- is a 'small'ish total download.
- the demo code should be as absolutely simple as is
practical to generate the errors you are seeing in eclipse,
make sure it doesn not silently 'swallow' any exceptions,
but instead dump the stack traces.

Here is one I prepared recently to investigate a problem
with dialogs, you might take some pointers off that.
<http://www.physci.org/test/applet/001/>

One of the advantages of putting it up on the net is
that sometimes an applet that fails for you works fine
for others. That can help us figure out what is happening.

Oh, and if your going ahead with putting it up on the net,
can you 'jar' your classes up first? In fact, you might as
well test again locally once you've done that. It probably
is not part of the problem, but then again..

HTH

Andrew T.

Reply to this Message

Eric Capps - 05 Aug 2006 23:11 GMT

>> What would help you most? To be able to see the actual execution of the
>> applet? Or the source, or the HTML that embeds it?
[quoted text clipped - 7 lines]
> make sure it doesn not silently 'swallow' any exceptions,
> but instead dump the stack traces.

Thank you for your reply. I set up a test page that I hope will be
useful here: http://theory.cm.utexas.edu/~eruhk/UsenetTest/test.html

If there is anything lacking from this, please let me know and I will
address it immediately.

I couldn't print a stack trace (this is explained in a bit more detail
on the page, with code). If you have any insight as to why what I tried
failed, it would really help me help you help me.

Cheers,
Eric

Reply to this Message

Andrew Thompson - 06 Aug 2006 00:19 GMT

...

> .. I set up a test page that I hope will be
> useful here: http://theory.cm.utexas.edu/~eruhk/UsenetTest/test.html

Further notes later (probably tomorrow) after I've
had a chance to take a closer look at it, but have
you seen similar to this?
<http://www.physci.org/test/screenshot/>
( the jmol1.png )

> I couldn't print a stack trace (this is explained in a bit more detail
> on the page, with code).

'Let the code do the talking'? Fair enough!

Andrew T.

Reply to this Message

Eric Capps - 06 Aug 2006 01:32 GMT

> Further notes later (probably tomorrow) after I've
> had a chance to take a closer look at it, but have
> you seen similar to this?
> <http://www.physci.org/test/screenshot/>
> ( the jmol1.png )

I have. There are JavaScript alerts that describe the stage things are
in. If you click the button that says "test" after that, you should see
a series of them. The one that indicates that the problem I am having
has been overcome is "succesfully typecast". I have yet to see that.

Again, the problem seems to be when I typecast the object to JmolApplet.

-Eric

Reply to this Message

Andrew Thompson - 06 Aug 2006 08:49 GMT

> > Further notes later (probably tomorrow) after I've
> > had a chance to take a closer look at it, but have
[quoted text clipped - 3 lines]
>
> I have.

OK. I suspected that the model had never appeared
before - wrong again!

What I had sure not expected was the JS to come to 41Kb!
That was somewhat of a shock.

The JS uses browser sniffing rather than 'feature detection'.
This is generally fragile, and not the way best way to write it.
I am toying with throwing my hands up in disgust/defeat
at the sight of that JS..

There are a variety of things that I don't understand about
this process yet. Part of it is why it has one applet loading
another, but mostly about the purpose of the JS.

Did you say this is how 'other' JMol developers do it?
Are there any *working* examples on the net?

Andrew T.

Reply to this Message

Eric Capps - 06 Aug 2006 16:16 GMT

> OK. I suspected that the model had never appeared
> before - wrong again!
[quoted text clipped - 6 lines]
> I am toying with throwing my hands up in disgust/defeat
> at the sight of that JS..

Are you talking about the Jmol-new.js script? Try not to worry about
that, as I don't think it has much to do with my problem.

> There are a variety of things that I don't understand about
> this process yet. Part of it is why it has one applet loading
> another, but mostly about the purpose of the JS.

I don't actually think there is one applet loading another. The Jmol
applet is called into place with a JavaScript command. Or, are you
referring to my applet that is trying to access Jmol methods? If so, I
am doing this because I am trying to address a problem within Jmol - the
inability to handle large (millions of frames) animations effectively.
Jmol handles animations by reading a file that has one "frame" of data
after the other. The model that loaded on the page I sent you is one
model and takes somewhere around 30k if I remember correctly, so you can
imagine how hellish this gets when we are talking, again, about millions
of frames.

I wrote some new methods in the Jmol source to try to handle this
better, but rather than try to fully incorporate my fairly special case
into the code, I opted to make some generally useful methods and then
try to ACCESS them externally. The applet I am writing downloads
information from a server in chunks, does some optimization, and passes
information into the Jmol applet.

> Did you say this is how 'other' JMol developers do it?
> Are there any *working* examples on the net?

I am fairly sure that they do not. From what I can tell, other Jmol
developers usually first build changes into the JavaScript file and then
into the actual Jmol source, or both. I believe the purpose is to make
using Jmol in fairly advanced ways an easier task, and to increase what
you can do with it without getting too deep into the code.

The bottom line: it is possible to call methods in the Jmol applet from
JavaScript (the Jmol-new.js file). It is possible to call those
JavaScript commands from a second applet in the same page (what I have
been doing!) So, shouldn't it be possible to bypass the JavaScript
altogether and call methods from the Jmol applet from the second applet?

I don't think the Jmol-new.js has much to do with this, but if you like
I can highlight parts of it that may be significant and upload them on
that test page.

This email is very long!

Best,
Eric Capps

Reply to this Message

Andrew Thompson - 06 Aug 2006 17:47 GMT

...

> > Did you say this is how 'other' JMol developers do it?
> > Are there any *working* examples on the net?
[quoted text clipped - 7 lines]
> The bottom line: it is possible to call methods in the Jmol applet from
> JavaScript (the Jmol-new.js file).

It would be nice to see an URL where I can confirm
that for myself..

> ...It is possible to call those
> JavaScript commands from a second applet in the same page

Wait a second. Lets make sure we're all
of the same understanding here.

While there are a number of ways to load a second
applet, there is only one applet element in that HTML.

I am not sure if that is what you intended, but performing
this experiment with the second applet element written in
the HTML *might* be a logical first step to what you are
attempting.

>....(what I have
> been doing!)

Without the 'working example', and without a clear
understanding of what you are trying to do (as
we determined earlier), it is still tricky for me to know
what should happen in your example, or what it
looks like when it fails (note that when I first visited the
page, there was no model onscreen - then I clicked
the link to the source file, and when I returned - 'hey
presto' ..the model appeared)

>...So, shouldn't it be possible to bypass the JavaScript
> altogether and call methods from the Jmol applet from the second applet?

I need to become clear on this 'second applet' yet.

Can you set up a test with HTML that includes both applets?

> I don't think the Jmol-new.js has much to do with this, but if you like
> I can highlight parts of it that may be significant and upload them on
> that test page.
>
> This email is very long!

Important note - this is not email, it is a post to a usenet
newsgroup. Email generally
- does not get archived by news servers,
- is not publicly searchable
- does not contribute to the bandwidth of subscribers to this group ;)

..and that makes me aware that we are still x-posting
this to both c.l.j.p. and c.l.j.h. I have set follow-ups to
c.l.j.programmer only.

Andrew T.

Reply to this Message

inter-applet communication problems

Free Magazines