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/[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 >>> > > >