Skip to main content

NoClassDefFoundError: javax/media/jai/OperationRegistrySpi

23 replies [Last post]
russelleast
Offline
Joined: 2004-01-09

Getting an odd error in the following rather special situation. It's really related to JAI, but only happens when JAI ImageIO is installed locally.

Our app requires JAI, and we provide it as either applet or via WebStart. In some of our doc, we recommend optionally installing JAI ImageIO for improved performance, but for the WebStart app we don't require installing JAI, since it comes across as a WebStart extension in this case.

Following is the exception we see if an end-user has JAI ImageIO locally installed in their JRE, but not JAI, on the first attempt to access the JAI class. JAI *should* be available via the WebStart extension mechanism, but I'm just guessing there might be some kind of security issue related to differing ClassLoader's???

java.lang.NoClassDefFoundError: javax/media/jai/OperationRegistrySpi
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at com.sun.media.jai.util.Service$LazyIterator.next(Service.java:267)
at javax.media.jai.OperationRegistry.registerServices(OperationRegistry.java:2047)
at javax.media.jai.ThreadSafeOperationRegistry.registerServices(ThreadSafeOperationRegistry.java:612)
at javax.media.jai.OperationRegistry.initializeRegistry(OperationRegistry.java:365)
at javax.media.jai.JAI.(JAI.java:560)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)

... our code is doing Class.forName("javax.media.jai.JAI") in order to test that the correct version of JAI is available.

Happens on Windows and Linux (at least, and probably Sun as well) for JAI 1.1.3, JAI ImageIO 1.1.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Nidel, Mike

Is it possible for us to answer the underlying question about
classloaders?

We have never seen this problem specifically, because we require our
users
to install JAI, and give them the option of installing JAI ImageIO
tools.
We are typically in a non-internet-connected environment and thus aren't
able to point to a WebStart extension installer. Therefore if we DID run
into such a problem, that solution wouldn't help us.

The problem seems to be that libraries installed in lib/ext have tighter
access restrictions than those in the core JRE, from a classloader
perspective.
This indicates to me that a separate, secured classloader is used for
lib/ext,
without visibility to the application classloader. What's puzzling to me
is
that this would have to affect any JAI plugins (e.g.
OperationRegistrySpi)
that are loaded from the application's classpath (rather than from
lib/ext).
We don't use this particular behavior so we've never run into a problem.

Obviously classes loaded from the core JRE (e.g. rt.jar) do not have the
same security restrictions; otherwise the entire ImageIO framework would
be badly broken.

does anyone have any thoughts on how the classloaders are divided? Is it
different in WebStart from a normal invocation of the java or javaw
commands?
Is there a complex classloader hierarchy?

Perhaps there's documentation on the JVM behavior somewhere but I
haven't
been tenacious enough to track it down.

Mike

> -----Original Message-----
> From: Brian.Burkhalter@Sun.COM [mailto:Brian.Burkhalter@Sun.COM]
> Sent: Monday, June 04, 2007 7:06 PM
> To: interest@jai-imageio.dev.java.net
> Subject: Re: RE: RE: RE: [JAI-IMAGEIO] Re: NoClassDefFoundError:
>
> Well unless someone comes up with a better idea the most
> likely near term solution would be for us to get it in gear
> and provide jai-imageio webstart bundles as well ...
>
> On Mon, 4 Jun 2007, jai-imageio@javadesktop.org wrote:
>
> >> So you are using the JAI webstart bundles hosted on java.net?
> >
> > yup!
> > [Message sent by forum member 'russelleast' (russelleast)]
> >
> > http://forums.java.net/jive/thread.jspa?messageID=220449
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> interest-unsubscribe@jai-imageio.dev.java.net
> > For additional commands, e-mail:
> > interest-help@jai-imageio.dev.java.net
> >
> >
>
> ----------------
> Brian Burkhalter
> Java Media, Imaging, and Graphics
> Sun Microsystems, Inc.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged
> information. Any unauthorized review, use, disclosure or
> distribution is prohibited.
> If you are not the intended recipient, please contact the
> sender by reply email and destroy all copies of the original message.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail:
> interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

russelleast
Offline
Joined: 2004-01-09

> When you do a Class.forName() are you calling it just
> like that, or are you doing
> SomeAppClass.class.forName()

I am doing Class.forName("path.of.class")

> Do my theories make any sense?

