3 Replies Latest reply on Oct 26, 2011 11:19 PM by Brian Wallis

    AS6 support for Service.providers()

    Brian Wallis Master

      We are attempting to use some javax.imageio classes in a war file and need to deploy the jai-imageio-1.1.jar file as part of that war.


      The use of these classes relies on the Service Provider feature of the jar file, ie: the loading of the service specifications that are in the files found in the jar's META-INF/services directory. The code to use the service is



                  ImageReader           reader = ImageIO.getImageReadersByFormatName(extension).next();



      This doesn't work if the jai-imageio jar file is deployed in the WEB-INF/lib or in an enclosing ear file's lib directory. Is there a way to configure the war/ear to respect the service provider configuration files in the jar files?


      The current workaround is to copy the jar-imageio jar files (there are 3) into the server/default//lib directory. This seems to cause the service provider configuration files to be used.



      brian wallis...

        • 1. Re: AS6 support for Service.providers()
          jaikiran pai Master

          I don't see a reason why it shouldn't work. However, I haven't looked at how the ImageIO method is implemented. So it might have to do with the implementation. Do you have more details about that?


          Edit: I misread your post. I thought ImageIO was some class from the library that you are using.

          1 of 1 people found this helpful
          • 2. Re: AS6 support for Service.providers()
            jaikiran pai Master
                 * Scans for plug-ins on the application class path,
                 * loads their service provider classes, and registers a service
                 * provider instance for each one found with the
                 * <code>IIORegistry</code>.
                 * <p>This method is needed because the application class path can
                 * theoretically change, or additional plug-ins may become available.
                 * Rather than re-scanning the classpath on every invocation of the
                 * API, the class path is scanned automatically only on the first
                 * invocation. Clients can call this method to prompt a re-scan.
                 * Thus this method need only be invoked by sophisticated applications
                 * which dynamically make new plug-ins available at runtime.
                 * <p> The <code>getResources</code> method of the context
                 * <code>ClassLoader</code> is used locate JAR files containing
                 * files named
                 * <code>META-INF/services/javax.imageio.spi.</code><i>classname</i>,
                 * where <i>classname</i> is one of <code>ImageReaderSpi</code>,
                 * <code>ImageWriterSpi</code>, <code>ImageTranscoderSpi</code>,
                 * <code>ImageInputStreamSpi</code>, or
                 * <code>ImageOutputStreamSpi</code>, along the application class
                 * path.
                 * <p> The contents of the located files indicate the names of
                 * actual implementation classes which implement the
                 * aforementioned service provider interfaces; the default class
                 * loader is then used to load each of these classes and to
                 * instantiate an instance of each class, which is then placed
                 * into the registry for later retrieval.
                 * <p> The exact set of locations searched depends on the
                 * implementation of the Java runtime enviroment.
                 * @see ClassLoader#getResources
                public static void scanForPlugins() {



            So I'm guessing that it's a case of wrong (thread context) classloader being used whenver that call to scanForPlugins is happening. It probably isn't using the deployment's classloader and instead using the server level classloader which doesn't have visibility to the deployments classes/resources.

            1 of 1 people found this helpful
            • 3. Re: AS6 support for Service.providers()
              Brian Wallis Master

              Thanks for the comments on this. Since we have a work around I won't persue this in the AS6 version. Since AS7 is completly different in how all of this works and from what I understand about the support of services in modules, I expect this won't be so much of a problem - we will see...


              We are using a different version of the ImageIO stuff from what is included in the JDK so that is probably contributing to the problem. Having any duplicate classes of differing versions is always going to cause odd and difficult problems in JBoss, at least for 6 and earlier.


              thanks again.