Announcement Announcement Module
Collapse

JavaConfig forum decommissioned in favor of Core Container

As described at

http://static.springsource.org/sprin...fig/README.TXT

key features of the Spring JavaConfig project have been migrated into the core Spring Framework as of version 3.0.

Please see the Spring 3.0 documentation on @Configuration and @Bean support:

http://static.springsource.org/sprin...tml#beans-java

For any questions related to @Configuration classes and @Bean methods in Spring 3.0, please post in the dedicated 'Core Container' forum at

http://forum.springsource.org/forumdisplay.php?f=26
See more
See less
Spring 3.0M2 + Javaconfig 1.0.0M4 ASM problems Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring 3.0M2 + Javaconfig 1.0.0M4 ASM problems

    Been playing around with Spring 3.0 for the REST stuff, and decided to take Javaconfig for a spin too.

    Looks like I'm running into the ASM problem, we had until you guys JarJar'd it into Spring 2.5.1.

    Does spring 3.0 use this same trick? I think I've got just about all the bundles included. And I'm still running into it.

    Is there another workaround?

    -kyri

    Code:
    ERROR - ContextLoader.initWebApplicationContext(219) | Context initialization failed
    java.lang.NoClassDefFoundError: org/springframework/asm/ClassVisitor
    	at org.springframework.config.java.internal.factory.support.AsmJavaConfigBeanDefinitionReader.loadBeanDefinitions(AsmJavaConfigBeanDefinitionReader.java:65)
    	at org.springframework.config.java.internal.process.InternalConfigurationPostProcessor.parseAnyConfigurationClasses(InternalConfigurationPostProcessor.java:128)
    	at org.springframework.config.java.internal.process.InternalConfigurationPostProcessor.postProcessBeanFactory(InternalConfigurationPostProcessor.java:76)
    	at org.springframework.config.java.context.JavaConfigWebApplicationContext.invokeBeanFactoryPostProcessors(JavaConfigWebApplicationContext.java:80)
    	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:358)
    	at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:254)
    	at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:198)
    	at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47)
    	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3843)
    	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4342)
    	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
    	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
    	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
    	at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:830)
    	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:515)
    	at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1231)
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    	at java.lang.reflect.Method.invoke(Method.java:585)
    	at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297)
    	at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
    	at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
    	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
    	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
    	at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1471)
    	at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:645)
    	at org.apache.catalina.manager.ManagerServlet.doPut(ManagerServlet.java:432)
    	at javax.servlet.http.HttpServlet.service(HttpServlet.java:640)
    	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
    	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
    	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568)
    	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)

  • #2
    Hi Kyri,

    Sorry - this is a temporary incompatibility between the two projects. As Juergen mentioned on the blog recently, we will be re-packaging asm in 3.0M3, but until then, this little problem is going to keep cropping up.

    As a stopgap, you could just include org.springframework.core v2.5.6 on your classpath (make sure it's included *after* 3.0M2!), and this will make the org.springframework.asm classes available once again.

    Sorry for the inconvenience!

    - Chris

    P.S.: Regarding JavaConfig, stay tuned for 3.0M3 - @Configuration classes and @Bean methods will be supported right in the core.

    Comment


    • #3
      I found this post helped me fix this issue for the time-being.

      I have a modular project, with DAO/Service layer and Web (Spring MVC) layer in separate Maven subprojects. In my DAO/Service layer, I excluded asm, asm-attrs and cglib from my Hibernate dependency, and explicitly added asm, asm-all, asm-commons (2.2.3) and cglib-nodep (2.1_3) dependencies. My Web (Spring MVC) layer has the DAO/Service layer as a dependency.

      This appears to have resolved this issue for me.
      Last edited by alexbcoles; Mar 21st, 2009, 07:23 AM. Reason: Fixed grammar, explained web layer

      Comment


      • #4
        FYI, the repackaged org.springframework.asm packaging has just been re-introduced into the Spring 3.0 trunk, so the latest nightly snapshots will 'just work' against JavaConfig 1.0.0.M4 without any extra fuss.

        Comment


        • #5
          Integrate Groovy as expression language

          I was looking into Spring 3.0M3 documentation http://static.springsource.org/sprin...html/ch07.html

          Its mentioned there "SpEL is based on an technology agnostic API allowing other expression language implementations to be integreated should the need arise."

          I want to integrate Groovy script as my scripting language.

          Please provide me some hints.

          Why? We are building Claim processing system using Spring/Spring Batch/Spring Integration/EclipseLink/Oracle Coherence. In our product one can specify conditions as Groovy Script in the DB. The Claim processing picks these script and based on the outcome next processing steps are executed.
          Like claimLine.provider == 'Hospital' do ... if claimLine.provide == 'person' do ....

          Comment


          • #6
            Originally posted by mgorav View Post
            I was looking into Spring 3.0M3 documentation http://static.springsource.org/sprin...html/ch07.html

            Its mentioned there "SpEL is based on an technology agnostic API allowing other expression language implementations to be integreated should the need arise."

            I want to integrate Groovy script as my scripting language.

            Please provide me some hints.

            Why? We are building Claim processing system using Spring/Spring Batch/Spring Integration/EclipseLink/Oracle Coherence. In our product one can specify conditions as Groovy Script in the DB. The Claim processing picks these script and based on the outcome next processing steps are executed.
            Like claimLine.provider == 'Hospital' do ... if claimLine.provide == 'person' do ....
            Where are you wanting to use the expressions?

            The expression layer defines the interfaces Expression and ExpressionParser - but currently we only provide the SpelExpression and SpelAntlrExpressionParser implementations. Supporting another language/syntax requires implementation of those two interfaces.

            Spring then works with the expression parser implementation through StandardBeanExpressionResolver (an implementation of BeanExpressionResolver). So to plugin your alternate implementation of the parser, change the BeanExpressionResolver that is being used via the call:

            beanFactory.setBeanExpressionResolver(...)

            (the factory being accessible through the context). I'm not sure yet if we are going to find time before 3.0 ships to flesh out how to do this or provide alternate implementations.

            Andy Clement
            Senior Software Engineer, SpringSource

            Comment


            • #7
              Thanks for reply.

              Aim of using expression language - Groovy Script
              ====================================
              We are aiming to use Spring Batch for Claim Processing. Within the Claim Processing we provide ability to externalize conditions as Groovy Scripts, which alter the flow of Claim Processing. These Groovy Scripts are stored in the DB (as they are subject to alterations)
              SB 2.0 provide ability to alter the flow processing based on conditions. I like to Spring 3.0 feature which lets us use the expressions. I was envisioning to extend this concept inline with our business requirements/case
              So in conditional steps of the SB we can provide these conditions
              like execute step1 if #context....xxxxx==true
              This context is local to thread and provide ability to set these while processing.
              If we integrate groovy (which in our business case is the expression language of choice) than Spring 3.0 will also like it. (I understood by default the expression language is SPEL)

              Looking forward to more valuable insights. May be if you have some sample JUnit test case which I can refer, it will be really nice
              Last edited by mgorav; May 21st, 2009, 05:39 AM.

              Comment


              • #8
                Yes, I think groovy would be a good script language to support behind the expression evaluation interface. If we consider (as is definetly the case in parts of the syntax) SpEL as a kind of mini subset of what groovy can do, then many of the same tests for SpEL should pass for a groovy implementation. The tests are mostly in here:

                https://fisheye.springsource.org/bro...xpression/spel

                And for an example, here are the boolean tests that ought to work just fine for groovy too.

                https://fisheye.springsource.org/bro...sionTests.java

                The only lines that should need changing are in the supertype, where it creates a SpelExpressionParser() it should create a GroovyExpressionParser() so that is used instead.

                Comment

                Working...
                X