it'll be interesting to see the outcome. The application I am writing uses SPI-style plugins. They've worked well so far, but this ClassLoader difference might become a limiting factor.

Nidel, Mike

I realized my original question about Class.forName() didn't really have
a point. Sorry for the diversion. One thing I should have asked and
which you may have already explained: does this error break your
application?

I think it is exactly the SPI-style plugins that are killing your app --
however, not necessarily your own but the ones that are in JAI ImageIO
Tools. We have seen this kind of thing numerous times because of
reflection that is used by plugin lookup. For my team, it's mainly
happened in a J2EE app container because of the security boundaries they
put on classloaders. It seems logical to me that WebStart might do
something similar. What would be an interesting test would be to run
your app from the command line (no WebStart), with JAI ImageIO Tools on
the system classpath and JAI on your app's own classpath.

I've just spent some time formulating a theory with a coworker as to the
cause of the problem, and I think I can guess pretty closely as to what
it is.

In the configuration that is causing you problems, you have ImageIO
Tools in the JRE lib/ext directory, and JAI in your application. Let's
guess that there are separate classloader pools for these two sets of
libraries, and there is a one-way classloader reference relationship
between them. The result is that classes in your app can "see"
(load/reference/use) classes in the JRE. But the core JRE classes
(including lib/ext) are loaded in such a way that they cannot see your
application's classes. Let's call these the app classloader (ACL) and
JRE classloader (JCL) just for simplicity.

In terms of legal references, you have the following:

ACL -> JCL: yes
JCL -> ACL: no
and of course
ACL -> ACL: yes
JCL -> JCL: yes

Now in this configuration, you do Class.forName("...JAI"). From your
original stack trace, this successfully makes it into the JAI static
initializer, because your class is in the ACL and can see JAI (also in
the ACL). During static initialization of the JAI class, it sets up the
OperationRegistry. This results in a SPI-type lookup (remember what I
said at the beginning about plugins). If you look in the JAI ImageIO
Tools jai_imageio.jar under META-INF/services, you'll see a descriptor
file for OperationRegistrySpi. This references the class
com.sun.media.jai.imageioimpl.ImageReadWriteSpi (part of JAI ImageIO
Tools of course). This provides the JAI "imageread" and "imagewrite"
operators.

So now, during the static initialization of the JAI class, we have
started to load the JAI ImageIO Tools code, _which is in the JCL_
(because of the fact that JAI IIO Tools is in the JRE). In a sense,
classloader control has moved from the ACL to the JCL. Now under the
JCL, the ImageReadWriteSpi class is being initialized. But as you might
have guessed, this class implements the OperationRegistrySpi interface,
which is a JAI interface. This means you have a hidden dependency BACK
from the JCL to the ACL. If you accept my proposal that the classloaders
in WebStart are set up in such a way that this is not permitted, then
you will see why you get this error: because classes loaded from the JCL
cannot "see" classes in the ACL. This is a security constraint, I can't
necessarily explain the reasoning but I've seen this kind of problem
before in non-WebStart environments and I think the logic of my
explanation holds tight. (it's worth noting that your stack trace does
go through the SecurityManager, by the way.)

As far as I can tell, the only symptom you should see of this problem is
that the ImageWrite and ImageRead operations provided in JAI IIO Tools
won't work. This is why I asked above if your application breaks when
you see this error, or if it's just a stack trace on the console, or
what.

As far as what to do about it... the picture is pretty bleak. I don't
think you'll get the behavior of classloaders to change any time this
decade (and arguably the classloader is doing the right thing). The most
I can say is that you have to instruct your users either to install both
JAI and JAI ImageIO Tools, or neither. There MIGHT be something the JAI
IIO Tools team could do to make the system more robust to this kind of
failure, but that seems to be about it.

Without knowing the real behavior of the WebStart classloader hierarchy,
I've made some assumptions here that could be wrong. But the evidence
seems to bear them out. If anyone has any more input, feel free to throw
it in the ring.

Mike

