Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder

[Donald Woods]

+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

JDK-1.5.0.12

            Reporter: Aleksandr Tarutin

Environment: 2.6.18-gentoo-r2 #1 Sat Nov 11 03:36:37 EST 2006 i686 Pentium III (Katmai) GenuineIntel GNU/Linux

--- jetty6-deployer/src/plan/plan.xml    (revision 560807)
+++ jetty6-deployer/src/plan/plan.xml    (working copy)
@@ -130,7 +130,10 @@
                         <type>car</type>
                     </dependency>
                 </dependencies>
-                <hidden-classes/>
+                <hidden-classes>
+                    <filter>org.springframework.</filter>
+                    <filter>org.apache.cxf.</filter>
+                </hidden-classes>
                 <non-overridable-classes>
                     <filter>java.</filter>
                     <filter>javax.</filter>





--kevan

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: 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.

smime.p7s
Description: S/MIME Cryptographic Signature