geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
Date Tue, 31 Jul 2007 12:44:32 GMT

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: 
>              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-
>             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 @@
-                <hidden-classes/>
+                <hidden-classes>
+                    <filter>org.springframework.</filter>
+                    <filter>org.apache.cxf.</filter>
+                </hidden-classes>

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- 

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.


View raw message