11 Replies Latest reply on Mar 5, 2013 11:07 AM by enriquezrene

    JBOSS5 + Spring Deployer version confusion

    dlmiles

      I see there is: Spring Deployer 2.1 (in 2.5/2.5.x and 2.0.8 forms) this is a JAR and contains no implementation of Spring and no JBOSS5 style META-INF/spring-deployers-beans.xml.

      I am correct in thinking the above version is for JBoss AS 4.2.x and older ? But should not be used wit JBoss AS 5 ?


      I see there is: Spring Deployer 3.0 (which includes a jboss-spring.deployer JAR file, which appears to be in JBOSS5 deployers format, it does not include an implementation of Spring that appears to be older than spring 2.0.7 from filesizes and timestamps). When this file is dropped into the JBoss5 deployers directory I see no log entry indicating startup of the deployer. Should something appear in the JBossAS console log ?

      I am correct in thinking this should be used with JBoss AS 5 and newer ?

      Now if I wanted to upgrade to 2.0.7 or 2.0.8 is a recompile necessary or can I replace the spring-*.jar files inside the jboss-spring.deployer file ?

      Could I also suggest that all dependent JARs what are bundled please use the file name that includes the version of said file like "spring-core-2.0.99.jar" not just the plain "spring-core.jar" so its really clear to audit.

      This could also extend to the deployer archive itself, jboss-spring-3.0.deployer.

        • 1. Re: JBOSS5 + Spring Deployer version confusion
          alesj

           

          "dlmiles" wrote:

          I am correct in thinking the above version is for JBoss AS 4.2.x and older ? But should not be used wit JBoss AS 5 ?

          Yes, only JBossAS 4.x.

          "dlmiles" wrote:

          Should something appear in the JBossAS console log ?

          If you use trace log for deployers packages, there should be some log indicating that deployer was added to MainDeployersImpl/DeployersImpl.

          "dlmiles" wrote:

          I am correct in thinking this should be used with JBoss AS 5 and newer ?

          Yes, it's the new breed of deployers. :-)

          "dlmiles" wrote:

          Now if I wanted to upgrade to 2.0.7 or 2.0.8 is a recompile necessary or can I replace the spring-*.jar files inside the jboss-spring.deployer file ?

          It depends on the back (or in this case fwd) compatibility of Spring lib.
          I had no problems changing between 2.0.8 and 2.5.

          "dlmiles" wrote:

          Could I also suggest that all dependent JARs what are bundled please use the file name that includes the version of said file like "spring-core-2.0.99.jar" not just the plain "spring-core.jar" so its really clear to audit.

          You can suggest :-), but I'm not gonna do that. ;-)
          Those are Spring files as such, I don't wanna modify them in any way.
          And you can see the version in its manifest.mf file.

          • 2. Re: JBOSS5 + Spring Deployer version confusion
            dlmiles

            Thank for your prompt reply.

            I was able to turn on logging to see SpringParserDeployer and ApplicationContextDeployer being picked up by editing */conf/jboss-log4j.xml and adding:

            <category name="org.jboss.deployers">
             <priority value="DEBUG" />
             <appender-ref ref="CONSOLE"/>
            </category>
            


            Also for interest with those reading this thread (as of this time) Spring 2.0 is shipped with JBoss Spring Deployer 3.0. This saves you from downloading every version of Spring framework and comparing JARs until you find a match.


            I disagree you are not modifying the file by changing the filename by appending the version number like spring-core-2.0.8.jar but would support you stance if I was asking for the content to be modified (which I am not).

            I can also see that the MANIFEST of jboss-spring.deployer itself does not include its own version number and would also like to see jboss-spring.jar from inside the *.deployer file renamed to jboss-spring-3.0.jar (as well as version in the manifest). Both would be ideal and would save you documenting a README file about which version you built with this week.




            My next problem is that one or more Spring bean descriptors does not use XSD/Namespaces but DTD, is that allowed ?

            Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Failed to parse schema for nsURI=, baseURI=null, schemaLocation=http://www.springframework.org/dtd/spring-beans.dtd



            Now my remaining concern: I have a WAR in my EAR which currently has spring*.jar's inside (/WEB-INF/lib/*.jar) what is the correct way the package those ?

            If the JBoss deployer version (of Spring Framework) and the WAR version (of Spring Framework) were different, would there ever be a problem, I am thinking that the WAR container encapsulaltion will still work fine, since I would need to go to JNDI to obtain access to an ApplicationContext for any components deployed via JBoss Spring Deployer. Is my understanding correct on this ?


            • 3. Re: JBOSS5 + Spring Deployer version confusion
              alesj

               

              "dlmiles" wrote:

              I can also see that the MANIFEST of jboss-spring.deployer itself does not include its own version number and would also like to see jboss-spring.jar from inside the *.deployer file renamed to jboss-spring-3.0.jar (as well as version in the manifest). Both would be ideal and would save you documenting a README file about which version you built with this week.

              I'll fix the manifest.mf, to include the version.

              "dlmiles" wrote:

              My next problem is that one or more Spring bean descriptors does not use XSD/Namespaces but DTD, is that allowed ?

              It's up to Spring on what it does with the file.

              "dlmiles" wrote:

              Now my remaining concern: I have a WAR in my EAR which currently has spring*.jar's inside (/WEB-INF/lib/*.jar) what is the correct way the package those ?

              In theory it should play nicely.
              But see recent thread about the same problem.

              • 4. Re: JBOSS5 + Spring Deployer version confusion
                dlmiles

                 

                "dlmiles" wrote:
                Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Failed to parse schema for nsURI=, baseURI=null, schemaLocation=http://www.springframework.org/dtd/spring-beans.dtd


                I converted all my spring-beans.dtd to XSD (both in the web-app itself and all its included JARs from WEB-INF/lib, what a pain!). My guess on the problem here is that the XML parser is configured by JBoss (as it owns the XML parser and its configuration and supplies it to the JBoss Spring Deployer / Spring Framework). So I am thinking that either the JBoss Spring Deployer should supply a DTD resolver to the JBoss XML Parser that can locate the DTD from within the spring-beans.jar when necessary or Spring Framework is making presumptions about how the XML parser is already configured before it uses it.


                Anyway now moving onto my next problem.


                Are all the schemes that spring usually has setup (when running as a web-app in plain Tomcat; not Tomcat under JBoss), are they enabled and functional with respect to JBoss ? In particular the scheme handler for "classpath:" I have a:

                <bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
                 <property name="location">
                 <value>classpath:config/application.properties</value>
                 </property>
                </bean>


                But I'm getting the error:

                DEBUG [org.jboss.deployers.vfs.deployer.kernel.BeanDeployer] Parsed file: JarEntryHandler@28894583[path=Service.ear/Foobar.war/WEB-INF/spring-beans.xml context=file:/data/opt/jboss-5.0.0.Beta4/server/default/deploy/ real=jar:file:/data/opt/jboss-5.0.0.Beta4/server/default/tmp/javatmp/nestedjar19733.tmp!/WEB-INF/spring-beans.xml] to: classpath:/config/application.properties
                
                DEBUG [org.jboss.deployers.vfs.deployer.kernel.BeanDeployer] Error during deploy: vfsfile:/data/opt/jboss-5.0.0.Beta4/server/default/deploy/Service.ear/Foobar.war
                org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfsfile:/data/opt/jboss-5.0.0.Beta4/server/default/deploy/Service.ear/Foobar.war
                 at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
                
                ....SNIP....
                
                Caused by: java.lang.ClassCastException
                 at java.lang.Class.cast(Class.java:2951)
                 at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:136)



                • 5. Re: JBOSS5 + Spring Deployer version confusion
                  alesj

                   

                  "dlmiles" wrote:

                  Anyway now moving onto my next problem.

                  Are all the schemes that spring usually has setup (when running as a web-app in plain Tomcat; not Tomcat under JBoss), are they enabled and functional with respect to JBoss ? In particular the scheme handler for "classpath:" I have a:

                  <bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
                   <property name="location">
                   <value>classpath:config/application.properties</value>
                   </property>
                  </bean>


                  But I'm getting the error:

                  DEBUG [org.jboss.deployers.vfs.deployer.kernel.BeanDeployer] Parsed file: JarEntryHandler@28894583[path=Service.ear/Foobar.war/WEB-INF/spring-beans.xml context=file:/data/opt/jboss-5.0.0.Beta4/server/default/deploy/ real=jar:file:/data/opt/jboss-5.0.0.Beta4/server/default/tmp/javatmp/nestedjar19733.tmp!/WEB-INF/spring-beans.xml] to: classpath:/config/application.properties
                  
                  DEBUG [org.jboss.deployers.vfs.deployer.kernel.BeanDeployer] Error during deploy: vfsfile:/data/opt/jboss-5.0.0.Beta4/server/default/deploy/Service.ear/Foobar.war
                  org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfsfile:/data/opt/jboss-5.0.0.Beta4/server/default/deploy/Service.ear/Foobar.war
                   at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
                  
                  ....SNIP....
                  
                  Caused by: java.lang.ClassCastException
                   at java.lang.Class.cast(Class.java:2951)
                   at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:136)


                  Ah, yes, I though this one will come up sooner or later. :-)

                  This has nothing to do with Spring.
                  It's the way we deploy our Microcontainer beans.
                  BeanDeployer picks up any file that ends with -beans.xml, assuming that this is where MC beans are declared.
                  You can either rename the file or change the way BeanDeployer handles this file, e.g. perhaps not using the file if it also contains 'spring' in its name.

                  • 6. Re: JBOSS5 + Spring Deployer version confusion
                    dlmiles

                    Thank you for your replies again.

                    Picks up ? Ah I see the error is from the deployer trying to deploy something as a JBoss service which is actually contained inside my EAR which has a WAR and in my /WEB-INF/spring.beans.xml. I'm surprised it could find it, none of my containment files are exploded.


                    Surely there is some other qualifying requirement too. For example the *.deployer file name as well as requiring a META-INF/spring-deployers-beans.xml with outer element ?

                    I'm thinking that just having the name should never be enough but being the correct name and having a well formed data inside qualifies it for being picked up and special treatment. Anything not matching all of the requirements should elicit a warning and then be put back down (and ignored for further pickups until its timestamp changes again). The warning would be along the lines of foobar-bean.xml file does not contain outer element, ignoring file and returning.

                    Also if there is a clearly DTD or XSD described in the *-beans.xml for which the deployer does not understand then no warning should be emitted for INFO log level. But possible to see the attempted pickup at DEBUG level.


                    Now the next thing in the saga (not really spring related) :

                    vfsfile:/data/opt/jboss-5.0.0.Beta4/server/default/deploy/Service.ear -> org.xml.sax.SAXException: cvc-pattern-valid: Value 'application/xhtml+xml' is not facet-valid with respect to pattern '
                    [\p{L}\-\p{Nd}]+/[\p{L}\-\p{Nd}\.]+' for type 'null'. @ *unknown*[164,47][/core]
                    
                    I'm pretty sure this has been fixed in the Servlet web.xml DTD/XSD for a few years now, don't you just love validating parsers. Yes the plus character "+" is valid in a MIME type.


                    • 7. Re: JBOSS5 + Spring Deployer version confusion
                      alesj

                       

                      "dlmiles" wrote:

                      I'm surprised it could find it, none of my containment files are exploded.

                      It's called JBoss VFS. ;-)

                      "dlmiles" wrote:

                      Surely there is some other qualifying requirement too. For example the *.deployer file name as well as requiring a META-INF/spring-deployers-beans.xml with <deployment xmlns="urn:jboss:bean-deployer:2.0"> outer element ?

                      The file has to be in metadata path, recognized by StructureDeployers.

                      I don't know what you mean by *.deployers file name and requiring spring-deployers-beans.xml.

                      To require exact outer element, it means it would always have to parse the file, to see what is the first element.
                      I think the name + suffix are good enough to distinct deployment types.
                      And with the new aspectized deployers, it's easy to swap out the behavior / add additional constraints.

                      "dlmiles" wrote:

                      Now the next thing in the saga (not really spring related) :

                      vfsfile:/data/opt/jboss-5.0.0.Beta4/server/default/deploy/Service.ear -> org.xml.sax.SAXException: cvc-pattern-valid: Value 'application/xhtml+xml' is not facet-valid with respect to pattern '
                      [\p{L}\-\p{Nd}]+/[\p{L}\-\p{Nd}\.]+' for type 'null'. @ *unknown*[164,47][/core]
                      
                      I'm pretty sure this has been fixed in the Servlet web.xml DTD/XSD for a few years now, don't you just love validating parsers. Yes the plus character "+" is valid in a MIME type.

                      I think you can always say to the parsing deployer that it should not validate.
                      And this info should be delegated fwd.

                      • 8. Re: JBOSS5 + Spring Deployer version confusion
                        dlmiles

                         

                        "alesj" wrote:
                        "dlmiles" wrote:

                        Surely there is some other qualifying requirement too. For example the *.deployer file name as well as requiring a META-INF/spring-deployers-beans.xml with <deployment xmlns="urn:jboss:bean-deployer:2.0"> outer element ?

                        The file has to be in metadata path, recognized by StructureDeployers.

                        I don't know what you mean by *.deployers file name and requiring spring-deployers-beans.xml.

                        To require exact outer element, it means it would always have to parse the file, to see what is the first element.
                        I think the name + suffix are good enough to distinct deployment types.
                        And with the new aspectized deployers, it's easy to swap out the behavior / add additional constraints.


                        The point I was getting at, is that no deployer should mindlessly attempt to deploy all files it finds at any nesting depth ending in *-beans.xml. This is mindless madness.

                        But I would be happy for it to have a look at all files and then attempt to parse the file as a JBoss specific deployment descriptor. Now during this process it should immediately see that my file has an XML Schema that belongs to Spring Framework. Upon seeing this the deployer should stop considering that file as a JBoss deployment descriptor and no exception should be thrown.

                        This is the point of having XSDs to ensure an application that is not meant to process some data, does not attempt to process it!

                        The JBoss deployer does not own all the files ending in *-beans.xml that the JBoss VFS can find, it only own those files that also match the DTD/XSD schemes that JBoss understands.

                        Of course it has to parse the file, its bl**dy well doing that now is not it! The error I reported is due to a deployment failure because the contents of the XML appeared to be garbage to the MBean deployer when it attempted deployment.


                        Renaming my file in my WAR from /WEB-INF/spring-beans.xml to /WEB-INF/spring-context.xml did the trick.


                        "dlmiles" wrote:
                        I'm pretty sure this has been fixed in the Servlet web.xml DTD/XSD for a few years now, don't you just love validating parsers. Yes the plus character "+" is valid in a MIME type.


                        I have researched this issue and Tomcat 5.5.x has an updated web-app_2_4.xsd in servlet-api.jar but Tomcat 6.0.14 (the version I checked and the version shipped with JBoss AS 5.0.x) has not been updated. The Bugzilla ticket is at https://issues.apache.org/bugzilla/show_bug.cgi?id=44517 "web-app_2_4.xsd not up-to-date in TC6 servlet-api.jar"

                        For now I shall manually fix servlet-api.jar!javax/servlet/resources/web-app_2_4.xsd in my JBoss installation.

                        • 9. Re: JBOSS5 + Spring Deployer version confusion
                          dlmiles

                          See also http://jira.jboss.org/jira/browse/JBMETA-5 (which I believe to be the correct channel for updates to jboss-metadata.jar). The XSD validation is picking up the information contained in that JAR.

                          • 10. Re: JBOSS5 + Spring Deployer version confusion
                            alesj

                             

                            "dlmiles" wrote:

                            The point I was getting at, is that no deployer should mindlessly attempt to deploy all files it finds at any nesting depth ending in *-beans.xml.

                            It is not.
                            Like I said, only those that are in metadata path.
                            See StructureDeployers for more info.

                            "dlmiles" wrote:

                            But I would be happy for it to have a look at all files and then attempt to parse the file as a JBoss specific deployment descriptor. Now during this process it should immediately see that my file has an XML Schema that belongs to Spring Framework. Upon seeing this the deployer should stop considering that file as a JBoss deployment descriptor and no exception should be thrown.

                            This is the point of having XSDs to ensure an application that is not meant to process some data, does not attempt to process it!

                            The JBoss deployer does not own all the files ending in *-beans.xml that the JBoss VFS can find, it only own those files that also match the DTD/XSD schemes that JBoss understands.

                            Feel free to open this discussion in 'Deployers on JBoss' or 'Design of POJO server' forum.
                            No point of discussing this here, since this is getting out of the scope of this forum.

                            "dlmiles" wrote:

                            Of course it has to parse the file, its bl**dy well doing that now is not it!

                            :-)
                            The problem that I see here is, that most of the xml parsing/handling has the most awful exceptions, which would make it hard for us to distinguish between what's a real exception or just not the right combination of deployer+dtd/schema.

                            "dlmiles" wrote:

                            The error I reported is due to a deployment failure because the contents of the XML appeared to be garbage to the MBean deployer when it attempted deployment.

                            No, it failed because the BeanDeployer expected that the outcome of unmarshalling would be KernelDeployment instance.

                            "dlmiles" wrote:

                            Renaming my file in my WAR from /WEB-INF/spring-beans.xml to /WEB-INF/spring-context.xml did the trick.

                            "alesj" wrote:

                            You can either rename the file or change the way BeanDeployer handles this file, e.g. perhaps not using the file if it also contains 'spring' in its name.

                            ;-)

                            • 11. Re: JBOSS5 + Spring Deployer version confusion
                              enriquezrene

                              Hi, now I'm migrating an J2EE application from JBoss eap 4.3 to JBoss eap 5.1, and I have .spring file of the next way:

                               

                              application.jar

                               

                                   application-kernel.spring

                               

                                       META-INF/jboss-spring.xml

                               

                              when I try to use the bean factory I have the next error:

                               

                              javax.ejb.EJBException: NamingException al buscar el BeanFactory en el JNDI application-kernel: application-kernel not bound

                               

                               

                               

                              How can I be sure if the bean factory is available or if my .spring file was deployed?, excuse me for my bad english and many thanks advance