8 Replies Latest reply on Dec 20, 2011 12:30 PM by alesj

    Visibility of several (versions of) jar's in JBoss EAP 5.1

    simon_jongsma

      Hi there!

       

      We currently have a problem with the JBoss EAP 5.1 classloading.

      I tried to solve the issue using several jboss-classloading.xml setups but did not succeed.

      So I would be very glad if someone could provide some help on this.

       

      Resume: we are deploying six ear’s in total; A, C, C, D, E, F.

       

      Five of those (A through E) are using a external jar xxx.jar version 2.0 (in lib directory).

      One ear (F) is using the same xxx.jar but a legacy version 1.0 of it which we embedded inside the F ear.

      Objective was to limit visibility of this jar.

      Problem now arises that all ear’s are nevertheless “seeing” xxx.jar version 1.0 instead of version 2.0.

       

      Our wish is to configure JBoss (using jboss-classloading.xml files presumably) to configure the F ear,
      so that it’s (embedded?) xxx.jar is NOT exposed to the other 5 ear’s.

      Note: we do want F ear to "see" other jars in the JBoss environment.

       

      At the same time F ear now contains a class "com.getronics.slg.civmk.common.jaas.listener.CivisionSessionListener"
      that we want to be visible for ear’s A through E.

       

      Can you help us? It’s rather urgent; our development time window ends this week.

        • 1. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
          alesj

          Can you help us? It’s rather urgent; our development time window ends this week.

          Since this is EAP, I suggest you use JBoss Support.

          That's the easiest way how you get urgent things done. ;-)

          • 2. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
            simon_jongsma

            Thanks Ales,

            We were walking that road that anyway..

            But if you know the answer beforehand I would be grateful.

            Regards,

            Simon

            • 3. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
              alesj

              At the same time F ear now contains a class "com.getronics.slg.civmk.common.jaas.listener.CivisionSessionListener"

              that we want to be visible for ear’s A through E.

              If it wasn't for this, then it would be pretty simple to do this -- simply putting F into own CL domain, with DefaultDomain as parent.

              But with this, it means that A-F still need to be in a shared CL domain.

              Let me think about this ...

              • 4. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
                alesj

                For F: perhaps try to avoid big-ball-o-mud, and filter out the xxx.jar from ext delegates.

                 

                This is the code in BaseCLDomain that should help:

                 

                         if (policy.isImportAll())
                            allExports = true;
                      }
                
                
                      // Next we try the old "big ball of mud" model      
                      if (allExports)
                      {
                         loader = findLoaderInExports(classLoader, name, trace);
                         if (loader != null)
                            return loader;
                      }
                      else if (trace)
                         log.trace(this + " not loading " + name + " from all exports");
                
                      // Next we try the imports
                      if (info != null)
                      {
                         loader = findLoaderInImports(info, name, trace);
                
                • 5. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
                  simon_jongsma

                  Are you suggesting that I do a extend/override on the JBoss class loading?

                  I'm new at this..
                  Can you elaborate a bit: which class I need to subclass/override & how I could do this?

                  Thanks in advance!

                  • 6. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
                    alesj

                    Are you suggesting that I do a extend/override on the JBoss class loading?

                    No. :-)

                    I was thinking of having a proper jboss-classloading.xml configuration.

                    e.g. import-all=false, right requirements, etc

                    • 7. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
                      simon_jongsma

                      For your info:

                       

                      We were able to solve this by isolating the Fear adding a jboss-app.xml and a simple loader-repository entry there.

                      In the F ear is a top-level lib directory with our xxx.jar version 1,0.

                      xxx.jar 2.0 is in the lib directory. The other ear's no changes.

                       

                      The visibility of the CivisionSessionListener class is not solved yet (needed for Shiro single-signoff).
                      Could that be arranged with jboss-classloading.xml? Can you provide an example?


                      Besides this:

                      There were some plugin jars that needed to be outside the ear (must be customizable).

                      These were callable but could not talk back to classes inside the ear.

                       

                      We were able to solve this by loading these separately using raw byte streams (nasty but effective).

                      • 8. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
                        alesj

                        Isolating F helps with seeing the x.jar v1.0 first.

                        But that hides the CSL class.

                         

                        Those jars should be able to see classes from A-E, if they are not .war classes.

                        Ah, direct streams, it always helps. :-)

                         

                        Hopefully I'll find some more time soon to check how to do proper solution.

                        I will have to be "OSGi"-like in order to work w/o hacks.