> -----Original Message-----
> From: jai-imageio@javadesktop.org
> [mailto:jai-imageio@javadesktop.org]
> Sent: Sunday, June 03, 2007 12:12 PM
> To: interest@jai-imageio.dev.java.net
> Subject: Re: RE: [JAI-IMAGEIO] Re: NoClassDefFoundError:
>
> > When you do a Class.forName() are you calling it just like that, or
> > are you doing
> > SomeAppClass.class.forName()
>
> I am doing Class.forName("path.of.class")
>
> > Do my theories make any sense?
>
> it'll be interesting to see the outcome. The application I
> am writing uses SPI-style plugins. They've worked well so
> far, but this ClassLoader difference might become a limiting factor.
> [Message sent by forum member 'russelleast' (russelleast)]
>
> http://forums.java.net/jive/thread.jspa?messageID=220261
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail:
> interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

russelleast
Offline
Joined: 2004-01-09

> I realized my original question about Class.forName() didn't really have
> a point. Sorry for the diversion.

no problem here. :-)

> One thing I should have asked and
> which you may have already explained: does this error
> break your application?

well yes, from the point of view that we are trying to provide an app that works in either Web Start or applet environments. We don't really need ImageIO, but we mention it as an optional enhancement. But, the only way for end-users to get it currently is to install it. At that point, we don't know whether the end-user plans on using Web Start or applet.

Once they try running our app, our code firstly goes out and checks what is available and complains if something is missing or the wrong version, and won't start the app until they fix it. In this strange case, we didn't get to that point because of the Error, but, now that I know about it, I modified the above test code to catch it and display an appropriate message. From this point of view, you could say that nothing is "broken", because there is a simple workaround - either install both or neither.

> What would be an interesting test would be to run
> your app from the command line (no WebStart), with
> JAI ImageIO Tools on the system classpath and
> JAI on your app's own classpath.

I'm out of time to try this, but I suspect there won't be a problem, as the ClassLoaders involved won't be downloading from a web site - I think that is likely to be the sticking point and causing security red-flags.

> As far as I can tell, the only symptom you should see of this problem is
> that the ImageWrite and ImageRead operations provided in JAI IIO Tools
> won't work. This is why I asked above if your application breaks when
> you see this error, or if it's just a stack trace on the console, or what.

Well, if we didn't have the code to check versions and existence of required packages, I think what is likely to happen is, the first time we do anything, a static load of JAI will occur, and exactly the same problem is likely to occur, just at a different point in our code.

> The most I can say is that you have to instruct your users
> either to install both JAI and JAI ImageIO Tools, or neither.

exactly!

> There MIGHT be something the JAI IIO Tools team could do to make the system more
> robust to this kind of failure, but that seems to be about it.

Actually, there *is* something the JAI IIO folks could do for us. The problem as I see it is, we have to tell folks who want to use Web Start apps to install IIO. But, it would be much cooler if there was an IIO Web Start extension available. I think I requested this once, but can't find is an issue logged anywhere - maybe I'm just dreaming. ;-)

Nidel, Mike

> But, the only way for
> end-users to get it currently is to install it. At that
> point, we don't know whether the end-user plans on using Web
> Start or applet.

...

> Actually, there *is* something the JAI IIO folks could do for
> us. The problem as I see it is, we have to tell folks who
> want to use Web Start apps to install IIO. But, it would be
> much cooler if there was an IIO Web Start extension
> available. I think I requested this once, but can't find is
> an issue logged anywhere - maybe I'm just dreaming. ;-)

Why couldn't you just bundle the JARS with your app? This shouldn't
violate the license, and in the case where you want to run your
app without an internet connection it is necessary. So you could
package the jai_imageio.jar and clibwrapper_jiio.jar along with
the native libs (in a jar file) and deploy that via webstart.

This doesn't mean the webstart extension is not useful, just that
it doesn't suffice in all cases.

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

russelleast
Offline
Joined: 2004-01-09

> Why couldn't you just bundle the JARS with your app? This shouldn't
> violate the license, and in the case where you want to run your
> app without an internet connection it is necessary.

Internet connection is required to run our app - all the data is online.

> So you could package the jai_imageio.jar and clibwrapper_jiio.jar along with
> the native libs (in a jar file) and deploy that via webstart.

Nice if Sun can do this - they do it for JAI already. It makes sense that the people who maintain and upgrade it should expose it. I take your point though - if I really want it, I can roll my own. :-)

bpb
Offline
Joined: 2004-06-23

> > So you could package the jai_imageio.jar and
> clibwrapper_jiio.jar along with
> > the native libs (in a jar file) and deploy that via
> webstart.
>
> Nice if Sun can do this - they do it for JAI already.

