Re: Global Spring ApplicationContext

Thu, 12 Apr 2007 10:10:12 -0700 


On Apr 12, 2007, at 9:50 AM, Richard Wallace wrote:


I think I found the source of the problem described below.  I've tried
deploying a simple ear with a webapp that has the following jsp

<html>
  <head>
    <title>Hidden Classes Test</title>
  </head>
  <body bgcolor="white">
    <%
Object o = new org.apache.xbean.propertyeditor.ArrayListEditor (); 
      out.println (o);
    %>
  </body>
</html>

I tested this with Geronimo 1.1.  I copied the
repository/org/apache/xbean directory to my Geronimo 1.1 repository from 
my Geronimo 2.0-M3 installation.  If I leave the
geronimo-application.xml file without any hidden-classes or
dependencies, this JSP won't compile because
"org.apache.xbean.propertyeditor.ArrayListEditor cannot be resolved to a type". To get it to work in Geronimo 1.1 I have to manually specify in 
the geronimo-application.xml that I want to use the xbean-reflect
package in the Geronimo 1.1 repository.

In Geronimo 2.0-M3, it appears as tho everything in the Geronimo
repository is available to the application.
No. What is happening is that xbean-reflect is used in the web container whose classloader is a parent of your app's classloader. 


So, when I deploy the
application and hit the above JSP, it is able to successfully create the 
ArrayListEditor, even when there are no dependencies listed in the
geronimo-application.xml file. It also seems that if I try to hide the 
package with this geronimo-application.xml file

<?xml version="1.0" encoding="UTF-8"?>
<application
  xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-1.2";>
  <environment
    xmlns="http://geronimo.apache.org/xml/ns/deployment-1.2";>
    <moduleId>
      <groupId>${pom.groupId}</groupId>
      <artifactId>${pom.artifactId}</artifactId>
      <version>${version}</version>
      <type>ear</type>
    </moduleId>
    <hidden-classes>
      <filter>org.apache.xbean</filter>
    </hidden-classes>
  </environment>

</application>
the JSP is able to compile and run just fine, leading me to believe that 
the hidden-classes in my geronimo-application.xml file are being
ignored.  Am I missing something or is this a bug?
I think that if you exclude the class in a geronimo-web.xml it will be successfully excluded. It's getting pulled in from the web container's classloader which is a parent of the web app classloader but not the ear classloader. 

Hope I'm right and this helps :-)
david jencks



Thanks,
Rich

Richard Wallace wrote:

I'm trying to get the full Geronimo 2 working just for my own
edification and am still running into some problems.  I tried just
disabling the cxf stuff, but it seemed to keep getting reenabled.  I
uninstalled it and got past that problem.  Now I'm running into a
problem with the xbean library.  I'm getting the following:
org.springframework.beans.factory.access.BootstrapException: Unable to 
initialize group definition. Group resource name
[classpath:/shared-context.xml], factory key [shared-context]; nested
exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'shared-context' defined in class path
resource [shared-context.xml]: Instantiation of bean failed; nested
exception is org.apache.xbean.propertyeditor.PropertyEditorException:
Value is not an instance of String
Caused by:
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'shared-context' defined in class path
resource [shared-context.xml]: Instantiation of bean failed; nested
exception is org.apache.xbean.propertyeditor.PropertyEditorException:
Value is not an instance of String
Caused by:
org.apache.xbean.propertyeditor.PropertyEditorException: Value is not
an instance of String
        at
org.apache.xbean.propertyeditor.AbstractConverter.setValue (AbstractConverter.java:67) 
        at
org.springframework.beans.TypeConverterDelegate.doConvertValue (TypeConverterDelegate.java:269) 
        at
org.springframework.beans.TypeConverterDelegate.convertIfNecessary (TypeConverterDelegate.java:192) 
        at
org.springframework.beans.TypeConverterDelegate.convertIfNecessary (TypeConverterDelegate.java:107) 
        at
org.springframework.beans.BeanWrapperImpl.convertIfNecessary (BeanWrapperImpl.java:356) 
        at
org.springframework.beans.factory.support.ConstructorResolver.createA rgumentArray(ConstructorResolver.java:422) 
        at
org.springframework.beans.factory.support.ConstructorResolver.autowir eConstructor(ConstructorResolver.java:140) 
        at
org.springframework.beans.factory.support.AbstractAutowireCapableBean Factory.autowireConstructor (AbstractAutowireCapableBeanFactory.java:773) 
        at
org.springframework.beans.factory.support.AbstractAutowireCapableBean Factory.createBeanInstance(AbstractAutowireCapableBeanFactory.java: 716) 
        at
org.springframework.beans.factory.support.AbstractAutowireCapableBean Factory.createBean(AbstractAutowireCapableBeanFactory.java:386) 
        at
