5 Replies Latest reply on Jul 19, 2011 12:11 PM by ssilvert

    Newbie question about Spring integration

    robertgary1

      We've migrated to JBoss 6 and I'm not sure we are installing Spring correctly in 6. Because we have numerous WARs, EARS, etc that rely on Spring we put the libraries in $JBOSS_HOME/server/myserver/lib. However, the WAR applications use Spring servlets, Spring JSF VariableResolver, etc.So when I start I get an error

       

      [2011-05-20 09:20:11] SEVERE [Thread-2 org.apache.myfaces.webapp.AbstractFacesIn

      itializer] An error occured while initializing MyFaces: Class org.springframewor

      k.web.jsf.DelegatingVariableResolver is no javax.faces.el.VariableResolver: java

      .lang.IllegalArgumentException: Class org.springframework.web.jsf.DelegatingVari

      ableResolver is no javax.faces.el.VariableResolver

       

      I'm thinking this is because the WAR is getting the Spring reference from the global classloader but the JSF deployer (I'm using the MyFaces-2.0 deployer from JBoss) is in the WAR's classloader and its not able to reference it back.

       

      1) Am I incorrectly doing the Spring integration?

      2) How can I share Spring with multiple applications without such a classloader issue in JBoss?

       

      Thanks!

      -Robert

        • 1. Re: Newbie question about Spring integration
          dlmiles

          It would good for JBoss to write up some full and clear documentation covering all the features of their Class Loading mechanisms.  I have read a number of snippets over the time of AS5, AS6 and now AS7 that claim there is a new mix of ideas on the topic and that JBoss software is the best.  However there does not seem to be information to back up this claim that is in the form of full and complete documentation covering all possible features.

           

          This is something that at least Spring Framework has going well for itself.  The quality and completeness of the documentation covering all the features makes it one of the best open-source products there is.

           

          If anything I'd like to see the JBoss AS core have as good technical a documentation as say Hibernate does.   The quick-start, pet-clinic, admin-guide are all great but where is the "reference manual" that covers all possible features from A to Z ?  What I as a user wants to know is, if I want access to some of the hybrid JBoss AS specific features (that may or may not be part of any JSR) we need to know about them all to be trying them, blog about them, suggesting revisions and patches to them, etc... no documentation = smaller eco system

           

          So while AS7 claims to have re-written the book on class loading in my opinion at this time until a full set of documentation about that alone is written, this sound bite is nothing more than clever marketing and hype, just like it seems to have been when a similar claim was made about AS6.

           

           

          It is no wonder that a thread request like the OP here goes unanswered for over a month.   We're sorry but the great JBoss AS class loader is not documented well enough maybe as a solution I can offer you "try to reduce the number of poorly documented open-source parts from your project."

          • 2. Re: Newbie question about Spring integration
            alesj

            1) Am I incorrectly doing the Spring integration?

            Looks OK.

            This is a valid approach, specially as you mention that you have multiple apps depending on Spring libs,

            hence sharead libs is the right way to go.

            2) How can I share Spring with multiple applications without such a classloader issue in JBoss?

            The problem is not referencing back, it's the dup EL classes.

            Spring's DelegatingVariableResolver uses its own instance of VariableResolver,

            where your .war uses another, hence "classic" CCE.

             

            I would say you try to dissable this per-deployment-JSF handling.

            Then you would only have one global JSF lib, hence no dups --> should work, but less flexible.

            • 3. Re: Newbie question about Spring integration
              marius.bogoevici

              Hi Robert,

               

              Thanks for using AS6 and sorry for missing this question.

               

              You're not doing the Spring integration incorrectly, but due to the way the JSF integration works, it's relatively hard (if not impossible) to use the deployer (which adds the JSF API+implementation classes at the WAR level) and use shared JSF utility classes (which load in the global classloader).

               

              You have a few options:

              1. disable the deployer *and* share the JSF API+Implementation classes globally (as Ales says)

              2. Keep the current structure and include only the Spring JSF classes in your deployment (not shared)

              3. Use your own JSF implementation bundled in the WAR as shown here: http://docs.jboss.org/jbossas/6/JSF_Guide/en-US/html/jsf.deployer.config.html#bundling.jsf.with.war

              • 4. Re: Newbie question about Spring integration
                marius.bogoevici

                Actually, option 3 is not too much help if you want to share the Spring JSF classes (due to visibility issues) - it would help dealing with duplications only.

                 

                So it's really 1 or 2, 1 being the most straightforward candidate.

                • 5. Re: Newbie question about Spring integration
                  ssilvert

                  Marius Bogoevici wrote:

                   

                  Hi Robert,

                   

                  Thanks for using AS6 and sorry for missing this question.

                   

                  You're not doing the Spring integration incorrectly, but due to the way the JSF integration works, it's relatively hard (if not impossible) to use the deployer (which adds the JSF API+implementation classes at the WAR level) and use shared JSF utility classes (which load in the global classloader).

                   

                  You have a few options:

                  1. disable the deployer *and* share the JSF API+Implementation classes globally (as Ales says)

                  2. Keep the current structure and include only the Spring JSF classes in your deployment (not shared)

                  3. Use your own JSF implementation bundled in the WAR as shown here: http://docs.jboss.org/jbossas/6/JSF_Guide/en-US/html/jsf.deployer.config.html#bundling.jsf.with.war

                  Option #4 is in the JSF Deployer documentation that you reference in #3 above.  Instead of bundling JSF with your WAR, look at sections 3.7 and 3.8 of that document.  This describes a feature where you create your own JSF configuration.  You can include any combination of JSF implementation and supporting libraries in that configuration.  Note that the JSF configuration contains its own "shared" web.xml that allows you to configure these libraries.  Then when you are done with the configuration you use a setting in the application's web.xml to tell that JSF Deployer that you want to use that configuration. 

                   

                  I don't know the particulars of the libraries you are trying to use, but it sounds to me like option #4 might be exactly what you are trying to do.  It makes the JSF configuration look like it would if you bundled it with each WAR.

                   

                  Stan