launch applet with APPLET or PLUGIN

[cym tronik]

Hi,
not sure this is the right place for my problem ...

In a web page I use an applet. If I launch the applet in a
HTML file, like this:

<APPLET CODE="myapplet.class" ...>

everything goes well. But if I launch it in a JSP file:

<jsplugin type="applet"
code="myapplet.class"
....>

the Firefox (1.03 and 1.06) says it needs a plug-in. When promted to
look for it, it says it cannot be found. The JSP generated by Tomcat
5.5.9 from the instruction "jsplugin ..." mentions :

<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
width="600" height="420"
codebase="http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2-win.cab#Version=1,2,2,0">

i.e. the latest Java plug-in.

The EMBED part of the generated code for IE works fine, which drives
me mad, I hate IE.

Any idea of what's wrong ?

cymtronik

 

[Andrew Thompson]

In a web page

[1] URL?

..I use an applet. If I launch the applet in a
HTML file, .... everything goes well. But if
I launch it in a JSP file:

<jsplugin type="applet"
code="myapplet.class"
...>

Just before I forget. Why the heck do you not simply
use the applet element? Is there anything specific to
the (invalid) nested OBJECT/EMBED element that you require,
that cannot be specified by the applet element?

the Firefox (1.03 and 1.06) says it needs a plug-in. When promted to
look for it, it says it cannot be found. The JSP generated by Tomcat
5.5.9 from the instruction "jsplugin ..." mentions :

<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
width="600" height="420"
codebase="http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2-win.cab#Version=1,2,2,0">

i.e. the latest Java plug-in.

Err... '1.2.2' I don't see it here..

The EMBED part of the generated code for IE works fine, which drives
me mad, I hate IE.

Ain't it irritating? When the (accursed) IE is the only
one that gets it right.

Any idea of what's wrong ?

Let me start with HTML (the inconsistencies between browser
renderings) applets (generally) Sun's lax attitude to both
HTML and (now) applets.. How much more do you want?

...Had you considered doing this as an application?

 

[cym tronik]

......
Just before I forget. Why the heck do you not simply
use the applet element? Is there anything specific to
the (invalid) nested OBJECT/EMBED element that you require,
that cannot be specified by the applet element?

I may be wrong, but I believe there is a difference between the APPLET
tag and the jsplugin one. The former only makes the browser to load
Java if the browser is not yet Java enabled. If the applet uses newer
version of Java there may be problems. The jsplugin forces the
browser update the Java if necessary.

Err... '1.2.2' I don't see it here..

I have not pasted the whole Tomcat generated file. The codebase=... is
part of the file.

.....
..Had you considered doing this as an application?

It is an applet.

 

[Raymond DeCampo]

I may be wrong, but I believe there is a difference between the APPLET
tag and the jsplugin one. The former only makes the browser to load
Java if the browser is not yet Java enabled. If the applet uses newer
version of Java there may be problems. The jsplugin forces the
browser update the Java if necessary.




I have not pasted the whole Tomcat generated file. The codebase=... is
part of the file.




It is an applet.

I do not see the OP on my news server yet, so forgive me if this is off
base. Are you specifying the JRE version you are targeting? Perhaps
targeting a later version will help.

HTH,
Ray

 

[Andrew Thompson]

I do not see the OP on my news server yet,

Oddly, the OP's posts are coming in dated the 14th,
maybe that is screwing something up. (How long does
your news server retain posts?)

..so forgive me if this is off
base. Are you specifying the JRE version you are targeting?

The above codebase indicates 'Java 1.2.2', *but* the
classid[1] indicates to me that it specifies 'latest
java'. I find that element most confusing.

[1]
<http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/using_tags.html#note_3>

Perhaps it would help to see the complete statement written
in the original JSP that *generates* this HTML.

Actually, it just occured to me the OP specifically said
*Firefox*. Being a Mozilla based browser, it should completely
ignore the <OBJECT> element and would instead need the (invalid)

..Perhaps targeting a later version will help.

1.2.2 is not listed on the page with 'versions available',
they start at 1.3, but the 1.2.2 cab file certainly exists.

Viz.
<http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2-win.cab>

To the OP.
What is the URL of your JSP? This is too slow.

 

[Dag Sunde]

<snipped
..so forgive me if this is off
base. Are you specifying the JRE version you are targeting?

