Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-M6, 2.0
    • Fix Version/s: 2.0.2, 2.1
    • Component/s: None
    • Security Level: public (Regular issues)
    • Labels:
      None
    • Environment:

      Description

      1. This Geronimo build includes spring-beans.jar, spring-context.jar and spring-core.jar of version 2.0.
      So as far as we know, version 2.0 does not fully support integration with JPA implementations.

      2. We developed an enterprise application (ear) which utilizes Spring 2.0.2 and OpenJPA.
      OpenJPA comes with Geronimo.

      Deployment and start of this application fails, because of different versions of Spring (our application expects spring-beans.jar, spring-context.jar and spring-core.jar to be at least of version 2.0.2 but Geronimo contains libs of version 2.0 (the lack of some methods in version 2.0 is the problem here).

      3. If we try to use inverse-classloading or hidden classes (org.springframework) in geronimo-web.xml and include all necesary libs in WEB-INF/lib following Exception is thrown during deployment and start of the application (see below).

      4. We found temporary workaround: to replace spring-beans.jar, spring-context.jar and spring-core.jar of version 2.0 with jars of version 2.0.2 in Geronimo repository without using of inverse-classloading and hidden classes and everything looks fine.

      5. So as far as I understand this out-of-the-box Geronimo build could not be used as Server for Spring-OpenJPA appications. At least Spring libs upgrade could solve this problem.
      6. Another problem is following Exception when using hidden classes or inverse-classloading to load application jars first.

      ERROR [ContextLoader] Context initialization failed
      org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/springAppContext.xml]; nested exception is java.lang.IllegalArgumentException: Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface
      Caused by:
      java.lang.IllegalArgumentException: Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface
      at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.initHandlerMappings(DefaultNamespaceHandlerResolver.java:119)
      at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.<init>(DefaultNamespaceHandlerResolver.java:96)
      at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.<init>(DefaultNamespaceHandlerResolver.java:82)
      at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createDefaultNamespaceHandlerResolver(XmlBeanDefinitionReader.java:526)
      at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createReaderContext(XmlBeanDefinitionReader.java:515)
      at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:495)
      at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
      at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:340)
      at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:317)
      at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:125)
      at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:141)
      at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:123)
      at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:91)
      at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:94)
      at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:292)
      at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:156)
      at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:246)
      at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184)
      at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49)
      at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3823)
      at org.apache.catalina.core.StandardContext.start(StandardContext.java:4324)
      at org.apache.geronimo.tomcat.GeronimoStandardContext.access$201(GeronimoStandardContext.java:62)
      at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:350)
      at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
      at org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:194)
      at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
      at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
      at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
      at org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:333)
      at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke(<generated>)
      at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
      at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
      at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
      at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:828)
      at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
      at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
      at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
      at org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$9425c889.addContext(<generated>)
      at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:517)
      at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:994)
      at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
      at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
      at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:537)
      at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111)
      at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146)
      at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)
      at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173)
      at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41)
      at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251)
      at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294)
      at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
      at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
      at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:551)
      at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
      at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:442)
      at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:479)
      at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188)
      at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530)
      at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:511)
      at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(<generated>)
      at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
      at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
      at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
      at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:828)
      at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
      at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
      at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
      at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$7a707602.startConfiguration(<generated>)
      at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:67)
      at java.lang.Thread.run(Thread.java:595)

        Issue Links

          Activity

          Alexei Kozich created issue -
          Hide
          Donald Woods added a comment -

          BTW - Spring is only being included for WADI, which is only in the Jetty assembly.
          My thoughts are that we shouldn't include Spring in any of the Geronimo assemblies, as we will never have the most current version available that our users will want.....

          Show
          Donald Woods added a comment - BTW - Spring is only being included for WADI, which is only in the Jetty assembly. My thoughts are that we shouldn't include Spring in any of the Geronimo assemblies, as we will never have the most current version available that our users will want.....
          Hide
          Paul McMahan added a comment -

          I agree with Donald that including spring in the geronimo assemblies can cause problems when users want to use a different version of spring. I think its OK to include the spring jars in the repository but not OK for apps deployed into geronimo to automatically inherit spring as a dependency. i.e. users should be able to deploy their own spring based app without having to worry about setting up <hidden-class> filters.

          Show
          Paul McMahan added a comment - I agree with Donald that including spring in the geronimo assemblies can cause problems when users want to use a different version of spring. I think its OK to include the spring jars in the repository but not OK for apps deployed into geronimo to automatically inherit spring as a dependency. i.e. users should be able to deploy their own spring based app without having to worry about setting up <hidden-class> filters.
          Hide
          Matt Hogstrom added a comment -

          I agree with the approach Paul. Suggestions on solving this ?

          Show
          Matt Hogstrom added a comment - I agree with the approach Paul. Suggestions on solving this ?
          Hide
          Paul McMahan added a comment -

          Well I could have sworn that webapps I deployed into Geronimo were at one time picking up a Spring dependency from some place but that no longer seems to be the case. Maybe instead of Spring it was a Castor dependency that I'm thinking of? Webapps automatically inherit org.exolab.castor.* from axis->openejb, and that tends to interfere with webapps that use castor for processing XML like pluto's portal driver.

          Show
          Paul McMahan added a comment - Well I could have sworn that webapps I deployed into Geronimo were at one time picking up a Spring dependency from some place but that no longer seems to be the case. Maybe instead of Spring it was a Castor dependency that I'm thinking of? Webapps automatically inherit org.exolab.castor.* from axis->openejb, and that tends to interfere with webapps that use castor for processing XML like pluto's portal driver.
          Hide
          Jarek Gawor added a comment -

          CXF uses Spring to configure itself. I'm pretty sure it is possible to remove that dependency from CXF but it would require some extra work.

          Show
          Jarek Gawor added a comment - CXF uses Spring to configure itself. I'm pretty sure it is possible to remove that dependency from CXF but it would require some extra work.
          Hide
          Paul McMahan added a comment -

          thanks Jarek, The classloader viewer in the admin console doesn't show any spring classes pulled in by CXF but maybe that view is not accurate If so then is there any way for webapps to avoid getting a cxf/axis dependency when they don't contain any web services? that might be a helpful first step we could take, if removing the Spring dependency from CXF proves difficult.

          Show
          Paul McMahan added a comment - thanks Jarek, The classloader viewer in the admin console doesn't show any spring classes pulled in by CXF but maybe that view is not accurate If so then is there any way for webapps to avoid getting a cxf/axis dependency when they don't contain any web services? that might be a helpful first step we could take, if removing the Spring dependency from CXF proves difficult.
          Hide
          Gianny Damour added a comment -

          I confirm that the cxf config pulls 2.0 Spring dependencies; also, Spring is not included for WADI as per Donald's comment.

          I have been able to run a Web-app depending on Spring dependencies having a version greater than 2.0 by:

          • reversing classloading; and
          • hidding NamespaceHandler implementation classes defined by cxf: Spring simply logs a debug message when a declared NamespaceHandler implementation class cannot be loaded.

          So, by adding this to your web-app geronimo DD, you can run your web-app:

          <hidden-classes>
          <filter>org.apache.cxf</filter> <!-- -This can also be the exhaustive list of NamespaceHandler implementations declared by CXF ->
          </hidden-classes>

          <inverse-classloading/>

          Show
          Gianny Damour added a comment - I confirm that the cxf config pulls 2.0 Spring dependencies; also, Spring is not included for WADI as per Donald's comment. I have been able to run a Web-app depending on Spring dependencies having a version greater than 2.0 by: reversing classloading; and hidding NamespaceHandler implementation classes defined by cxf: Spring simply logs a debug message when a declared NamespaceHandler implementation class cannot be loaded. So, by adding this to your web-app geronimo DD, you can run your web-app: <hidden-classes> <filter>org.apache.cxf</filter> <!-- -This can also be the exhaustive list of NamespaceHandler implementations declared by CXF -> </hidden-classes> <inverse-classloading/>
          Hide
          Daniel Kulp added a comment -

          CXF does use spring. However, we pull in 2.0.4 (and work fine with 2.0.5). I'm not sure where the 2.0 version would be coming from.

          Show
          Daniel Kulp added a comment - CXF does use spring. However, we pull in 2.0.4 (and work fine with 2.0.5). I'm not sure where the 2.0 version would be coming from.
          Jarek Gawor made changes -
          Field Original Value New Value
          Link This issue relates to GERONIMO-3348 [ GERONIMO-3348 ]
          Hide
          Kevan Miller added a comment -

          We should fix this in 2.0.1 by rebasing our CXF configuration to a non-Spring solution. Until then, you can use a Geronimo deployment plan to avoid the problem. Something like:

          <?xml version="1.0" encoding="UTF-8"?>
          <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1" xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1" xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1">
          <dep:environment>
          <dep:moduleId>
          <dep:groupId>org.mygroup</dep:groupId>
          <dep:artifactId>MyApp</dep:artifactId>
          <dep:version>1.1</dep:version>
          <dep:type>car</dep:type>
          </dep:moduleId>
          <!--
          Don't load spring classes or spring resources from parent ClassLoaders.
          -->
          <hidden-classes>
          <filter>org.springframework.</filter>
          <filter>META-INF/spring</filter>
          </hidden-classes>

          </dep:environment>

          </web-app>

          Show
          Kevan Miller added a comment - We should fix this in 2.0.1 by rebasing our CXF configuration to a non-Spring solution. Until then, you can use a Geronimo deployment plan to avoid the problem. Something like: <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1" xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1" xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1"> <dep:environment> <dep:moduleId> <dep:groupId>org.mygroup</dep:groupId> <dep:artifactId>MyApp</dep:artifactId> <dep:version>1.1</dep:version> <dep:type>car</dep:type> </dep:moduleId> <!-- Don't load spring classes or spring resources from parent ClassLoaders. --> <hidden-classes> <filter>org.springframework.</filter> <filter>META-INF/spring</filter> </hidden-classes> </dep:environment> </web-app>
          Kevan Miller made changes -
          Affects Version/s 2.0 [ 12312600 ]
          Fix Version/s 2.0.x [ 12312601 ]
          Hide
          Kevan Miller added a comment -

          This has been fixed in branches/2.0 (574686) and trunk (574694). So, should be fixed in Geronimo 2.0.2 and 2.1

          Show
          Kevan Miller added a comment - This has been fixed in branches/2.0 (574686) and trunk (574694). So, should be fixed in Geronimo 2.0.2 and 2.1
          Kevan Miller made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 2.1 [ 12312602 ]
          Resolution Fixed [ 1 ]
          Fix Version/s 2.0.2 [ 12312731 ]
          Fix Version/s 2.0.x [ 12312601 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Alexei Kozich
            • Votes:
              3 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development