geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wallace <rwall...@thewallacepack.net>
Subject Re: Global Spring ApplicationContext
Date Thu, 12 Apr 2007 16:50:27 GMT
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.  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?

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.createArgumentArray(ConstructorResolver.java:422)
>         at
> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:140)
>         at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:773)
>         at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:716)
>         at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:386)
>         at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251)
>         at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.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/%3C21c9d60d0701300301s6ece788bm2431eb6278956b0f@mail.gmail.com%3E.
>   
>>> But as mentioned in another post
>>>
>>>       
> (http://mail-archives.apache.org/mod_mbox/geronimo-user/200612.mbox/%3cA99F00E9A39CF5428039DE37B2069B2107D280E5@atlmaiexcp02.iss.net%3e),
>   
>>> 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
>>>
>>>       
> [org.springframework.context.support.ClassPathXmlApplicationContext@6be45d];
>   
>>> 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.createDefaultNamespaceHandlerResolver(XmlBeanDefinitionReader.java:489)
>   
>>> at
>>>
>>>       
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createReaderContext(XmlBeanDefinitionReader.java:478)
>   
>>> at
>>>
>>>       
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:458)
>   
>>> at
>>>
>>>       
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:353)
>   
>>> at
>>>
>>>       
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:303)
>   
>>> at
>>>
>>>       
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:280)
>   
>>> at
>>>
>>>       
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:131)
>   
>>> at
>>>
>>>       
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:147)
>   
>>> at
>>>
>>>       
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:173)
>   
>>> at
>>>
>>>       
> org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:112)
>   
>>> at
>>>
>>>       
> org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:79)
>   
>>> at
>>>
>>>       
> org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:100)
>   
>>> at
>>>
>>>       
> org.springframework.context.support.AbstractApplicationContext.refresh(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.initWebApplicationContext(ContextLoader.java:180)
>   
>>> at
>>>
>>>       
> org.springframework.web.context.ContextLoaderListener.contextInitialized(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.lifecycleCommand(AbstractImmutableHandler.java:52)
>   
>>> at
>>>
>>>       
> org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.lifecycleCommand(ThreadClassloaderHandler.java:57)
>   
>>> at
>>>
>>>       
> org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCommand(AbstractImmutableHandler.java:50)
>   
>>> at
>>>
>>>       
> org.apache.geronimo.jetty6.handler.ComponentContextHandler.lifecycleCommand(ComponentContextHandler.java:57)
>   
>>> at
>>>
>>>       
> org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCommand(AbstractImmutableHandler.java:50)
>   
>>> at
>>>
>>>       
> org.apache.geronimo.jetty6.handler.InstanceContextHandler.lifecycleCommand(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
>>>       
>
>
>   


Mime
View raw message