The above codebase indicates 'Java 1.2.2', *but* the
classid[1] indicates to me that it specifies 'latest
java'. I find that element most confusing.

[1]
<http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/using_tags.html#note_3>

The classid indicates what Sun call "Dynamic Versioning", and is used
together
with the codebase attibute.

If Codebase is set to
"...autodl/jinstall-1_4-windows-i586.cab#Version=1,4,0,0"
the client will use any version later than or equal to 1.4.0 If this is not
present,
the latest release of the version indicated in the "Version=xxx" family will
be downloded (ie. at present: 1.4.2_06).

So where I think you misunderstood is that the classId given does *not*
indicate
the 'latest Java', but at least the version given in "Version=" in codebase.
If not
present, the latest version *of that family* (ie. the 1.4 family in my
example).

 

[Andrew Thompson]

On Fri, 19 Aug 2005 14:05:26 GMT, Andrew Thompson


ok, here it is. My jsp file:

<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\">

You do not need a transitional doctype on this web page,
and the leading '\"' is invalid for HTML. I suggest..

<HTML><HEAD><TITLE>JApplet</TITLE></HEAD>
<BODY>

<jsplugin type="applet"
code="ASV_applet.class"
codebase = "/ASV_site"
width="700" height="600">
</jsplugin>

</BODY></HTML>

Which leaves only 11 errors for the undefined
<EMBED>/<NOEMBED>/<COMMENT> elements and the
attributes associated with them.

(This is an irritation for me, as I usually like to
validate HTML before proceeding, but it is impossible
when using the nested <OBJECT>/<EMBED> structure.)

OK.. I've changed the parameters, so I'll trim the rest
of your 'what Tomcat said'...

The above .JSP produces (in my tomcat)..

***
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML><HEAD><TITLE>JApplet</TITLE></HEAD>
<BODY>
<div>
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="700"
height="600"
codebase="http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2-win.cab#Version=1,2,2,0">
<PARAM name="java_code" value="ASV_applet.class">
<PARAM name="java_codebase" value="/ASV_site">
<PARAM name="type" value="application/x-java-applet;">
<COMMENT>
<EMBED type="application/x-java-applet;" width="700" height="600"
pluginspage="http://java.sun.com/products/plugin/"
java_code="ASV_applet.class" java_codebase="/ASV_site"<NOEMBED>
</COMMENT>
</NOEMBED></EMBED>
</OBJECT>

</div>
</BODY></HTML>
***

That HTML prompted me to install the plug-in, but I
chose to ingore/cancel it, since I use 1.5 Java in Mozilla

I assume that mimics the behaviour you are seeing in FireFox?

...I saw a suspicious character in that output and removed
it, to produce this (note: *1* character different)..
***
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML><HEAD><TITLE>JApplet</TITLE></HEAD>
<BODY>
<div>
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="700"
height="600"
codebase="http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2-win.cab#Version=1,2,2,0">
<PARAM name="java_code" value="ASV_applet.class">
<PARAM name="java_codebase" value="/ASV_site">
<PARAM name="type" value="application/x-java-applet;">
<COMMENT>
<EMBED type="application/x-java-applet" width="700" height="600"
pluginspage="http://java.sun.com/products/plugin/"
java_code="ASV_applet.class" java_codebase="/ASV_site"<NOEMBED>
</COMMENT>
</NOEMBED></EMBED>
</OBJECT>

</div>
</BODY></HTML>
***

Here, that second HTML produce an NPE when the browser
could not find the class.

Try it in your FireFox.

Ray.. do you still wonder why I avoid using the 'easy'
'<jsplugin' way of placing applets in pages?
Sun seems to not have the first clue when it comes to
...about everything related to HTML and JavaScript, I
would prefer to rely on the applet element.

 

[cym tronik]

Thanks Andrew,
you've put me on the track. Your version of Tomcat is different of
mine, your _working_ file:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML><HEAD><TITLE>JApplet</TITLE></HEAD>
<BODY>
<div>
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="700"
height="600"
codebase="http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2-win.cab#Version=1,2,2,0">
<PARAM name="java_code" value="ASV_applet.class">
<PARAM name="java_codebase" value="/ASV_site">
<PARAM name="type" value="application/x-java-applet;">
<COMMENT>
<EMBED type="application/x-java-applet;" width="700" height="600"
pluginspage="http://java.sun.com/products/plugin/"
java_code="ASV_applet.class" java_codebase="/ASV_site"
<NOEMBED>
</COMMENT>
</NOEMBED></EMBED>
</OBJECT>

