Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
On Jul 31, 2007, at 2:53 PM, Jarek Gawor wrote: On 7/31/07, Kevan Miller [EMAIL PROTECTED] wrote: OK. So, there are testsuite failures. I'm not seeing problems with other testing, however... I see why you removed the hidden-classes filter... Looks like we're in a bit of a Catch-22... I assume restructuring the spring-based configuration of cxf is pretty disruptive/potentially error-prone? Looks like some apps which include Spring and use jaxws could run into the same type of catch-22. Their only option would be to include the same version of spring that's used by our cxf module... Yes, I think so. But I could spend a day or two to see what it would take to configure CXF without Spring. I wasn't able to get this working. As described previously, I can get Spring apps deploying properly by filtering Spring classes and resources: hidden-classes filterorg.springframework./filter filterMETA-INF/spring/filter /hidden-classes However, this breaks CXF-based JAXWS client code. So, some Spring apps running on Jetty/CXF will require a deployment plan to perform the filtering. For 2.0.1, we should switch our CXF configuration to not use Spring. Also, we probably should create hidden-resources to our plans. So, above config would become: hidden-classes filterorg.springframework./filter /hidden-classes hidden-resources filterMETA-INF/spring/filter /hidden-resources --kevan
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
On Jul 25, 2007, at 2:23 PM, Aleksandr Tarutin (JIRA) wrote: java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder -- - Key: GERONIMO-3348 URL: https://issues.apache.org/jira/browse/ GERONIMO-3348 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0-M6 Environment: 2.6.18-gentoo-r2 #1 Sat Nov 11 03:36:37 EST 2006 i686 Pentium III (Katmai) GenuineIntel GNU/Linux JDK-1.5.0.12 Reporter: Aleksandr Tarutin This problem is caused by incompatibilities between the spring jars included within the cxf module and the spring jars included within the application. I think this is going to be a pretty common failure scenario. Rather than require a lot of Spring users to create a geronimo deployment plan, I'd like to add the necessary hidden- classes to the jetty6-deployer defaultEnvironment, namely: --- jetty6-deployer/src/plan/plan.xml (revision 560807) +++ jetty6-deployer/src/plan/plan.xml (working copy) @@ -130,7 +130,10 @@ typecar/type /dependency /dependencies -hidden-classes/ +hidden-classes +filterorg.springframework./filter +filterorg.apache.cxf./filter +/hidden-classes non-overridable-classes filterjava./filter filterjavax./filter I'm running some TCK tests, now. Assuming things look good, I'd like to commit to 2.0. Any objections? We could do nothing and require users to create a geronimo deployment plan which hides these same classes, instead. However, I'd like to make this scenario work out-of- the-box... Jarek has mentioned that with a bit of work, our cxf module need not be dependent on Spring configuration. This seems like a good idea. I'd certainly like to see the dependency dropped. However, don't see that happening in time for 2.0. --kevan
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
+1 -Donald Kevan Miller wrote: On Jul 25, 2007, at 2:23 PM, Aleksandr Tarutin (JIRA) wrote: java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder --- Key: GERONIMO-3348 URL: https://issues.apache.org/jira/browse/GERONIMO-3348 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0-M6 Environment: 2.6.18-gentoo-r2 #1 Sat Nov 11 03:36:37 EST 2006 i686 Pentium III (Katmai) GenuineIntel GNU/Linux JDK-1.5.0.12 Reporter: Aleksandr Tarutin This problem is caused by incompatibilities between the spring jars included within the cxf module and the spring jars included within the application. I think this is going to be a pretty common failure scenario. Rather than require a lot of Spring users to create a geronimo deployment plan, I'd like to add the necessary hidden-classes to the jetty6-deployer defaultEnvironment, namely: --- jetty6-deployer/src/plan/plan.xml(revision 560807) +++ jetty6-deployer/src/plan/plan.xml(working copy) @@ -130,7 +130,10 @@ typecar/type /dependency /dependencies -hidden-classes/ +hidden-classes +filterorg.springframework./filter +filterorg.apache.cxf./filter +/hidden-classes non-overridable-classes filterjava./filter filterjavax./filter I'm running some TCK tests, now. Assuming things look good, I'd like to commit to 2.0. Any objections? We could do nothing and require users to create a geronimo deployment plan which hides these same classes, instead. However, I'd like to make this scenario work out-of-the-box... Jarek has mentioned that with a bit of work, our cxf module need not be dependent on Spring configuration. This seems like a good idea. I'd certainly like to see the dependency dropped. However, don't see that happening in time for 2.0. --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
On Jul 31, 2007, at 8:44 AM, Kevan Miller wrote: I'm running some TCK tests, now. Assuming things look good, I'd like to commit to 2.0. Any objections? We could do nothing and require users to create a geronimo deployment plan which hides these same classes, instead. However, I'd like to make this scenario work out-of-the-box... +1 I agree this would be good for 2.0. Pluto 1.2 uses spring to configure itself so I experienced some of these problems first hand while setting up the new dynamic console framework. Like you say, in most cases users can probably work around it with hidden-class filters or arranging their modules in a certain way. But that's not entirely straight forward and can limit their options with respect to how their application can be deployed. Spring applications should work out of the box. Best wishes, Paul
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
+1 (assuming it doesn't affect TCK) ;-) Joe Kevan Miller wrote: On Jul 25, 2007, at 2:23 PM, Aleksandr Tarutin (JIRA) wrote: java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder --- Key: GERONIMO-3348 URL: https://issues.apache.org/jira/browse/GERONIMO-3348 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0-M6 Environment: 2.6.18-gentoo-r2 #1 Sat Nov 11 03:36:37 EST 2006 i686 Pentium III (Katmai) GenuineIntel GNU/Linux JDK-1.5.0.12 Reporter: Aleksandr Tarutin This problem is caused by incompatibilities between the spring jars included within the cxf module and the spring jars included within the application. I think this is going to be a pretty common failure scenario. Rather than require a lot of Spring users to create a geronimo deployment plan, I'd like to add the necessary hidden-classes to the jetty6-deployer defaultEnvironment, namely: --- jetty6-deployer/src/plan/plan.xml(revision 560807) +++ jetty6-deployer/src/plan/plan.xml(working copy) @@ -130,7 +130,10 @@ typecar/type /dependency /dependencies -hidden-classes/ +hidden-classes +filterorg.springframework./filter +filterorg.apache.cxf./filter +/hidden-classes non-overridable-classes filterjava./filter filterjavax./filter I'm running some TCK tests, now. Assuming things look good, I'd like to commit to 2.0. Any objections? We could do nothing and require users to create a geronimo deployment plan which hides these same classes, instead. However, I'd like to make this scenario work out-of-the-box... Jarek has mentioned that with a bit of work, our cxf module need not be dependent on Spring configuration. This seems like a good idea. I'd certainly like to see the dependency dropped. However, don't see that happening in time for 2.0. --kevan
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
I'm +1 on the testing this out. I seem to remember that a while ago I've had some problems with CXF when the hidden-classes/ was actually enabled for Spring classes in the Jetty config but maybe it will work better now. See: http://www.mail-archive.com/dev@geronimo.apache.org/msg41202.html. Please also run the testsuite/webservices-testsuite/jaxws-tests/jaxws-*/ tests to verify that everything works ok after the change. But I have a few comments on this change in general. First, why are we adding the hidden-classes/ bits for Spring and CXF only? Aren't we in the same boat with other libraries, e.g. Axis2, Commons Logging, etc.? Also, I think the hidden-classes/ change should go into both Tomcat and Jetty configs (since for example the Tomcat assembly could be switched to run CXF). Jarek On 7/31/07, Kevan Miller [EMAIL PROTECTED] wrote: On Jul 25, 2007, at 2:23 PM, Aleksandr Tarutin (JIRA) wrote: java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder -- - Key: GERONIMO-3348 URL: https://issues.apache.org/jira/browse/ GERONIMO-3348 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0-M6 Environment: 2.6.18-gentoo-r2 #1 Sat Nov 11 03:36:37 EST 2006 i686 Pentium III (Katmai) GenuineIntel GNU/Linux JDK-1.5.0.12 Reporter: Aleksandr Tarutin This problem is caused by incompatibilities between the spring jars included within the cxf module and the spring jars included within the application. I think this is going to be a pretty common failure scenario. Rather than require a lot of Spring users to create a geronimo deployment plan, I'd like to add the necessary hidden- classes to the jetty6-deployer defaultEnvironment, namely: --- jetty6-deployer/src/plan/plan.xml (revision 560807) +++ jetty6-deployer/src/plan/plan.xml (working copy) @@ -130,7 +130,10 @@ typecar/type /dependency /dependencies -hidden-classes/ +hidden-classes +filterorg.springframework./filter +filterorg.apache.cxf./filter +/hidden-classes non-overridable-classes filterjava./filter filterjavax./filter I'm running some TCK tests, now. Assuming things look good, I'd like to commit to 2.0. Any objections? We could do nothing and require users to create a geronimo deployment plan which hides these same classes, instead. However, I'd like to make this scenario work out-of- the-box... Jarek has mentioned that with a bit of work, our cxf module need not be dependent on Spring configuration. This seems like a good idea. I'd certainly like to see the dependency dropped. However, don't see that happening in time for 2.0. --kevan
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
On Jul 31, 2007, at 10:47 AM, Jarek Gawor wrote: I'm +1 on the testing this out. I seem to remember that a while ago I've had some problems with CXF when the hidden-classes/ was actually enabled for Spring classes in the Jetty config but maybe it will work better now. See: http://www.mail-archive.com/dev@geronimo.apache.org/msg41202.html. Please also run the testsuite/webservices-testsuite/jaxws-tests/jaxws-*/ tests to verify that everything works ok after the change. But I have a few comments on this change in general. First, why are we adding the hidden-classes/ bits for Spring and CXF only? Aren't we in the same boat with other libraries, e.g. Axis2, Commons Logging, etc.? Also, I think the hidden-classes/ change should go into both Tomcat and Jetty configs (since for example the Tomcat assembly could be switched to run CXF). Yes, there is always an exposure for problems with parent libraries. As you might expect, what libraries are exposed to client applications has been discussed, before... You could make a case that we should offer a simple configuration mode where we offer only strict EE interfaces to client applications, default would remain our current behavior. I don't see this happening for 2.0. As to why treat Spring differently: 1. Spring is especially prone to version incompatibilities. We only include spring core, context, and beans jars in the cxf module. Since most apps will have additional Spring jar files, we are exposed to problems caused by method signature incompatibilities. 2. Spring problems are what have shown up on our user list/jiras. Yes. I had the same filters in the tomcat deployer... --kevan
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
On Jul 31, 2007, at 10:47 AM, Jarek Gawor wrote: I'm +1 on the testing this out. I seem to remember that a while ago I've had some problems with CXF when the hidden-classes/ was actually enabled for Spring classes in the Jetty config but maybe it will work better now. See: http://www.mail-archive.com/dev@geronimo.apache.org/msg41202.html. Please also run the testsuite/webservices-testsuite/jaxws-tests/jaxws-*/ tests to verify that everything works ok after the change. OK. So, there are testsuite failures. I'm not seeing problems with other testing, however... I see why you removed the hidden-classes filter... Looks like we're in a bit of a Catch-22... I assume restructuring the spring-based configuration of cxf is pretty disruptive/potentially error-prone? Looks like some apps which include Spring and use jaxws could run into the same type of catch-22. Their only option would be to include the same version of spring that's used by our cxf module... --kevan
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
On 7/31/07, Kevan Miller [EMAIL PROTECTED] wrote: OK. So, there are testsuite failures. I'm not seeing problems with other testing, however... I see why you removed the hidden-classes filter... Looks like we're in a bit of a Catch-22... I assume restructuring the spring-based configuration of cxf is pretty disruptive/potentially error-prone? Looks like some apps which include Spring and use jaxws could run into the same type of catch-22. Their only option would be to include the same version of spring that's used by our cxf module... Yes, I think so. But I could spend a day or two to see what it would take to configure CXF without Spring. Jarek
[jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
java.lang.NoSuchMethodError in
org.springframework.context.i18n.LocaleContextHolder
---
Key: GERONIMO-3348
URL: https://issues.apache.org/jira/browse/GERONIMO-3348
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.0-M6
Environment: 2.6.18-gentoo-r2 #1 Sat Nov 11 03:36:37 EST 2006 i686
Pentium III (Katmai) GenuineIntel GNU/Linux
JDK-1.5.0.12
Reporter: Aleksandr Tarutin
When deploying and running [Proximity|http://proximity.abstracthorizon.org/] it
works without any problem in geronimo-1.1.1. But when the same application is
deployed to 2.0-M6 following exception is thrown:
{noformat}
15:57:53,267 INFO [DirectoryHotDeployer] Deploying proximity
15:57:56,690 WARN [JettyModuleBuilder] Web application . 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.
15:58:04,709 WARN [JspModuleBuilderExtension] Invalid transformed taglib
org.apache.xmlbeans.XmlException: Invalid deployment descriptor: errors:
jar:file:/opt/geronimo-jetty6-jee5-2.0-M6/repository/default/proximity/1185307073730/proximity-1185307073730.war/WEB-INF/lib/bsf-2.3.0.jar!/META-INF/taglib.tld:15:3:
error: cvc-datatype-valid.1.1: string value 'BSF JSP Support' does not match
pattern for tld-canonical-nameType in namespace
http://java.sun.com/xml/ns/javaee
Descriptor:
!--a tab library descriptor--
taglib xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; version=2.1
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
!--after this the default space is
http://java.sun.com/j2ee/dtds/jsptaglibrary_1_2.dtd--
tlib-version2.0/tlib-version
short-nameBSF JSP Support/short-name
urihttp://jakarta.apache.org/taglibs//uri
tag
namescriptlet/name
tag-classorg.apache.taglibs.bsf.scriptlet/tag-class
body-contenttagdependent/body-content
attribute
namelanguage/name
requiredtrue/required
/attribute
/tag
tag
nameexpression/name
tag-classorg.apache.taglibs.bsf.expression/tag-class
body-contenttagdependent/body-content
attribute
namelanguage/name
requiredtrue/required
/attribute
/tag
/taglib
at
org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.validateDD(XmlBeansUtil.java:218)
at
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.convertToTaglibSchema(JspModuleBuilderExtension.java:675)
at
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.parseTldFile(JspModuleBuilderExtension.java:433)
at
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.getListenerClasses(JspModuleBuilderExtension.java:420)
at
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.createJspClassFinder(JspModuleBuilderExtension.java:180)
at
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.addGBeans(JspModuleBuilderExtension.java:149)
at
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension$$FastClassByCGLIB$$1f60ab3b.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:828)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.j2ee.deployment.ModuleBuilderExtension$$EnhancerByCGLIB$$6720f345.addGBeans(generated)
at
org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:484)
at
org.apache.geronimo.jetty6.deployment.JettyModuleBuilder$$FastClassByCGLIB$$1a00be84.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:828)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
