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 18:23:39 GMT
David Jencks wrote:
>
> 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.

Alright, so I tried adding the following geronimo-web.xml to the
WEB-INF of the webapp:

<?xml version="1.0" encoding="UTF-8"?>
<web-app
  xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.2">
  <environment xmlns="http://geronimo.apache.org/xml/ns/deployment-1.2">
    <moduleId>
      <groupId>com.contentconnections.spikes</groupId>
      <artifactId>hidden-classes-webapp</artifactId>
    </moduleId>
    <hidden-classes>
      <filter>org.apache.xbean</filter>
    </hidden-classes>
  </environment>
</web-app>

And the JSP still compiles.  Is my formatting for the filter correct?
> 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.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