</div>
</BODY></HTML>

fails in my Firefox, but the next one, with the suspicious semicolon
in <EMBED removed:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML><HEAD><TITLE>JApplet</TITLE></HEAD>
<BODY>
<div>
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="700"
height="600"
codebase="http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2-win.cab#Version=1,2,2,0">
<PARAM name="java_code" value="ASV_applet.class">
<PARAM name="java_codebase" value="/ASV_site">
<PARAM name="type" value="application/x-java-applet;">
<COMMENT>
<EMBED type="application/x-java-applet" width="700" height="600"
pluginspage="http://java.sun.com/products/plugin/"
java_code="ASV_applet.class" java_codebase="/ASV_site"
<NOEMBED>
</COMMENT>
</NOEMBED></EMBED>
</OBJECT>

</div>
</BODY></HTML>

works fine. Now I have something to report to the Tomcat people.

Regards

Cym

 

[Andrew Thompson]

Thanks Andrew,
you've put me on the track. Your version of Tomcat is different of
mine, your _working_ file: .... ....
fails in my Firefox, but the next one, with the suspicious semicolon
in <EMBED removed: ... ...
works fine. Now I have something to report to the Tomcat people.

I don't think it is quite that straightforward.
This is the first time I have looked closely at the
output of the <jsplugin statement, generally I use
the <APPLET> element.

After poking further into the jsplugin element at
the bug database, I realised why the ';' is there
(docs may also have indicated, but..) for a reason.
Look at these bugs, and notice that after the semi-colon
is a 'version=n.n.n'.

<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4823518>
...
type="application/x-java-applet;version=1.4.1_01"

<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4870461>
...
type="application/x-java-applet;version=1.3.1"

Maybe Ray 'hit the nail on the head' for the solution..
Specify a version later than 1.2.2 and the plugin element
will most likely complete that attribute with a sensible value.

OTOH, the absence of ..
type="application/x-java-applet;version=1.2.2"
...does seem like a bug (to me).

 

[cym tronik]

...
After poking further into the jsplugin element at
the bug database, I realised why the ';' is there
(docs may also have indicated, but..) for a reason.
Look at these bugs, and notice that after the semi-colon
is a 'version=n.n.n'.

I've tried the version attribute, I've even pasted an example from
Sun's tutorial page, and it does not work. I've tried space, slash,
dollar instead of this semicolon, no better. I think it is a bug, yes.

Cym

 

[cym tronik]

Got it!!!

here is my working line line:
type="application/x-java-applet;version=1.5"

you notice that only the major and minor version numbers are
specified. Weird. Contradicts Sun's hints at:

http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/using_tags.html#html

 

[Raymond DeCampo]

You do not need a transitional doctype on this web page,
and the leading '\"' is invalid for HTML. I suggest..










Which leaves only 11 errors for the undefined
<EMBED>/<NOEMBED>/<COMMENT> elements and the
attributes associated with them.

(This is an irritation for me, as I usually like to
validate HTML before proceeding, but it is impossible
when using the nested <OBJECT>/<EMBED> structure.)

OK.. I've changed the parameters, so I'll trim the rest
of your 'what Tomcat said'...

The above .JSP produces (in my tomcat)..

***
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML><HEAD><TITLE>JApplet</TITLE></HEAD>
<BODY>
<div>
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="700"
height="600"
codebase="http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2-win.cab#Version=1,2,2,0">
<PARAM name="java_code" value="ASV_applet.class">
<PARAM name="java_codebase" value="/ASV_site">
<PARAM name="type" value="application/x-java-applet;">
<COMMENT>
<EMBED type="application/x-java-applet;" width="700" height="600"
pluginspage="http://java.sun.com/products/plugin/"
java_code="ASV_applet.class" java_codebase="/ASV_site"

<NOEMBED>
</COMMENT>
</NOEMBED></EMBED>
</OBJECT>

</div>
</BODY></HTML>
***

That HTML prompted me to install the plug-in, but I
chose to ingore/cancel it, since I use 1.5 Java in Mozilla

I assume that mimics the behaviour you are seeing in FireFox?

