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/[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 >>>>> [EMAIL PROTECTED]: >>>>> >>>>> >>>>> >>>>> >>>>> display name >>>>> >>>>> >>> [EMAIL PROTECTED]; >>> >>> >>> >>>>> 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 >>>>> >>> >>> >>> >> >