So you are using the JAI webstart bundles hosted on java.net?

> It makes sense that the people who maintain and
> upgrade it should expose it. I take your point
> though - if I really want it, I can roll my own. :-)

russelleast
Offline
Joined: 2004-01-09

> So you are using the JAI webstart bundles hosted on java.net?

yup!

Brian Burkhalter

Well unless someone comes up with a better idea the most likely near term
solution would be for us to get it in gear and provide jai-imageio webstart
bundles as well ...

On Mon, 4 Jun 2007, jai-imageio@javadesktop.org wrote:

>> So you are using the JAI webstart bundles hosted on java.net?
>
> yup!
> [Message sent by forum member 'russelleast' (russelleast)]
>
> http://forums.java.net/jive/thread.jspa?messageID=220449
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>

----------------
Brian Burkhalter
Java Media, Imaging, and Graphics
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

russelleast
Offline
Joined: 2004-01-09

Sounds good!

Brian Burkhalter

On Thu, 31 May 2007, jai-imageio@javadesktop.org wrote:

> I can't tell if the app and JAI are loaded into the cache, although it seems like they are, since, after I re-installed JAI locally, and tried starting warpdemo it started without downloading anything.

If you fire up 'javaws' you should be able to see the cache contents.

> On the other hand (nothing to do with my issue) when both are installed locally, I do get another exception and the WarpDemo won't start, with this message: "the_nut.tif": File not found

I am not going to worry about that for now.

----------------
Brian Burkhalter
Java Media, Imaging, and Graphics
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

russelleast
Offline
Joined: 2004-01-09

yes indeed, they are located in the cache.

bpb
Offline
Joined: 2004-06-23

OK, so the problem lies in the execution of the application, not in the installation of the required files by WebStart. I have asked for assistance from some others who know this technology better than I.

> yes indeed, they are located in the cache.

Nidel, Mike

My guess is that Webstart is placing the core libraries installed in the
JRE
into a different classloader than the application libraries. The JRE
classloader
can't "see" classes or other resources from the application. If you look
back
at your stack trace in the original message you'll see a bunch of
ClassLoader stuff
in the middle, which you correctly suspected to be part of the issue.
But this
is still pretty mysterious.

When you do a Class.forName() are you calling it just like that, or are
you doing

SomeAppClass.class.forName()

or what?

If you look near the bottom of the stack trace, it's obviously finding
JAI classes,
so here is what I think is happening:

1. You call Class.forName() on the JAI class which causes it to be
initialized.
2. This results in registering all the services, including the
definition of those
services/operators that are included in JAI ImageIO Tools, e.g.
ImageRead/ImageWrite.
3. When THOSE JAI ImageIO Tools services are referenced, they reference
back to
JAI classes. But since they are in the JRE classloader, and if my theory
above about
the Webstart app loader is right, they cannot see the JAI classes which
are in the
application classloader pool.

This issue or related ones (specifically with J2EE app containers like
Tomcat and
Weblogic) have been very painful for us when dealing particularly with
dynamically
registered services such as ImageIO reader/writer plugins etc. In my
opinion, the
JAI extension needs to be installed into the system/JRE classloader
rather than the
application classloader, which MIGHT solve your problem. But then if you
publish any
services/plugins/operators to JAI, you might not see them load correctly
due to the
same issue.

Do my theories make any sense?

Mike

> -----Original Message-----
> From: jai-imageio@javadesktop.org
> [mailto:jai-imageio@javadesktop.org]
> Sent: Thursday, May 31, 2007 8:57 PM
> To: interest@jai-imageio.dev.java.net
> Subject: Re: [JAI-IMAGEIO] Re: NoClassDefFoundError:
>
> javax/media/jai/OperationRegis
> In-Reply-To:
> <5024156.136381180658259620.JavaMail.tomcat@sdcst12.sjc.collab.net>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 7bit
>
> OK, so the problem lies in the execution of the application,
> not in the installation of the required files by WebStart. I
> have asked for assistance from some others who know this
> technology better than I.
>
> > yes indeed, they are located in the cache.
> [Message sent by forum member 'bpb' (bpb)]
>
> http://forums.java.net/jive/thread.jspa?messageID=219842
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail:
> interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

bpb
Offline
Joined: 2004-06-23

I think you are not far off the mark. We are going to discuss this further here next week.