..I saw a suspicious character in that output and removed
it, to produce this (note: *1* character different)..
***
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML><HEAD><TITLE>JApplet</TITLE></HEAD>
<BODY>
<div>
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="700"
height="600"
codebase="http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2-win.cab#Version=1,2,2,0">
<PARAM name="java_code" value="ASV_applet.class">
<PARAM name="java_codebase" value="/ASV_site">
<PARAM name="type" value="application/x-java-applet;">
<COMMENT>
<EMBED type="application/x-java-applet" width="700" height="600"
pluginspage="http://java.sun.com/products/plugin/"
java_code="ASV_applet.class" java_codebase="/ASV_site"

<NOEMBED>
</COMMENT>
</NOEMBED></EMBED>
</OBJECT>

</div>
</BODY></HTML>
***

Here, that second HTML produce an NPE when the browser
could not find the class.

Try it in your FireFox.

Ray.. do you still wonder why I avoid using the 'easy'
'<jsplugin' way of placing applets in pages?
Sun seems to not have the first clue when it comes to
..about everything related to HTML and JavaScript, I
would prefer to rely on the applet element.

Yes, I do wonder. I have never had any issues with <jsplugin> myself.
You didn't indicate which character you changed above so i couldn't be
bothered to diff it myself.

Using <jsplugin> is a double edged sword. First, the responsibility
of getting it to work is not mine. So there is a group of people out
there working on it without taking any effort from me. OTOH, if it is
broken, I am at the mercy of others to get it fixed. So far, I haven't
had a problem with it, as I said above. Also, it's not as if I deal
with a billion applets; only two so far.

FWIW, I think that <jsplugin> is actually implemented by the J2EE
application server. (I could be wrong about this.)

Ray

 

[Andrew Thompson]

Andrew Thompson wrote:

Yes, I do wonder. I have never had any issues with <jsplugin> myself.
You didn't indicate which character you changed above so i couldn't be
bothered to diff it myself.

I removed the ';' from the embed 'type' attribute. You
can probably see it more clearly here..
<http://groups.google.com.au/group/comp.lang.java.programmer/msg/42e05d90de82a3fe>

[ I also suspect these posts are getting through to you
rather later to me. Do you see those posts at Google? ]

Using <jsplugin> is a double edged sword. First, the responsibility
of getting it to work is not mine. So there is a group of people out
there working on it without taking any effort from me. OTOH, if it is
broken, I am at the mercy of others to get it fixed. So far, I haven't
had a problem with it, as I said above. Also, it's not as if I deal
with a billion applets; only two so far.

FWIW, I think that <jsplugin> is actually implemented by the J2EE
application server. (I could be wrong about this.)

Do you usually specify the Java version?

Do you know the pages to work in Mozilla browsers?
Or (perhaps relevant), do Mozilla browsers ever access
those two pages/applets you refer to?

 

[Raymond DeCampo]

Andrew Thompson wrote:


Yes, I do wonder. I have never had any issues with <jsplugin> myself.
You didn't indicate which character you changed above so i couldn't be
bothered to diff it myself.

I removed the ';' from the embed 'type' attribute. You
can probably see it more clearly here..
<http://groups.google.com.au/group/comp.lang.java.programmer/msg/42e05d90de82a3fe>

[ I also suspect these posts are getting through to you
rather later to me. Do you see those posts at Google? ]

Do you usually specify the Java version?

Yes; actually, s/usually/always

Do you know the pages to work in Mozilla browsers?
Or (perhaps relevant), do Mozilla browsers ever access
those two pages/applets you refer to?

Yes, the applets work on Mozilla and Netscape. I think I have tested
one of them on FireFox as well.

Ray

 

[Roedy Green]

<jsplugin type="applet"
code="ASV_applet.class"
codebase = "/ASV_site"
width="700" height="600">

I would want to see what the final page looks like, and check out
various browsers to see what they think of it when fed to them from a
local hard disk. Tweak the HTML till your browsers are happy, then
tweak the JSP to match.

I don't like the idea of Applets not contained in jars. They are ever
so much more troublesome.

 

[cym tronik]

I would want to see what the final page looks like, and check out
various browsers to see what they think of it when fed to them from a
local hard disk. Tweak the HTML till your browsers are happy, then
tweak the JSP to match.

I don't like the idea of Applets not contained in jars. They are ever
so much more troublesome.

here it is:

<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\">
<HTML><HEAD><TITLE>JApplet</TITLE></HEAD>
<BODY>
<jsplugin type="applet"
code="ASV_applet.class"
codebase = "/ASV_site"
width="700" height="600">
</jsplugin>
</BODY></HTML>


