9 Replies Latest reply on Dec 1, 2011 5:07 AM by guinotphil

    Sealed packages & modules.

    guinotphil

      Hi,

       

      I'm currently having an issue with a lib that use sealed packages that I want to use as a JBoss Modules.

       

      The library is OpenOffice, and I created the module org.openoffice.

       

      Here is my module.xml:

      <?xml version="1.0" encoding="UTF-8"?>

      <module xmlns="urn:jboss:module:1.0" name="org.openoffice">

        <resources>

          <resource-root path="juh-3.2.1.jar"/>

          <resource-root path="jurt-3.2.1.jar"/>

          <resource-root path="ridl-3.2.1.jar"/>

          <resource-root path="unoil-3.2.1.jar"/>

        </resources>

       

        <dependencies>

        </dependencies>

      </module>

       

       

      And here is the manifest.xml of each library:

       

      juh-3.2.1.jar:

      Manifest-Version: 1.0

      Class-Path: ridl.jar jurt.jar ../../lib/ ../bin/

      Solar-Version: 320m14(Build:9489)

      Sealed: true

      RegistrationClassName: com.sun.star.comp.JavaUNOHelperServices

      UNO-Type-Path:

       

      jurt-3.2.1.jar:

      Manifest-Version: 1.0

      Class-Path: ridl.jar unoloader.jar ../../lib/ ../bin/

      Solar-Version: 320m14(Build:9489)

      Sealed: true

       

      Name: com/sun/star/lib/util/

      Sealed: false

       

       

      Name: com/sun/star/uno/

      Sealed: false

       

      ridl-3.2.1.jar:

      Manifest-Version: 1.0

      Solar-Version: 320m14(Build:9489)

       

      unoil-3.2.1.jar:

      Manifest-Version: 1.0

      Solar-Version: 320m14(Build:9489)

       

      As you can see, only a couple of JAR use the sealing facilities.

       

      My problem comes with the com.sun.star.uno package.

      2 jars define classes in this package:

      • ridl-3.2.1.jar, which has no sealing restriction.
      • jurt-3.2.1.jar, which has restriction, but NOT for this package

       

      When starting the server, I got the following Exception:

       

      17:14:51,826 WARN  [org.jboss.modules] (MSC service thread 1-8) Failed to define class com.sun.star.lang.DisposedException in Module "org.openoffice:main" from local module loader @b92a848 (roots: C:\DEV\jboss-as-7.1.0.Alpha2-SNAPSHOT\modules): java.lang.SecurityException: sealing violation: package com.sun.star.uno is sealed

                at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:354) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.Module.loadModuleClass(Module.java:590) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:183) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:361) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:333) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:333) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:310) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:103) [jboss-modules.jar:1.0.2.GA]

                at java.lang.ClassLoader.defineClass1(Native Method) [:1.6.0_27]

                at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [:1.6.0_27]

                at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [:1.6.0_27]

                at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) [:1.6.0_27]

                at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:397) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.Module.loadModuleClass(Module.java:590) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:183) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:361) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:333) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:310) [jboss-modules.jar:1.0.2.GA]

                at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:103) [jboss-modules.jar:1.0.2.GA]

                at java.lang.Class.getDeclaredFields0(Native Method) [:1.6.0_27]

                at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [:1.6.0_27]

                at java.lang.Class.getDeclaredFields(Class.java:1743) [:1.6.0_27]

                at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:57)

                at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:66)

                at org.jboss.as.ee.component.EEModuleClassDescription$DefaultConfigurator.configure(EEModuleClassDescription.java:176)

                at org.jboss.as.ee.component.deployers.EEClassConfigurationProcessor$1.compute(EEClassConfigurationProcessor.java:147)

                at org.jboss.as.ee.component.deployers.EEClassConfigurationProcessor$1.compute(EEClassConfigurationProcessor.java:122)

                at org.jboss.as.ee.component.LazyValue.get(LazyValue.java:40)

                at org.jboss.as.ee.component.EEApplicationDescription.getClassConfiguration(EEApplicationDescription.java:183)

                at org.jboss.as.ee.component.ComponentDescription.createConfiguration(ComponentDescription.java:153)

                at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:70)

                at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)

                at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824)

                at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759)

                at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_27]

                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_27]

                at java.lang.Thread.run(Thread.java:662) [:1.6.0_27]

       

       

      Looks like the "Sealed: false" option in MANIFEST.MF does not 'unseal' the package.

       

      And too bad, after removing the sealed options in the jurt jar, I still get the same error. Had to remove the options in the juh jar to fix the issue. But the juh jar has ONLY the following packages:

      • com.sun.star.comp
      • com.sun.star.comp.helper
      • com.sun.star.comp.juhtest
      • com.sun.star.lib.uno.adapter
      • com.sun.star.lib.uno.helper

       

      Thank you for your help

        • 1. Re: Sealed packages & modules.
          jaikiran

          Try enabling TRACE level logging for org.jboss.module and see what it shows for this package.

          • 2. Re: Sealed packages & modules.
            jaikiran
            1 of 1 people found this helpful
            • 3. Re: Sealed packages & modules.
              guinotphil

              Thank you for your fix.

               

              However this does not seems to fix my issue. As I said I tried to deploy the libs as JBoss module, so I don't think this is a VFS issue.

               

              However, your fix help me to find out that the PackageSpec is defined in

              org.jboss.modules.AbstractResourceLoader.getPackageSpec(String, Manifest, URL)

               

              Putting in the

              if (Boolean.parseBoolean(getDefinedAttribute(Attributes.Name.SEALED, entryAttribute, mainAttribute))) {

                     spec.setSealBase(rootUrl);

              }

              condition a breakpoint helped me to find that the sealed condition on the com.sun.star.uno package is called with the following rootUrl : jar:file:/C:/DEV/jboss-as-7.1.0.Alpha2-SNAPSHOT/modules/org/openoffice/main/juh-3.2.1.jar!/

              Or, as I said this jar does not contains the com.sun.star.uno package.

               

              Looking at the stracktrace, I notice that in org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:364)

              for each ResourceLoader (ie jar), a PackageSpec will be loaded. So, it seems that it load the package spec from the first jar with its options, even if the package does not exist in the jar file.

              • 4. Re: Sealed packages & modules.
                guinotphil

                In other words, in the defineClass method, it looks in each Jars to find a PackageSpec not null for a given package name. (line 365, if (spec != null) )

                But the method getPackageSpec of the loader, won't return null. So it'll always give the spec from the options of the first jar...

                • 5. Re: Sealed packages & modules.
                  jaikiran

                  Is it possible to attach your application which reproduces this, to this thread? That'll make it far easier to reproduce and fix this.

                  • 6. Re: Sealed packages & modules.
                    guinotphil

                    Hi,

                     

                    Here are the steps to create the error.

                     

                    First, create the org.openoffice module with the module.xml as above:

                    <?xml version="1.0" encoding="UTF-8"?>

                    <module xmlns="urn:jboss:module:1.0" name="org.openoffice">

                      <resources>

                        <resource-root path="juh-3.2.1.jar"/>

                        <resource-root path="jurt-3.2.1.jar"/>

                        <resource-root path="ridl-3.2.1.jar"/>

                        <resource-root path="unoil-3.2.1.jar"/>

                      </resources>

                     

                      <dependencies>

                      </dependencies>

                    </module>

                     

                    You can find the JARs via maven, you can get them here:

                    http://repo1.maven.org/maven2/org/openoffice/

                     

                     

                    Then, deploy the attached application.

                     

                    Once deployed, please run index.jsp via: http://localhost:8080/

                    You may get the error:

                    java.lang.SecurityException: sealing violation: package com.sun.star.lib.uno.typeinfo is sealed

                     

                    If you add a breakpoint at line 52 of org.jboss.modules.AbstractResourceLoader, you'll see that both packages

                    • com.sun.star.uno
                    • com.sun.star.lib.uno.typeinfo

                    are considered sealed, and are not linked with their own's jar, but with juh-3.2.1.jar

                    • 7. Re: Sealed packages & modules.
                      guinotphil

                      Should I open a bug for this ? Looks like a critical issue in JBoss Module for me.

                      • 8. Re: Sealed packages & modules.
                        jaikiran

                        guinotphil wrote:

                         

                        Should I open a bug for this ? Looks like a critical issue in JBoss Module for me.

                        I forgot about this. So yes, please create a JBMODULE JIRA.

                        1 of 1 people found this helpful
                        • 9. Re: Sealed packages & modules.
                          guinotphil

                          https://issues.jboss.org/browse/MODULES-108

                           

                          I created the issue a couple of month ago.

                           

                          For the moment I've edited the jar files to avoid the problem, but will there be any plans to put this issue in a future roadmap ?