> My guess is that Webstart is placing the core
> libraries installed in the
> JRE
> into a different classloader than the application
> libraries. The JRE
> classloader
> can't "see" classes or other resources from the
> application. If you look
> back
> at your stack trace in the original message you'll
> see a bunch of
> ClassLoader stuff
> in the middle, which you correctly suspected to be
> part of the issue.
> But this
> is still pretty mysterious.
>
> When you do a Class.forName() are you calling it just
> like that, or are
> you doing
>
> SomeAppClass.class.forName()
>
> or what?
>
> If you look near the bottom of the stack trace, it's
> obviously finding
> JAI classes,
> so here is what I think is happening:
>
> 1. You call Class.forName() on the JAI class which
> causes it to be
> initialized.
> 2. This results in registering all the services,
> including the
> definition of those
> services/operators that are included in JAI ImageIO
> Tools, e.g.
> ImageRead/ImageWrite.
> 3. When THOSE JAI ImageIO Tools services are
> referenced, they reference
> back to
> JAI classes. But since they are in the JRE
> classloader, and if my theory
> above about
> the Webstart app loader is right, they cannot see the
> JAI classes which
> are in the
> application classloader pool.
>
> This issue or related ones (specifically with J2EE
> app containers like
> Tomcat and
> Weblogic) have been very painful for us when dealing
> particularly with
> dynamically
> registered services such as ImageIO reader/writer
> plugins etc. In my
> opinion, the
> JAI extension needs to be installed into the
> system/JRE classloader
> rather than the
> application classloader, which MIGHT solve your
> problem. But then if you
> publish any
> services/plugins/operators to JAI, you might not see
> them load correctly
> due to the
> same issue.
>
>
> Do my theories make any sense?
>
> Mike
>
> > -----Original Message-----
> > From: jai-imageio@javadesktop.org
> > [mailto:jai-imageio@javadesktop.org]
> > Sent: Thursday, May 31, 2007 8:57 PM
> > To: interest@jai-imageio.dev.java.net
> > Subject: Re: [JAI-IMAGEIO] Re:
> NoClassDefFoundError:
> >
> > javax/media/jai/OperationRegis
> > In-Reply-To:
> >
> <5024156.136381180658259620.JavaMail.tomcat@sdcst12.sj
> c.collab.net>
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 7bit
> >
> > OK, so the problem lies in the execution of the
> application,
> > not in the installation of the required files by
> WebStart. I
> > have asked for assistance from some others who know
> this
> > technology better than I.
> >
> > > yes indeed, they are located in the cache.
> > [Message sent by forum member 'bpb' (bpb)]
> >
> >
> http://forums.java.net/jive/thread.jspa?messageID=2198
> 42
> >
> >
> ------------------------------------------------------
> ---------------
> > To unsubscribe, e-mail:
> interest-unsubscribe@jai-imageio.dev.java.net
> > For additional commands, e-mail:
> > interest-help@jai-imageio.dev.java.net
> >
> >
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail:
> interest-help@jai-imageio.dev.java.net

russelleast
Offline
Joined: 2004-01-09

> > So to be clear, the only time you see a problem is
> > when JAI Image I/O is already installed locally in
> > the JRE and the user installs your application via
> > the WebStart mechanism?
>
> Yes.

If both JAI and ImageIO are installed locally, it works

If JAI is installed, but not ImageIO, still works

If neither JAI nor ImageIO are installed, still works

If ImageIO is installed, but not JAI, it fails

bpb
Offline
Joined: 2004-06-23

I was able to reproduce the problem on Solaris-SPARC for this configuration using the WarpDemo example program here: https://jai-webstart.dev.java.net/examples.html.

> If ImageIO is installed, but not JAI, it fails

Both your app and JAI install into the WebStart cache correctly but the app does not run, is that correct.

russelleast
Offline
Joined: 2004-01-09

> I was able to reproduce the problem on Solaris-SPARC
> for this configuration using the WarpDemo example
> program here:
> https://jai-webstart.dev.java.net/examples.html.
>
> > If ImageIO is installed, but not JAI, it fails
>
> Both your app and JAI install into the WebStart cache
> correctly but the app does not run, is that correct.

I agree, the problem is reproduced with the warp demo - I can see the NoClassDefFoundError reported in the Exception tab if I have ImageIO installed but not JAI.