org.springframework.beans.factory.support.AbstractBeanFactory $1.getObject(AbstractBeanFactory.java:251) 
        at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistr y.getSingleton(DefaultSingletonBeanRegistry.java:144) 
        at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:248) 
        at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:160) 
        at
org.springframework.beans.factory.support.DefaultListableBeanFactory. preInstantiateSingletons(DefaultListableBeanFactory.java:279)
I tried adding using the following plan to deploy the EAR file, but it 
didn't seem to change anything.

<?xml version="1.0" encoding="UTF-8"?>
<application
  xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-1.1";
  xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1";
  xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1";
  application-name="ExampleApp">
  <sys:environment>
    <sys:moduleId>
      <sys:groupId>com.contentconnections.guts</sys:groupId>
      <sys:artifactId>example-app</sys:artifactId>
      <sys:version>0.1-SNAPSHOT</sys:version>
      <sys:type>car</sys:type>
    </sys:moduleId>
    <sys:hidden-classes>
      <sys:filter>org.springframework</sys:filter>
      <sys:filter>org.hibernate</sys:filter>
      <sys:filter>org.apache.cxf</sys:filter>
      <sys:filter>org.apache.xbean</sys:filter>
    </sys:hidden-classes>
  </sys:environment>

</application>

Any hints, or should I maybe stick with Little-G for now?

Thanks,
Rich

David Jencks wrote:


I think you should try turning off cxf support in
var/config/config.xml by adding load="false" to the module for
cxf-builder.  That ought to eliminate cxf from your classpath.

Not an ideal solution but it should work.

cxf is producing new snapshots every day or two so if you build
trunk you may also find this problem solved.

You might be able to use hidden-classes to get around this problem.


thanks david jencks

On Apr 11, 2007, at 9:40 AM, Richard Wallace wrote:



Hello again,

I've decided to try a completely different tact than what I was
trying before.  Rather than try and create a bunch of special
GBeans I noticed from a couple of places
(http://forum.springframework.org/showthread.php? t=14200&highlight=locatorFactorySelector 


mainly) that Spring has support for this sort of thing sorta
baked in. The only trick is to get that global context in a root
classloader so that it can be shared.

I tried this by putting the jars in a classpath entry in the ear
MANIFEST.MF file as mentioned here
http://mail-archives.apache.org/mod_mbox/geronimo-user/200701.mbox/ [EMAIL PROTECTED] 


But as mentioned in another post
(http://mail-archives.apache.org/mod_mbox/geronimo-user/ 200612.mbox/% [EMAIL PROTECTED]), 


this leads to everything being loaded in separate classloaders
per webapp.

So, this lead me to the discovery of the JEE5 support for the
/lib directory inside an EAR that will load all the jars into a
parent classpath that all modules can use.  I downloaded
geronimo-jetty6-jee5-2.0-M3, started it up, and deployed my EAR
with the spring and all my application code in the root lib
directory.

Spring failed to load.  Here's the stack trace.

09:04:55,548 WARN  [JettyModuleBuilder] Web application
example-webapp-0.1-SNAPSHOT.war does not contain a
WEB-INF/geronimo-web.xml deployment plan.  This may or may not be
a problem, depending on whether you have things like resource
references that need to be resolved.  You can also give the
deployer a separate deployment plan file on the command line.
09:04:55,615 WARN  [JettyModuleBuilder] Web application
example-webapp2.war does not contain a WEB-INF/geronimo-web.xml
deployment plan.  This may or may not be a problem, depending on
whether you have things like resource references that need to be
resolved. You can also give the deployer a separate deployment
plan file on the command line. 2007-04-11
09:04:56.535:/example:INFO:  Initializing Spring root
WebApplicationContext 09:04:56,535 INFO  [ContextLoader] Root
WebApplicationContext: initialization started 09:04:56,592 INFO
[ClassPathXmlApplicationContext] Refreshing
org.springframework.context.support.ClassPathXmlApplicationContext@ 6be45d: 


display name
[EMAIL PROTECTED] be45d]; 


