-
1. Re: jboss-spring.xml beans location
alesj Jul 5, 2007 11:59 PM (in response to loumaus)What happens?
I don't see what is this catalogBean that 'solved' the problem? -
2. Re: jboss-spring.xml beans location
loumaus Jul 6, 2007 4:47 AM (in response to loumaus)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
alesj Jul 6, 2007 5:33 AM (in response to loumaus)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
loumaus Jul 6, 2007 7:19 AM (in response to loumaus)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
alesj Jul 6, 2007 7:32 AM (in response to loumaus)"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
loumaus Jul 6, 2007 10:37 AM (in response to loumaus)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
alesj Jul 6, 2007 10:53 AM (in response to loumaus)"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
loumaus Jul 6, 2007 11:16 AM (in response to loumaus)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
loumaus Jul 11, 2007 5:49 AM (in response to loumaus)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
loumaus Jul 11, 2007 6:25 AM (in response to loumaus)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
alesj Jul 11, 2007 6:29 AM (in response to loumaus):-)
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.