I can't tell if the app and JAI are loaded into the cache, although it seems like they are, since, after I re-installed JAI locally, and tried starting warpdemo it started without downloading anything.

On the other hand (nothing to do with my issue) when both are installed locally, I do get another exception and the WarpDemo won't start, with this message: "the_nut.tif": File not found

java.lang.IllegalArgumentException: "the_nut.tif": File not found.
at javax.media.jai.JAI.createNS(JAI.java:1087)
at javax.media.jai.JAI.create(JAI.java:973)
at WarpDemo.(WarpDemo.java:480)
at WarpDemo.main(WarpDemo.java:596)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.javaws.Launcher.executeApplication(Launcher.java:1205)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1151)
at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:998)
at com.sun.javaws.Launcher.run(Launcher.java:105)
at java.lang.Thread.run(Thread.java:619)

Maybe something to do with the locally installed extensions?

russelleast
Offline
Joined: 2004-01-09

And then if I uninstall both extensions, there is no problem - nice little pic of the Nut from Stanley!

bpb
Offline
Joined: 2004-06-23

So to be clear, the only time you see a problem is when JAI Image I/O is already installed locally in the JRE and the user installs your application via the WebStart mechanism?

> Getting an odd error in the following rather special
> situation. It's really related to JAI, but only
> happens when JAI ImageIO is installed locally.
>
> Our app requires JAI, and we provide it as either
> applet or via WebStart. In some of our doc, we
> recommend optionally installing JAI ImageIO for
> improved performance, but for the WebStart app we
> don't require installing JAI, since it comes across
> as a WebStart extension in this case.
>
> Following is the exception we see if an end-user has
> JAI ImageIO locally installed in their JRE, but not
> JAI, on the first attempt to access the JAI class.
> JAI *should* be available via the WebStart extension
> mechanism, but I'm just guessing there might be some
> kind of security issue related to differing
> ClassLoader's???
>
> java.lang.NoClassDefFoundError:
> javax/media/jai/OperationRegistrySpi
> at java.lang.ClassLoader.defineClass1(Native
> e Method)
> at
> t
> java.lang.ClassLoader.defineClass(ClassLoader.java:620
> )
> at
> t
> java.security.SecureClassLoader.defineClass(SecureClas
> sLoader.java:124)
> at
> t
> java.net.URLClassLoader.defineClass(URLClassLoader.jav
> a:260)
> at
> t
> java.net.URLClassLoader.access$000(URLClassLoader.java
> :56)
> at
> t
> java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>
> at
> t java.security.AccessController.doPrivileged(Native
> Method)
> at
> t
> java.net.URLClassLoader.findClass(URLClassLoader.java:
> 188)
> at
> t
> java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at
> t
> java.lang.ClassLoader.loadClass(ClassLoader.java:299)
> at
> t
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.ja
> va:276)
> at
> t
> java.lang.ClassLoader.loadClass(ClassLoader.java:299)
> at
> t
> java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at
> t
> java.lang.ClassLoader.loadClassInternal(ClassLoader.ja
> va:319)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:247)
> at
> t
> com.sun.media.jai.util.Service$LazyIterator.next(Servi
> ce.java:267)
> at
> t
> javax.media.jai.OperationRegistry.registerServices(Ope
> rationRegistry.java:2047)
> at
> t
> javax.media.jai.ThreadSafeOperationRegistry.registerSe
> rvices(ThreadSafeOperationRegistry.java:612)
> at
> t
> javax.media.jai.OperationRegistry.initializeRegistry(O
> perationRegistry.java:365)
> at javax.media.jai.JAI.(JAI.java:560)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:169)
>
> ... our code is doing
> Class.forName("javax.media.jai.JAI") in order to
> test that the correct version of JAI is available.
>
> Happens on Windows and Linux (at least, and probably
> Sun as well) for JAI 1.1.3, JAI ImageIO 1.1.

russelleast
Offline
Joined: 2004-01-09

> So to be clear, the only time you see a problem is when JAI Image I/O is already installed locally in > the JRE and the user installs your application via the WebStart mechanism?

Yes.

bpb
Offline
Joined: 2004-06-23

We'll check it out.

> > So to be clear, the only time you see a problem is
> when JAI Image I/O is already installed locally in >
> the JRE and the user installs your application via
> the WebStart mechanism?
>
> Yes.

russelleast
Offline
Joined: 2004-01-09

> We'll check it out.

thanks