1 2 Previous Next 15 Replies Latest reply on Aug 18, 2009 6:07 PM by Gary Brown

    Class loading conflict

    Gary Brown Master

      Hi

      I have a sar that includes xmlbeans 2.3.0 - which works fine in AS 5.1. However when I installed ESB4.6, which has version 2.2.0 of this jar in its esb-deployer, I get schema version problems.

      What is the best way to isolate my sar from being affected by jar versions in other non-dependent deployments?

      Regards
      Gary

        • 2. Re: Class loading conflict
          Ales Justin Master

          You need to "mimic" this isolation code

           String domain = getJMXName(deployment, unit) + ",extension=LoaderRepository";
           classLoadingMetaData = new ClassLoadingMetaData();
           classLoadingMetaData.setName(unit.getName());
           classLoadingMetaData.setDomain(domain);
           classLoadingMetaData.setExportAll(ExportAll.NON_EMPTY);
           classLoadingMetaData.setImportAll(true);
           classLoadingMetaData.setVersion(Version.DEFAULT_VERSION);
           classLoadingMetaData.setJ2seClassLoadingCompliance(false);
          
          

          taken from http://anonsvn.jboss.org/repos/jbossas/projects/webbeans-ri-int/trunk/deployer/src/main/java/org/jboss/webbeans/integration/deployer/metadata/WebBeansClassloadingDeployer.java
          in your jboss-classloading.xml.

          Where you should put this file into esb.deployer and your deployment,
          so that both are isolated and don't see over-lapping classes.

          • 3. Re: Class loading conflict
            Gary Brown Master

            Hi,

            Tried that approach, but now I have a problem in that the ESB is complaining about classes not being found. The jboss-classloading.xml is placed in the esb.deployer, so I assume that isolation is now causing the jbossesb.sar to not resolve classes that it previously referenced from the esb.deployer.

            So I assume to overcome this, I would need a jboss-classloading.xml in the jbossesb.sar?

            The jbossesb.sar has a deployment.xml but it does not have a dependency on the deployer - if it did, would this overcome the problem? or do all deployment units that depend upon the ESB need to have its own jboss-classloading.xml? i.e. any .esb distribution?

            The other problem with this approach is that it requires me to modify the ESB distribution. Is there no mechanism to just enable my sar to indicate that it wants to have only its own libs, and the jboss AS libs on its classpath?

            Regards
            Gary

            • 4. Re: Class loading conflict
              Ales Justin Master

              What about if you add parentDomain="DefaultDomain" to the esb.deployer's jboss-classloading.xml?

              • 5. Re: Class loading conflict
                Gary Brown Master

                No, still no luck - just to check, the jboss-classloading.xml in esb.deployer is:

                <classloading domain="jboss.esb:service=EsbDeployer,extension=LoaderRepository" xmlns="urn:jboss:classloading:1.0" name="EsbDeployer"
                import-all="true" export-all="NON_EMPTY" version="0.0.0"
                j2seClassLoadingCompliance="false" parentDomain="DefaultDomain" >


                and it causes exceptions like:

                15:34:00,679 ERROR [AbstractKernelController] Error installing to Instantiated: name=jboss.esb:service=PropertyService state=Described mode=Manual requiredState=Configured
                java.lang.ClassNotFoundException: org.jboss.soa.esb.common.JBossESBPropertyService from BaseClassLoader@127d5a0{VFSClassLoaderPolicy@3a0533{name=vfsfile:/.......

                • 6. Re: Class loading conflict
                  Ales Justin Master

                  What about if you just have this jboss-classloading.xml in your deployment:

                  <classloading domain="some-name" xmlns="urn:jboss:classloading:1.0" name="some-name"
                  import-all="true" export-all="NON_EMPTY" version="0.0.0"
                  j2seClassLoadingCompliance="false" parentDomain="DefaultDomain" >

                  and leave esb.deployer as it is.
                  Or did you already try this?

                  • 7. Re: Class loading conflict
                    Gary Brown Master

                    I hadn't tried with all those attributes, so I just tried it with the same result :(

                    Just to make sure, this is what I have used:

                    <classloading domain="jboss.bpel:service=BPELEngine,extension=LoaderRepository" xmlns="urn:jboss:classloading:1.0" name="BPELEngine"
                     import-all="true" export-all="NON_EMPTY" version="0.0.0"
                     j2seClassLoadingCompliance="false" parentDomain="DefaultDomain" >
                    </classloading>
                    


                    • 8. Re: Class loading conflict
                      Ales Justin Master

                       

                      "objectiser" wrote:
                      I hadn't tried with all those attributes, so I just tried it with the same result :(

                      So, you're still picking up esb.deployer's classes?

                      I'll try to re-create this tomorrow, ok?

                      • 9. Re: Class loading conflict
                        Gary Brown Master

                        Yes, still picking up the xbeans-2.2.0.jar from the esb.deployer lib, instead of my local xmlbeans-2.3.0.jar in my sar's lib folder.

                        Tomorrow is ok.

                        Thanks.

                        • 10. Re: Class loading conflict
                          Ales Justin Master

                          You put wrong attribute. ;-)

                          j2seClassLoadingCompliance --> parent-first

                          I guess we should validate this xmls.

                          So, this does the trick for me:

                          <classloading xmlns="urn:jboss:classloading:1.0"
                           domain="some-name"
                           name="some-name"
                           import-all="true"
                           export-all="NON_EMPTY"
                           version="0.0.0"
                           parent-first="false"
                           parentDomain="DefaultDomain"
                          />
                          


                          Simply put this into your deployment/app.

                          • 11. Re: Class loading conflict
                            Gary Brown Master

                            Yes that worked.

                            Thanks for your help.

                            Regards
                            Gary

                            • 12. Re: Class loading conflict
                              Ales Justin Master

                               

                              "objectiser" wrote:

                              Thanks for the help so far - just another quick question, as well as the isolation of the riftsaw.sar, I also have an esb module that is dependent upon an interface within the sar.

                              I tried defining a capability in the sar's classloading.xml, and then define a simple jboss-classloading.xml that defines a 'requirement' on that capability. But this did not help - it now generates the following problem:

                              Deployment "<UNKNOWN vfsfile:/NotBackedUp/gbrown/testing/riftsaw/jboss-5.1.0.GA/server/default/deploy/riftsaw.esb/>" is in error due to the following reason(s): ** UNRESOLVED ModuleRequirement{BPELEngine [0.0.0,?)} **

                              I have attached the two jboss-classloading.xml file - could you let me know how I can ensure the riftsar.esb can access a particular interface in the sar.

                              <classloading domain="jboss.bpel:service=BPELEngine,extension=LoaderRepository" xmlns="urn:jboss:classloading:1.0" name="BPELEngine"
                               import-all="true" export-all="NON_EMPTY" version="0.0.0"
                               parent-first="false" parentDomain="DefaultDomain" >
                               <capabilities>
                               <module name="BPELEngine" />
                               </capabilities>
                              </classloading>
                              


                              <classloading xmlns="urn:jboss:classloading:1.0" domain="DefaultDomain" export-all="ALL" name="RiftSaw" >
                               <capabilities>
                               <module name="RiftSaw" />
                               </capabilities>
                               <requirements>
                               <module name="BPELEngine" />
                               </requirements>
                              </classloading>
                              



                              BPELEngine is in separate domain - jboss.bpel:service=BPELEngine,extension=LoaderRepository.
                              Hence RiftSaw - which is in DefaultDomain - cannot see it.

                              They should be in the same or hierarchy-accessible domains.
                              e.g. BPELEngine's domain could be some ancestor of RiftSaw's domain

                              If this was the other way around it would work, as BPELEngine would find RiftSaw in its parent (== DefaultDomain) domain.

                              • 13. Re: Class loading conflict
                                Gary Brown Master

                                Hi Ales

                                Using the same domains in the riftsaw.esb and sar worked fine, but introduced another problem when I deployed some ESB examples that depended upon the action I had defined in the riftsaw.esb, and I don't think it would be a good idea for me to set the domain inside the ESB example to be based on riftsaw, as an ESB service in reality maybe using a number of other thirdparty custom ESB actions - and I assume it cannot be part of multiple domains?

                                So I thought it best to outline the overall scenario, to see whether there is a good overall solution, rather than presenting the side effects of each individual change as I have currently being doing.

                                1) The riftsaw.sar, which had the original jar conflict, is not dependent upon JbossESB. It does however have some interfaces that need to be used externally.

                                2) If the JBossESB integration is being used, then currently there is a single BPEL invoke action that needs to access the interface from the riftsaw.sar

                                3) Other ESB services - that may need to use the BPELInvoke action. Currently ESB services don't need to do anything specific in their configuration to pick up ESB actions defined in other .esb modules - so either this approach needs to continue, or an approach needs to be used that would enable the ESB example to reference multiple ESB actions potentially defined in different isolation domains.

                                Hope this gives a clearer outline of the dependencies and what we are wanting to achieve.

                                Regards
                                Gary

                                • 14. Re: Class loading conflict
                                  Ales Justin Master

                                  I can currently think of two solutions.

                                  (1) Still put all ESB examples in the same domain as RiftSaw, with parent being DefaultDomain and perhaps parent-first=true

                                  Don't see why this would be a problem?
                                  Or why would you need multiple domains?
                                  Their parent is DefaultDomain, hence they see all what default stuff sees.

                                  (2) Be "OSGi" exact

                                  Split / extract the conflicting jar into separate deployment, and give it proper jboss-classloading.xml
                                  e.g. readable module name + *proper* version

                                  Do the same with its updated version.

                                  Then simply reference the right exact module,
                                  whereas you don't need to define any separate domains.

                                  It's definitely more work, plus you need to wrap existing external jars,
                                  but this is a known OSGi issue - see SS's huge effort of creating proper repository.

                                  1 2 Previous Next