1 2 Previous Next 19 Replies Latest reply on Dec 8, 2008 3:34 PM by kabirkhan

    Remaing classLoader changes

      This thread brings together some previous discussion in other threads,
      but a small part of it (JBOSGI-15) has not been fully discussed before.

      Not all of this needs to be done for Beta4/RC1 since a lot of this is implementation
      detail and tidyup.

      The remaining work for the classloader changes falls into three main categories
      (I'll ignore fixing problems found using the new classloader which is just on going
      maintenance).

      1) Setting of the correct context classloader
      2) Using the new classloader in the bootstrap
      3) Finishing the OSGi classloading rules

      I'll discuss the details in other posts and link them here so we don't have yet another
      incomprenisble free for all.
      This thread can be used to raise issues not part of the other discussion.

        • 1. Re: Remaing classLoader changes

          Setting the context classloader in the Microcontainer
          http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122221#4122221

          Setting the deployer context classloader
          http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122224#4122224

          Bootstrap and module style classloader outside deployment layer
          http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122233#4122233

          Finishing the OSGI style classloader rules - META-INF/jboss-classloader.xml
          http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122245#4122245

          • 2. Re: Remaing classLoader changes
            starksm64

            One difference in behavior I'm seeing that we don't appear to have control over is duplicate resource ordering. The org.jboss.test.deployers.vfs.classloader.test.FilteredExportUnitTestCase.testEar1 test I just added shows a users.properties resource being loaded from the testear1/lib/jar1.jar rather than the testear1.ear/ejb1.jar as is the case for the ULR. In the ULR we give preference to exact matches on latter ordered classes loaders. If I turn off the import all flag, the ejb1.jar resource is found, but this is too restrictive a policy. We need a import-all-exact-match-first type of behavior it seems.

            • 3. Re: Remaing classLoader changes

               

              "scott.stark@jboss.org" wrote:
              One difference in behavior I'm seeing that we don't appear to have control over is duplicate resource ordering. The org.jboss.test.deployers.vfs.classloader.test.FilteredExportUnitTestCase.testEar1 test I just added shows a users.properties resource being loaded from the testear1/lib/jar1.jar rather than the testear1.ear/ejb1.jar as is the case for the ULR. In the ULR we give preference to exact matches on latter ordered classes loaders. If I turn off the import all flag, the ejb1.jar resource is found, but this is too restrictive a policy. We need a import-all-exact-match-first type of behavior it seems.


              I don't see what you are describing in the UnifiedClassLoader, but I do see a difference
              in the logic between the UnifiedLoaderRepository.getResource()

               public URL getResource(String name, ClassLoader cl)
               {
              
              ...
              
               // Not found in cache, ask the calling classloader
               resource = getResourceFromClassLoader(name, cl);
              
              ...
              
               // Not visible in global cache, iterate on all classloaders
               resource = getResourceFromRepository(name, cl);
              


              and BaseClassLoaderDomain.getResource()

               URL getResource(BaseClassLoader classLoader, String name, boolean allExports)
               {
               boolean trace = log.isTraceEnabled();
              
               if (getClassLoaderSystem() == null)
               throw new IllegalStateException("Domain is not registered with a classloader system: " + toLongString());
              
               // Try the before attempt
               URL result = beforeGetResource(name);
               if (result != null)
               return result;
              
               // Work out the rules
               ClassLoaderInformation info = null;
               BaseClassLoaderPolicy policy;
               if (classLoader != null)
               {
               policy = classLoader.getPolicy();
               info = infos.get(classLoader);
               if (policy.isImportAll())
               allExports = true;
               }
              
               // Next we try the old "big ball of mud" model
               if (allExports)
               {
               result = getResourceFromExports(classLoader, name, trace);
               if (result != null)
               return result;
               }
               else if (trace)
               log.trace(this + " not getting resource " + name + " from all exports");
              
               // Next we try the imports
               if (info != null)
               {
               result = getResourceFromImports(info, name, trace);
               if (result != null)
               return result;
               }
              
               // Finally use any requesting classloader
               if (classLoader != null)
               {
               if (trace)
               log.trace(this + " trying to get resource " + name + " from requesting " + classLoader);
               result = classLoader.getResourceLocally(name);
               if (result != null)
               {
               if (trace)
               log.trace(this + " got resource from requesting " + classLoader + " " + result);
               return result;
               }
               }
              
               // Try the after attempt
               result = afterGetResource(name);
               if (result != null)
               return result;
              
               // Didn't find it
               return null;
               }
              


              i..e. it doesn't do the look locally first before asking the parent or searching the
              repository.


              • 4. Re: Remaing classLoader changes

                 

                "adrian@jboss.org" wrote:
                "scott.stark@jboss.org" wrote:
                One difference in behavior I'm seeing that we don't appear to have control over is duplicate resource ordering. The org.jboss.test.deployers.vfs.classloader.test.FilteredExportUnitTestCase.testEar1 test I just added shows a users.properties resource being loaded from the testear1/lib/jar1.jar rather than the testear1.ear/ejb1.jar as is the case for the ULR. In the ULR we give preference to exact matches on latter ordered classes loaders. If I turn off the import all flag, the ejb1.jar resource is found, but this is too restrictive a policy. We need a import-all-exact-match-first type of behavior it seems.


                I don't see what you are describing in the UnifiedClassLoader


                Or is this something in the URLClassLoader code?

                • 5. Re: Remaing classLoader changes
                  starksm64

                  Ok, so do the current matching extension points/rules allow for ordering of bundles for resources/classes?

                  • 6. Re: Remaing classLoader changes

                     

                    "scott.stark@jboss.org" wrote:
                    Ok, so do the current matching extension points/rules allow for ordering of bundles for resources/classes?


                    For importAll, they are matched in the old way. i.e. the order the classloader
                    was added to the domain/repository. This is achieved by storing them in a list by
                    package name they export.

                    BaseClassLoaderDomain:
                     /** The classloaders by package name */
                     private Map<String, List<ClassLoaderInformation>> classLoadersByPackageName = new ConcurrentHashMap<String, List<ClassLoaderInformation>>();
                    


                    For specific imports (delegation model)
                    that are matched in the order the imports are "declared"
                    (and depending upon the parent policy, i.e. before/after).

                    • 7. Re: Remaing classLoader changes
                      starksm64

                       

                      "adrian@jboss.org" wrote:

                      ...
                      I don't see what you are describing in the UnifiedClassLoader
                      ...

                      Or is this something in the URLClassLoader code?

                      No, I'm thinking of the LoadMgr3 behavior for ordering resources for classes. The resource behavior difference is just what you described.

                      • 8. Re: Remaing classLoader changes
                        alesj

                         

                        "scott.stark@jboss.org" wrote:
                        One difference in behavior I'm seeing that we don't appear to have control over is duplicate resource ordering.

                        OK, I must admit I'm not entirely following the discussion. :-)
                        But has this got to do something with this:
                        2008-01-22 17:37:32,796 TRACE [org.jboss.seam.as5.vfs.VFSScanner] Root url: vfsfile:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/deploy/jboss-seam-booking.ear/jboss-seam-booking.war/WEB-INF/lib/jboss-seam-debug.jar/seam.properties
                        2008-01-22 17:37:32,796 TRACE [org.jboss.seam.as5.vfs.VFSScanner] File: C:\projects\jboss5\trunk\build\output\jboss-5.0.0.Beta4\server\default\deploy\jboss-seam-booking.ear\jboss-seam-booking.war\WEB-INF\lib\jboss-seam-debug.jar\seam.properties
                        2008-01-22 17:37:32,796 TRACE [org.jboss.seam.as5.vfs.VFSScanner] URL: file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/deploy/jboss-seam-booking.ear, relative: jboss-seam-booking.war/WEB-INF/lib/jboss-seam-debug.jar/seam.properties
                        
                        2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] Root url: jar:file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-exp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties
                        2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] File: file:\C:\projects\jboss5\trunk\build\output\jboss-5.0.0.Beta4\server\default\tmp\deploy\jboss-seam-booking19541-exp.war\WEB-INF\lib\jboss-seam-debug.jar!\seam.properties
                        2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] URL: null, relative: file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-exp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties
                        

                        I do a ClassLoader.getResources("seam.properties") inside Seam app, and I'm not expecting any non vfs URLs.
                        Where does that 'jar:file' come from?

                        • 9. Re: Remaing classLoader changes

                           

                          "scott.stark@jboss.org" wrote:
                          "adrian@jboss.org" wrote:

                          ...
                          I don't see what you are describing in the UnifiedClassLoader
                          ...

                          Or is this something in the URLClassLoader code?

                          No, I'm thinking of the LoadMgr3 behavior for ordering resources for classes. The resource behavior difference is just what you described.


                          This has been fixed:
                          http://jira.jboss.com/jira/browse/JBMICROCONT-227

                          • 10. Re: Remaing classLoader changes

                             

                            "alesj" wrote:
                            "scott.stark@jboss.org" wrote:
                            One difference in behavior I'm seeing that we don't appear to have control over is duplicate resource ordering.

                            OK, I must admit I'm not entirely following the discussion. :-)
                            But has this got to do something with this:
                            2008-01-22 17:37:32,796 TRACE [org.jboss.seam.as5.vfs.VFSScanner] Root url: vfsfile:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/deploy/jboss-seam-booking.ear/jboss-seam-booking.war/WEB-INF/lib/jboss-seam-debug.jar/seam.properties
                            2008-01-22 17:37:32,796 TRACE [org.jboss.seam.as5.vfs.VFSScanner] File: C:\projects\jboss5\trunk\build\output\jboss-5.0.0.Beta4\server\default\deploy\jboss-seam-booking.ear\jboss-seam-booking.war\WEB-INF\lib\jboss-seam-debug.jar\seam.properties
                            2008-01-22 17:37:32,796 TRACE [org.jboss.seam.as5.vfs.VFSScanner] URL: file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/deploy/jboss-seam-booking.ear, relative: jboss-seam-booking.war/WEB-INF/lib/jboss-seam-debug.jar/seam.properties
                            
                            2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] Root url: jar:file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-exp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties
                            2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] File: file:\C:\projects\jboss5\trunk\build\output\jboss-5.0.0.Beta4\server\default\tmp\deploy\jboss-seam-booking19541-exp.war\WEB-INF\lib\jboss-seam-debug.jar!\seam.properties
                            2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] URL: null, relative: file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-exp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties
                            

                            I do a ClassLoader.getResources("seam.properties") inside Seam app, and I'm not expecting any non vfs URLs.
                            Where does that 'jar:file' come from?


                            No. As I told you last week, this is showing that both the original and the tmp jar are being added
                            to the list of VFS files/urls in the classpath. You need to determine what is doing this.

                            • 11. Re: Remaing classLoader changes
                              alesj

                               

                              "adrian@jboss.org" wrote:

                              No. As I told you last week, this is showing that both the original and the tmp jar are being added
                              to the list of VFS files/urls in the classpath.

                              Eh, forgot about it, but I remember it now - the discussion. :-)
                              Just working on Seam scanner, stumbled on this problem. Seeing the word 'duplicate', thinking I was saved. ;-)

                              "adrian@jboss.org" wrote:

                              You need to determine what is doing this.

                              Any usual suspects?
                              WarDeployer?

                              • 12. Re: Remaing classLoader changes

                                 

                                "alesj" wrote:

                                "adrian@jboss.org" wrote:

                                You need to determine what is doing this.

                                Any usual suspects?
                                WarDeployer?


                                I'd guess since it is a war :-)

                                I'd start with finding out what adds -exp to the name and copies it to tmp
                                URL: null, relative: file:/C:/proj
                                ects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-e
                                xp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties
                                


                                And then sees who references that copy of the information.

                                • 13. Re: Remaing classLoader changes
                                  alesj

                                   

                                  "adrian@jboss.org" wrote:

                                  I'd start with finding out what adds -exp to the name and copies it to tmp
                                  URL: null, relative: file:/C:/proj
                                  ects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-e
                                  xp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties
                                  


                                  And then sees who references that copy of the information.

                                  It's AbstractWarDeployer, AbstractWarDeployment and TomcatDeployment.
                                   unit.addAttachment("org.jboss.web.expandedWarClasspath", classpath);
                                   }
                                  
                                   // Indicate that an expanded URL exists
                                   unit.addAttachment("org.jboss.web.expandedWarURL", expWarUrl, URL.class);
                                  ...
                                   // Get the war URL
                                   // FIXME: JBAS-3812 - TomcatDeployment should use modified WebMetaData
                                   URL warURL = unit.getAttachment("org.jboss.web.expandedWarURL", URL.class);
                                  ...
                                   ArrayList<URL> classpath = (ArrayList<URL>)unit.getAttachment("org.jboss.web.expandedWarClasspath");
                                  

                                  But I have no idea what's done right and what wrong, to know what causes that duplicate. :-)

                                  • 14. Re: Remaing classLoader changes
                                    starksm64

                                     

                                    "alesj" wrote:

                                    2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] Root url: jar:file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-exp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties
                                    2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] File: file:\C:\projects\jboss5\trunk\build\output\jboss-5.0.0.Beta4\server\default\tmp\deploy\jboss-seam-booking19541-exp.war\WEB-INF\lib\jboss-seam-debug.jar!\seam.properties
                                    2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] URL: null, relative: file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-exp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties
                                    

                                    I do a ClassLoader.getResources("seam.properties") inside Seam app, and I'm not expecting any non vfs URLs.
                                    Where does that 'jar:file' come from?


                                    With the current mc code FilteredExportUnitTestCase.testEar1 its only showing vfs urls. I created a version that used a packed ear, and this also only shows vfsurls.

                                    For the war I assume its because a different class loader is being used. I'm still working on getting the war class loader to be based on the WarClassLoaderDeployer.


                                    1 2 Previous Next