which is translated by Tomcat 5.5.9 to:


<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\">
<HTML><HEAD><TITLE>JApplet</TITLE></HEAD>
<BODY>
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
width="700" height="600"
codebase="http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2-win.cab#Version=1,2,2,0">
<PARAM name="java_code" value="ASV_applet.class">
<PARAM name="java_codebase" value="/ASV_site">
<PARAM name="type" value="application/x-java-applet;">
<COMMENT>
<EMBED type="application/x-java-applet;" width="700" height="600"
pluginspage="http://java.sun.com/products/plugin/"
java_code="ASV_applet.class" java_codebase="/ASV_site"/>
<NOEMBED>
</NOEMBED>
</COMMENT>
</OBJECT>
</BODY></HTML>

The problems is the ";" in <EMBED type="application/x-java-applet;"

It seems to be a Tomcat bug. The file works either without the ";" or
with :

<EMBED type="application/x-java-applet;version=1.5"

but not with :

<EMBED type="application/x-java-applet;version=1.5.o"

as the Sun tutorial specifies. I'm new to this and rather disapointed
by the JSP.

Cym

 

[Roedy Green]

<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
width="700" height="600"
codebase="http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2-win.cab#Version=1,2,2,0">

I think others have already tackled your problem. and found it was a
bug in Firefox digesting the ; in this crap. I can't believe someone
would willfully compose an interface this ugly, not even Microsoft.
How did something so disgusting ever see the light of day?

This clsid stuff is surely windows specific and the win.cab similarly.
An interface to Java should be platform independent.

I feel this sort of thing has to be boycotted on extreme aesthetic
grounds. It is just too ugly to use.

Look at the minute fraction of that crud having any information
content in the SHannon sense. <applet was disgusting enough. This is
preposterous.

 

[Andrew Thompson]

The problems is the ";" in <EMBED type="application/x-java-applet;"

It seems to be a Tomcat bug. The file works either without the ";" or
with :

<EMBED type="application/x-java-applet;version=1.5" ...
...I'm new to this and rather disapointed by the JSP.

?!? Applets are no easy matter to deploy.

But I feel you have missed something important here..
I will quote Raymond DeCampo from an earlier post
to this thread.

"..Are you specifying the JRE version you are targeting?
Perhaps targeting a later version will help."

You have found that exact advice fixes the problem, which
leads me to.. why *aren't* you specifying a version?

Very few Java developers would dare risk running Swing
using Java 1.2*, but would probably specify 1.4 as the
minimum Java required. * Though the Swing classes were
incorporated in the 1.2 core classes, a lot of them had
quirky bugs, as I understand.

As an aside, I would be interested in seeing a link to
any bug report you lodge. I would not be the slightest
bit surprised if the 'closed - not a bug' explanation is
'Developer should specify a version'.

 

[Andrew Thompson]

<EMBED ... ....
...I'm new to this and rather disapointed by the JSP.

I have just identified another source of my irritation
at that statement.

If you want to 'blame' anybody for this mess, put the
blame where it belongs, Mozilla. It is the Mozilla
family of browsers that introduced the <EMBED> element.

Despite the common acceptance of the <OBJECT> element
(including by the W3C, the HTML recommendation group
that decides what will, and will not, be considered
valid HTML), Mozilla is still pushing this idiotic
structure some.. 6, 7(?) years after it should have
been considered a lost battle.

The Mozilla family of browsers are generally good
user agents, but that aspect of them, irk's me no end.

--
Andrew Thompson
physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
"You can blow out a candle, but you can't blow out a fire. Once the flame
begin to catch, the wind will blow it higher."
Peter Gabriel 'Biko'

 

[Roedy Green]

Very few Java developers would dare risk running Swing
using Java 1.2*, but would probably specify 1.4 as the
minimum Java required. * Though the Swing classes were
incorporated in the 1.2 core classes, a lot of them had
quirky bugs, as I understand.

With 1.2 Swing was not part of the distribution, but you could add
your own jar if you wanted to experiment.

With 1.3 Swing was included as part of the distribution. I consider
this the official advent of Swing.

It would be interesting to do a frequency distribution of JREs out in
the universe. I wonder if we often are going to tremendous work with
backward compatibility for people who use nothing but email and porn
viewing anyway.