11 Replies Latest reply on Jul 11, 2007 6:29 AM by Ales Justin

    jboss-spring.xml beans location

    thorsten maus Newbie

      Hi there ..

      am trying to deploy a formerly created spring application into jboss ( spring deployer properly installed )

      my spring app covers its own bean definitions ...

      in order to keep them at a single location i simply added a
      definition to the jboss-spring.xml.

      The server log reveals that the application is loading my beans properly. Accessing them during runtime from within an ejb using @Spring leads to a nullpointer exception. Analyzing this fact led me to the following problem:

      DEBUG [org.jboss.spring.interceptor.SpringInjectionInterceptor] Injecting bean 'catalogService' of class type $Proxy168 into foo.bar.ejb.DefaultCatalogServiceStateless@ce4dda v
      ia private foo.bar.service.CatalogService foo.bar.ejb.DefaultCatalogServiceStateless.catalogService

      Placing the catalogBean directly into the jboss-spring.xml solves the upper mentioned problem.

      2007-07-05 16:41:01,664 DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] Returning cached instance of singleton bean 'catalogService'
      2007-07-05 16:41:01,664 DEBUG [org.jboss.spring.interceptor.SpringInjectionInterceptor] Injecting bean 'catalogService' of class type foo.bar.service.DefaultCatalogService into foo.bar.ejb.De
      faultCatalogServiceStateless@6fa22b via private foo.bar.service.CatalogService foo.bar..ejb.DefaultCatalogServiceStateless.catalogService

      Any idea why this happens ???

        • 1. Re: jboss-spring.xml beans location
          Ales Justin Master

          What happens?
          I don't see what is this catalogBean that 'solved' the problem?

          • 2. Re: jboss-spring.xml beans location
            thorsten maus Newbie

            sorry .. badly explained ..

            tow scenarios:

            1. the target bean is directly embedded into the jboss-spring.xml looking like:
            <bean id="catalogService" class="foo.bar.service.DefaultCatalogService"\>

            everything works fine here ... of course .. as its the described way ..


            2. the bean is referenced inside the jboss-spring.xml via an import tag:
            \<import resource="classpath:catalog-beans.xml"/\>

            The catalog-beans.xml is located inside the spring deployable package, accessable via classpath and it really get processed on server / ear startup.
            ( [org.springframework.aop.framework.JdkDynamicAopProxy] Creating JDK dynamic proxy for [foo.bar.service.DefaultCatalogService]
            )


            The important difference between both scenarios can be seen in the SpringInectionInterceptor output.

            Scenario one outputs:
            ==============
            Injecting bean 'catalogService' of class type foo.bar.service.DefaultCatalogService into foo.bar.ejb.DefaultCatalogServiceStateless@6fa22b via private foo.bar.service.CatalogService foo.bar..ejb.DefaultCatalogServiceStateless.catalogService

            Scnenario two, which does not work outputs:
            ============================
            Injecting bean 'catalogService' of class type $Proxy168 into foo.bar.ejb.DefaultCatalogServiceStateless@ce4dda v
            ia private foo.bar.service.CatalogService foo.bar.ejb.DefaultCatalogServiceStateless.catalogService

            The injected class types differ. In the working scenario the SpringInjectionInterceptor is using an existing class, whereas it is using a proxy class in the none working scenario.

            And this is the problem im facing ....

            Hope you understood what i meant

            :O)

            • 3. Re: jboss-spring.xml beans location
              Ales Justin Master

              I understand a bit more ...
              Weird, don't know what the deal is with the proxy.

              You can still try separating the catalog beans with parent-child architecture.
              This is supported by SpringDeployer - see the instructions for setting this hierarchy.

              • 4. Re: jboss-spring.xml beans location
                thorsten maus Newbie

                thanks for the help alesj ...

                I was setting up a prototype to investigate if a spring application which resides and runs in a catalina container could be easily moved and embedded into a plain jboss application server .

                Development and testing of services in tomcat environment is faster and easier as in jboss.

                The services would have been migrated into the jboss using your deployer and accessed using injection in stateless session beans.

                As the way I wanted things to work ( spring deployed package accepts additional bean definition files, recognizes them and can use them in runtime ) does not work, I think I have to stop the evaluation.

                Anyways .. thanks for your help and congrats for this impressive approach to embed spring into jboss

                • 5. Re: jboss-spring.xml beans location
                  Ales Justin Master

                   

                  "loumaus" wrote:

                  Anyways .. thanks for your help and congrats for this impressive approach to embed spring into jboss

                  NP. Thanks for trying it out.

                  Be sure to check out the impressive features we have installed for you with new Microcontainer 2.x - new Spring-int module and a lot lot more ... ;-).


                  • 6. Re: jboss-spring.xml beans location
                    thorsten maus Newbie

                    well .. still not giving it up ..

                    my jboss-spring.xml looks like the following

                    <beans>
                    ..
                    ..
                    <bean id="catalogDao" class="foo.bar.dao.DefaultCatalogDao" />
                    
                    <bean id="catalogService" class="foo.bar.service.DefaultCatalogService" >
                     <property name="catalogDao" ref="catalogDao"/>
                    </bean>
                    ..
                    
                    



                    My stateless session bean covers a private object like

                    @Spring(..)
                    private CatalogService catalogService
                    


                    This works out fine ...
                    My simple jar based ( and spring deployer deployed ) target class is properly referenced by my stateless session bean. ( ssb gets injected and uses the reference )

                    The DefaultCatalogService covers a private object:
                    private CatalogDao catalogDao ( setter is available as well )
                    

                    This one should be injected during spring startup ....
                    but it definately does not ..
                    Catching an exception reveals that it has not been injected (Nullpointer ).

                    Again like some messages before I can see in the logs that the bean is properly created:
                    (Creating instance of bean 'catalogDao' with merged definition [Root bean: class [foo.bar.dao.Defaul
                    tCatalogDao]; scope=singleton; abstract=false; lazyInit=false; autowireCandidate=true; autowireMode=0; dependencyCheck=0; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=nu
                    ll; defined in URL [jar:file:/home/tmaus/server/jboss-4.0.5.GA/server/default/tmp/deploy/tmp14056catalog.ear-contents/catalog-spring.spring!/META-INF/jboss-spring.xml]]
                    2007-07-06 16:15:34,897 DEBUG [org.springframework.beans.CachedIntrospectionResults] Not strongly caching class [foo.bar.dao.DefaultCatalogDao] because it is not cache-safe
                    )
                    

                    so .. my question on this topic is ..

                    I can see that the complete spring framework gets properly instantiated, started and it configures everything properly ( it did so as well with the other spring beans which could not be referenced as described in former message )
                    Due to the fact that the dao does not get properly injected, I assume that the approach is facing a problem somewhere ... but I cannot say where ..

                    Hope you can help on this ..

                    greetings from berlin




                    • 7. Re: jboss-spring.xml beans location
                      Ales Justin Master

                       

                      "loumaus" wrote:

                      <property name="catalogDao" ref="catalogDao"/>
                      



                      What about if you change to this:

                      <property name="catalogDao"><ref local="catalogDao"></property>
                      


                      Since this is _not_ a SpringDeployer problem, it's a plain Spring problem.

                      • 8. Re: jboss-spring.xml beans location
                        thorsten maus Newbie

                        mmmhhh

                        <bean id="catalogService" class="foo.bar.service.DefaultCatalogService" >
                         <property name="catalogDao">
                         <ref local="catalogDao"/>
                         </property>
                         </bean>
                        


                        does not work as well ..

                        I already removed the autowire="byType" attribute as it did not work neither..

                        that was the only reason I was asking about the deployer ...

                        what worries me a bit is that everything seems to startup properly:

                        2007-07-06 17:08:49,866 DEBUG [org.springframework.beans.CachedIntrospectionResults] Not strongly caching class [foo.bar.dao.DefaultCatalogDao] because it is not cache-safe
                        2007-07-06 17:08:49,866 DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] Eagerly caching bean 'catalogDao' to allow for resolving potential circular references
                        2007-07-06 17:08:49,870 DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] Returning cached instance of singleton bean 'entityManagerFactory'
                        2007-07-06 17:08:49,906 DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] Creating shared instance of singleton bean 'catalogService'
                        2007-07-06 17:08:49,906 DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] Creating instance of bean 'catalogService' with merged definition [Root bean: class [foo.bar.servic
                        e.DefaultCatalogService]; scope=singleton; abstract=false; lazyInit=false; autowireCandidate=true; autowireMode=0; dependencyCheck=0; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyM
                        ethodName=null; defined in URL [jar:file:/home/tmaus/server/jboss-4.0.5.GA/server/default/tmp/deploy/tmp54823catalog.ear-contents/catalog-spring.spring!/META-INF/jboss-spring.xml]]
                        2007-07-06 17:08:49,908 DEBUG [org.springframework.beans.CachedIntrospectionResults] Not strongly caching class [foo-bar.service.DefaultCatalogService] because it is not cache-safe
                        2007-07-06 17:08:49,908 DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] Eagerly caching bean 'catalogService' to allow for resolving potential circular references
                        2007-07-06 17:08:49,909 DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] Returning cached instance of singleton bean 'catalogDao'
                        2007-07-06 17:08:49,909 DEBUG [org.jboss.spring.factory.NamedXmlApplicationContext] Publishing event in context [org.jboss.spring.factory.NamedXmlApplicationContext;hashCode=27471825]: org.springframework.cont
                        ext.event.ContextRefreshedEvent[source=org.jboss.spring.factory.NamedXmlApplicationContext: display name [org.jboss.spring.factory.NamedXmlApplicationContext;hashCode=27471825]; startup date [Fri Jul 06 17:08:
                        48 CEST 2007]; root of context hierarchy]
                        
                        


                        • 9. Re: jboss-spring.xml beans location
                          thorsten maus Newbie

                          hi alesj ..

                          if i post you a properly logfile ...
                          and provide you some excerpts of the code ..

                          would you be able to help me solving the problem ..

                          fact for me is:

                          1. my spring package gets properly deployed during deployment..
                          implementing the ApplicationContextAware interface in my service target class allows me to see all implemented beans, which are six.

                          2. in the spring context, the two target beans are properly bound together
                          "Autowiring by type from bean name 'catalogService' via property 'catalogDao' to bean named 'catalogDao'"

                          So .. the deployment on the jboss 4.0.5 is working perfectly, no problems no error messages

                          3. i call the stateless session bean.
                          3.1 the private catalogService object is properly injected by the correct implementation of of this service which is located in my jboss-spring.xml file.

                          3.2 the catalog service is called which works fine as well.

                          3.3 my target method calls the setApplicationContext again in order to display all bound beans. This time I receive an empty result list which means that no beans are bound.

                          It looks to me as if the stateless using the @Spring is able to inject a single class / implementation grabbed out of the spring context, but is not able to get the defined and deployed complete context .

                          I could investigate more by now but wanted to have your opinion on this first of all.

                          main question is ..
                          are you guys sure that the while injecting a stateless bean the complete deployed spring context is grabbed and used ??

                          thanks for your help

                          • 10. Re: jboss-spring.xml beans location
                            thorsten maus Newbie

                            My fault .. sorry ..

                            forgot to add this magic line:
                            @Interceptors(SpringLifecycleInterceptor.class)

                            greetings and thanks for your patience

                            • 11. Re: jboss-spring.xml beans location
                              Ales Justin Master

                              :-)

                              Initially I've used AOP interceptor defined in ejb3-interceptors-aop.xml (or some similar name).

                              So I didn't have to worry about setting this EJB3 style interceptor.