9 Replies Latest reply on Sep 25, 2013 2:11 PM by ksutton

    AS 7.1.1 to EAP 6.1 Migration of OWF

    ksutton Newbie

      I'm in the process of migrating a customized OWF application from JBoss AS 7.1.1 to JBoss EAP 6.1.  I've copied over the war & the modules, and I've updated the configuration & start scripts as far as I can tell is needed.  The issue seems to be that the resources imported by the Spring resources.xml, which exist under a particular JBoss module's path, are not loaded.

       

      Here's the /WEB-INF/spring/resources.xml, which tries to import the OWF config files:

      <?xml version="1.0" encoding="UTF-8"?>
      <beans xmlns="http://www.springframework.org/schema/beans"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
          <import resource="classpath*:*OWFsecurityContext*.xml" />
          <import resource="classpath*:OwfConfig.xml" />
      </beans>
      
      

       

      Here's a clip from the log output from the working deployment in AS 7.1.1, showing that the first log statement after loading the resources.xml is the loading of the imported OWFsecurityContext_JBoss.xml file:

      15:23:03,277 INFO  [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] (MSC service thread 1-5) Loading XML bean definitions from ServletContext resource [/WEB-INF/spring/resources.xml]

      15:23:03,518 INFO  [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] (MSC service thread 1-5) Loading XML bean definitions from file [/opt/jboss/default/modules/com/mycompany/owf/main/./OWFsecurityContext_JBoss.xml]

       

      Here's a clip from the log output from the non-working deployment in EAP 6.1; the OWF resource import never happens afterwards:

      15:19:28,424 INFO  [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] (ServerService Thread Pool -- 68) Loading XML bean definitions from ServletContext resource [/WEB-INF/spring/resources.xml]

      15:19:28,836 INFO  [org.codehaus.groovy.grails.plugins.orm.hibernate.HibernatePluginSupport] (ServerService Thread Pool -- 68) Set db generation strategy to 'none'

       

      No exceptions or errors are reported until much later on, when this possibly-related exception is thrown:

      15:19:33,738 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/owf]] (ServerService Thread Pool -- 68) JBWEB000284: Exception starting filter springSecurityFilterChain: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'springSecurityFilterChain' is defined

          at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:527) [org.springframework.context.support-3.0.5.RELEASE.jar:3.0.5.RELEASE]

          at org.springframework.beans.factory.support.AbstractBeanFactory.getMergedLocalBeanDefinition(AbstractBeanFactory.java:1083) [org.springframework.context.support-3.0.5.RELEASE.jar:3.0.5.RELEASE]

          at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:274) [org.springframework.context.support-3.0.5.RELEASE.jar:3.0.5.RELEASE]

          at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194) [org.springframework.context.support-3.0.5.RELEASE.jar:3.0.5.RELEASE]

          at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:266) [org.springframework.context.support-3.0.5.RELEASE.jar:3.0.5.RELEASE]

          at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194) [org.springframework.context.support-3.0.5.RELEASE.jar:3.0.5.RELEASE]

          at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1079) [org.springframework.context-3.0.5.RELEASE.jar:3.0.5.RELEASE]

          at org.springframework.web.filter.DelegatingFilterProxy.initDelegate(DelegatingFilterProxy.java:217) [org.springframework.web-3.0.5.RELEASE.jar:3.0.5.RELEASE]

          at org.springframework.web.filter.DelegatingFilterProxy.initFilterBean(DelegatingFilterProxy.java:145) [org.springframework.web-3.0.5.RELEASE.jar:3.0.5.RELEASE]

          at org.springframework.web.filter.GenericFilterBean.init(GenericFilterBean.java:179) [org.springframework.web-3.0.5.RELEASE.jar:3.0.5.RELEASE]

          at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:416) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]

          at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3225) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]

          at org.apache.catalina.core.StandardContext.start(StandardContext.java:3791) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]

          at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

          at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

          at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

          at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) [rt.jar:1.6.0_41]

          at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_41]

          at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_41]

          at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_41]

          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_41]

          at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_41]

          at org.jboss.threads.JBossThread.run(JBossThread.java:122)

       

      I've tried renaming the OWFsecurityContext_JBoss.xml file, to see if a resource-not-found error is generated, but none is.  The file is located under /opt/jboss/default/modules/com/mycompany/owf/main.  I'm wondering if the modules directory was part of the classpath in AS 7.1.1 but no longer is in EAP 6.1; or is there something else I'm missing?

       

      Is there any way to print out what classpath is in effect at the point the Spring resources.xml file is loaded?

       

      Thanks,

      Kyle Sutton

       

       

       

      UPDATE:  Basically, the wildcards used on the right side of the import resource aren't supported directly by JBoss.  They're supported through Snowdrop, and, as in this particular application's case (I'm guessing), Grails.  Since my overall goal is to migrate & load test the app, and not to dig down into the configuration, I've just removed the wildcards and now the application works fine.  The issue was probably that I didn't copy over some necessary Grails components or configuration from the AS 7.1.1 deployment, but I'm content to just get on with the load testing...

        • 1. Re: AS 7.1.1 to EAP 6.1 Migration of OWF
          Tomaz Cerar Master

          hi,

           

          how do you add /opt/jboss/default/modules to module path?

          • 2. Re: AS 7.1.1 to EAP 6.1 Migration of OWF
            ksutton Newbie

            I'm assuming it's done by the -mp option in standalone.sh.

             

            Here are the relevant output lines from the server.log of the non-working EAP deployment:

             

                java.class.path = /opt/jboss/default/jboss-modules.jar

                java.library.path = /usr/java/jdk1.6.0_41/jre/lib/amd64/server:/usr/java/jdk1.6.0_41/jre/lib/amd64:/usr/java/jdk1.6.0_41/jre/../lib/amd64::/usr/lib:/usr/lib64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

                jboss.modules.dir = /opt/jboss/default/modules

                jboss.modules.system.pkgs = org.jboss.byteman

                module.path = /opt/jboss/default/modules

                sun.boot.class.path = /usr/java/jdk1.6.0_41/jre/lib/resources.jar:/usr/java/jdk1.6.0_41/jre/lib/rt.jar:/usr/java/jdk1.6.0_41/jre/lib/sunrsasign.jar:/usr/java/jdk1.6.0_41/jre/lib/jsse.jar:/usr/java/jdk1.6.0_41/jre/lib/jce.jar:/usr/java/jdk1.6.0_41/jre/lib/charsets.jar:/usr/java/jdk1.6.0_41/jre/lib/modules/jdk.boot.jar:/usr/java/jdk1.6.0_41/jre/classes

                sun.java.command = /opt/jboss/default/jboss-modules.jar -mp /opt/jboss/default/modules -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -Djboss.home.dir=/opt/jboss/default -Djboss.server.base.dir=/opt/jboss/default/standalone -P=/opt/jboss/default/standalone/configuration/reddisk.properties

             

            Here's the same cut from the working AS 7.1.1 deployment:

             

                java.class.path = /opt/jboss/default/jboss-modules.jar

                java.library.path = /usr/java/jdk1.6.0_41/jre/lib/amd64/server:/usr/java/jdk1.6.0_41/jre/lib/amd64:/usr/java/jdk1.6.0_41/jre/../lib/amd64::/usr/lib:/usr/lib64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

                jboss.modules.dir = /opt/jboss/default/modules

                jboss.modules.system.pkgs = org.jboss.byteman

                module.path = /opt/jboss/default/modules

                sun.boot.class.path = /usr/java/jdk1.6.0_41/jre/lib/resources.jar:/usr/java/jdk1.6.0_41/jre/lib/rt.jar:/usr/java/jdk1.6.0_41/jre/lib/sunrsasign.jar:/usr/java/jdk1.6.0_41/jre/lib/jsse.jar:/usr/java/jdk1.6.0_41/jre/lib/jce.jar:/usr/java/jdk1.6.0_41/jre/lib/charsets.jar:/usr/java/jdk1.6.0_41/jre/lib/modules/jdk.boot.jar:/usr/java/jdk1.6.0_41/jre/classes

                sun.java.command = /opt/jboss/default/jboss-modules.jar -mp /opt/jboss/default/modules -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -Djboss.home.dir=/opt/jboss/default -P=/opt/jboss/default/standalone/configuration/reddisk.properties

             

            Thanks,

            Kyle

            • 3. Re: AS 7.1.1 to EAP 6.1 Migration of OWF
              Tomaz Cerar Master

              Everything around startup looks ok.

               

              can you post contents of your /com/mycompany/owf/main

               

              and module.xml .

               

               

              --

              tomaz

              • 4. Re: AS 7.1.1 to EAP 6.1 Migration of OWF
                ksutton Newbie

                modules/com/mycompany/owf/main listing:

                 

                total 48

                drwxr-xr-x 10 webadmin webadmin 4096 Aug 27 16:58 help

                drwxr-xr-x  3 webadmin webadmin 4096 Aug 27 16:58 js-plugins

                -rw-r--r--  1 webadmin webadmin  231 Sep 20 16:42 module.xml

                -rw-r--r--  1 webadmin webadmin 2450 Jul 25 04:43 MPsecurityContext.xml

                -rw-r--r--  1 webadmin webadmin 4354 Aug 27 16:58 OwfConfig.groovy

                -rw-r--r--  1 webadmin webadmin 5797 Jul 25 04:43 owf-override-log4j.xml

                -rw-r--r--  1 webadmin webadmin 2096 Jul 25 04:43 OWFsecurityContext_JBoss.xml

                -rw-r--r--  1 webadmin webadmin  737 Jul 25 04:43 OzoneConfig.properties

                drwxr-xr-x  2 webadmin webadmin 4096 Aug 27 16:58 ozone-security-beans

                drwxr-xr-x  2 webadmin webadmin 4096 Aug 27 16:58 themes

                 

                 

                modules/com/mycompany/owf/main/module.xml

                 

                <?xml version="1.0" encoding="UTF-8"?>

                <module xmlns="urn:jboss:module:1.1" name="com.mycompany.owf">

                    <resources>

                        <resource-root path="."/>

                    </resources>

                    <dependencies>

                    </dependencies>

                </module>

                 

                 

                Thanks,

                Kyle

                • 5. Re: AS 7.1.1 to EAP 6.1 Migration of OWF
                  Tomaz Cerar Master

                  It mostly luck that it even worked in 7.1.1.

                   

                  create folder "resources" or something like that.

                  then move all your files there (except for module.xml)

                  and change resource-root to

                   

                  <resource-root path="resources"/>

                  • 6. Re: AS 7.1.1 to EAP 6.1 Migration of OWF
                    ksutton Newbie

                    Same result.

                     

                    Is there some debug logging that could show what JBoss is trying to load or where it is looking for those configuration files?

                     

                    Thanks,

                    Kyle

                    • 7. Re: AS 7.1.1 to EAP 6.1 Migration of OWF
                      ksutton Newbie

                      So, I've managed to get past the first hurdle in the AS 7.1.1 to EAP 6.1 migration effort.  After running strace and seeing no hits for the OWFsecurityContext_JBoss.xml file, I changed the reference to the file in the Spring resources.xml file.  The following worked:

                       

                      <import resource="classpath*:OWFsecurityContext_JBoss.xml" />
                      

                       

                      ...the following attempts did not:

                       

                      <import resource="classpath*:*OWFsecurityContext*.xml" />
                      

                       

                      <import resource="classpath*:OWFsecurityContext*.xml" />
                      

                       

                      <import resource="classpath*:OWFsecurityContext.*.xml" />
                      

                       

                      <import resource="classpath*:OWFsecurityContext_JBoss.xml*" />
                      

                       

                      <import resource="classpath*:*OWFsecurityContext_JBoss.xml" />
                      

                       

                      It seems that wildcards don't work for searching for Spring config files in the classpath.  This did work in AS 7.1.1, with what I believe is the same Spring configuration & libraries.  Is this just a case of me not transferring all of the required Spring components over correctly, or has something changed in the way JBoss interacts with Spring or classpath searching?

                      1 of 1 people found this helpful
                      • 8. Re: AS 7.1.1 to EAP 6.1 Migration of OWF
                        Tomaz Cerar Master

                        Kyle Sutton wrote:

                        This did work in AS 7.1.1, with what I believe is the same Spring configuration & libraries.  Is this just a case of me not transferring all of the required Spring components over correctly, or has something changed in the way JBoss interacts with Spring or classpath searching?

                        Noting in particular, did you maybe had snowdrop extension installed on your old 7.1.1 instance?

                        btw, did you try to use latest version of spring? As i know they improved a bit in way they integrate with AS7.

                        • 9. Re: Re: AS 7.1.1 to EAP 6.1 Migration of OWF
                          ksutton Newbie

                          The AS 7.1.1 instance did have snowdrop installed as a module, though the configuration didn't look like it was using it.  The config file entries seemed to be making reference to Grails components instead.  I haven't looked into it too much, since removing the wildcards caused the application to load successfully.

                           

                          However, now, when I try to hit an OWF page, I get this in the logs:

                          17:20:52,548 ERROR [com.mycompany.sso.SSOTokenValidatorLoginModule] (ajp-/0.0.0.0:8009-1) problem during validation of sso token: org.apache.commons.lang.SerializationException: java.lang.ClassNotFoundException: com.mycompany.sso.SubjectWrapper from [Module "org.apache.commons.lang:main" from local module loader @68a0864f (finder: local module finder @2d1e233 (roots: /opt/jboss/default/modules,/opt/jboss/default/modules/system/layers/base))]

                              at org.apache.commons.lang.SerializationUtils.deserialize(SerializationUtils.java:166) [commons-lang-2.6-redhat-2.jar:2.6-redhat-2]

                              at org.apache.commons.lang.SerializationUtils.deserialize(SerializationUtils.java:193) [commons-lang-2.6-redhat-2.jar:2.6-redhat-2]

                              at com.mycompany.sso.cache.access.impl.SubjectSerializer.deserializeSubject(SubjectSerializer.java:27) [web-sso.jar:]

                              at com.mycompany.sso.cache.access.impl.HTTPCacheAccess.getCachedSubject(HTTPCacheAccess.java:89) [web-sso.jar:]

                              at com.mycompany.sso.SSOTokenValidatorLoginModule.login(SSOTokenValidatorLoginModule.java:80) [web-sso.jar:]

                          ...

                          Caused by: java.lang.ClassNotFoundException: com.mycompany.sso.SubjectWrapper from [Module "org.apache.commons.lang:main" from local module loader @68a0864f (finder: local module finder @2d1e233 (roots: /opt/jboss/default/modules,/opt/jboss/default/modules/system/layers/base))]

                              at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]

                          ...

                           

                          The weird part is that the class that it can't find, com.mycompany.sso.SubjectWrapper, is in the same web-sso.jar as the com.mycompany.sso.SSOTokenValidatorLoginModule referenced in the stack trace above.  Here's a cut from the class listing of the jar in question:

                          # jar tvf /opt/jboss/default/modules/com/mycompany/login/main/web-sso.jar

                          ...

                            4341 Thu Aug 15 18:17:50 GMT 2013 com/mycompany/sso/SSOTokenValidatorLoginModule.class

                            1804 Thu Aug 15 18:17:50 GMT 2013 com/mycompany/sso/valve/ResponseForwarderValve.class

                             703 Thu Aug 15 18:17:50 GMT 2013 com/mycompany/sso/valve/CatalinaRequestWrapper.class

                            2496 Thu Aug 15 18:17:50 GMT 2013 com/mycompany/sso/CacheUtils.class

                            2170 Thu Aug 15 18:17:50 GMT 2013 com/mycompany/sso/misc/PropertiesUtility.class

                            2344 Thu Aug 15 18:17:50 GMT 2013 com/mycompany/sso/SubjectWrapper.class

                             638 Thu Aug 15 18:17:50 GMT 2013 web-sso.properties

                          ...

                           

                          Any idea how one class file from a jar could be successfully loaded, while the other is unable to be found at runtime?  Would some kind of class load failure of one of the classes in between the two cause the class loader to stop processing the jar and not load SubjectWrapper...or maybe a failure in SubjectWrapper itself?  There are no other logged errors in boot-up or otherwise, just this one when a login is attempted.

                           

                          Thanks,

                          Kyle