startup date [Wed Apr 11 09:04:56 MST 2007]; root of context
hierarchy 09:04:56,725 INFO  [XmlBeanDefinitionReader] Loading
XML bean definitions from class path resource
[shared-context.xml] 09:04:58,850 ERROR [ContextLoader] Context
initialization failed
org.springframework.beans.factory.access.BootstrapException:
Unable to initialize group definition. Group resource name
[classpath:/shared-context.xml], factory key [shared-context];
nested exception is
org.springframework.beans.factory.BeanDefinitionStoreException:
Unexpected exception parsing XML document from class path
resource [shared-context.xml]; nested exception is
java.lang.IllegalArgumentException: Class
[org.apache.cxf.transport.http.spring.NamespaceHandler] does not
implement the NamespaceHandler interface Caused by:
org.springframework.beans.factory.BeanDefinitionStoreException:
Unexpected exception parsing XML document from class path
resource [shared-context.xml]; nested exception is
java.lang.IllegalArgumentException: Class
[org.apache.cxf.transport.http.spring.NamespaceHandler] does not
implement the NamespaceHandler interface Caused by:
java.lang.IllegalArgumentException: Class
[org.apache.cxf.transport.http.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.createD efaultNamespaceHandlerResolver(XmlBeanDefinitionReader.java:489) 


at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createR eaderContext(XmlBeanDefinitionReader.java:478) 


at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registe rBeanDefinitions(XmlBeanDefinitionReader.java:458) 


at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadB eanDefinitions(XmlBeanDefinitionReader.java:353) 


at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBea nDefinitions(XmlBeanDefinitionReader.java:303) 


at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBea nDefinitions(XmlBeanDefinitionReader.java:280) 


at
org.springframework.beans.factory.support.AbstractBeanDefinitionReade r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:131) 


at
org.springframework.beans.factory.support.AbstractBeanDefinitionReade r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:147) 


at
org.springframework.beans.factory.support.AbstractBeanDefinitionReade r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:173) 


at
org.springframework.context.support.AbstractXmlApplicationContext.loa dBeanDefinitions(AbstractXmlApplicationContext.java:112) 


at
org.springframework.context.support.AbstractXmlApplicationContext.loa dBeanDefinitions(AbstractXmlApplicationContext.java:79) 


at
org.springframework.context.support.AbstractRefreshableApplicationCon text.refreshBeanFactory(AbstractRefreshableApplicationContext.java: 100) 


at
org.springframework.context.support.AbstractApplicationContext.refres h(AbstractApplicationContext.java:313) 


at
org.springframework.context.access.ContextSingletonBeanFactoryLocator .initializeDefinition(ContextSingletonBeanFactoryLocator.java:137) 


at
org.springframework.beans.factory.access.SingletonBeanFactoryLocator. useBeanFactory(SingletonBeanFactoryLocator.java:381) 


at
org.springframework.web.context.ContextLoader.loadParentContext (ContextLoader.java:311) 


at
org.springframework.web.context.ContextLoader.initWebApplicationConte xt(ContextLoader.java:180) 


at
org.springframework.web.context.ContextLoaderListener.contextInitiali zed(ContextLoaderListener.java:49) 


at
org.mortbay.jetty.handler.ContextHandler.startContext (ContextHandler.java:511) 


at
org.mortbay.jetty.servlet.Context.startContext(Context.java:135)
at
org.mortbay.jetty.webapp.WebAppContext.startContext (WebAppContext.java:1191) 


at
org.mortbay.jetty.handler.ContextHandler.doStart (ContextHandler.java:481) 


at
org.mortbay.jetty.webapp.WebAppContext.doStart (WebAppContext.java:434) 
 at
org.mortbay.component.AbstractLifeCycle.start (AbstractLifeCycle.java:40) 


at
org.apache.geronimo.jetty6.JettyWebAppContext $StartCommand.lifecycleMethod(JettyWebAppContext.java:355) 


at
org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycle Command(AbstractImmutableHandler.java:52) 


at
org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.lifecycle Command(ThreadClassloaderHandler.java:57) 


at
org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycle Command(AbstractImmutableHandler.java:50) 


at
org.apache.geronimo.jetty6.handler.ComponentContextHandler.lifecycleC ommand(ComponentContextHandler.java:57) 


at
org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycle Command(AbstractImmutableHandler.java:50) 


at
org.apache.geronimo.jetty6.handler.InstanceContextHandler.lifecycleCo mmand(InstanceContextHandler.java:81) 



The problem seems to be that the class
org.apache.cxf.transport.http.spring.NamespaceHandler doesn't
implement the Spring NamespaceHandler interface.  Having no idea
where that even came from I google'd "cxf apache" and found the
Apache CXF project in the incubator.  I browsed the SVN repo and
eventually found this,
http://svn.apache.org/viewvc/incubator/cxf/trunk/rt/transports/ http/src/main/java/org/apache/cxf/transport/http/spring/ NamespaceHandler.java?revision=501982&view=markup. 



It looks like they have recently moved to supporting Spring more
directly/easily, at least that's what I infer from the comment.
So my hope is that a new milestone of Geronimo would include a
newer version of the CXF library and would fix this issue.  Do
you guys think that might to be the case?  If so, in the
meantime, is there anything I can do that would allow me to
workaround this issue?  If not, I'll fall back and try the dummy
ejb method that was mentioned in one of the threads I linked to.

Thanks, Rich

Reply via email to