Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-10-27 18:36:32
|
First of all - great work, James :-) In the long run, do you intend to = move the generic parts over to the Spring codebase, or will those remain = part of the ActiveMQ project too? It's not immediately obvious to me = which classes depend on the actual ActiveMQ message broker and which = just reside there but are generic in nature... (I've just looked at the = sample configuration yet.) =20 Eugene, regarding integrating the WorkManager into the server lifecycle: = If the WorkManager implements Spring's DisposableBean interface or has a = declaratively specified destroy method, it will receive a proper = shutdown callback - when the Spring application context gets closed (for = example, when the web application gets shut down). =20 Effectively, the WorkManager is similar to a Quartz Scheduler: It fires = up with the Spring context, manages a couple of threads for asynchronous = processing there, and closed down with the Spring context again. I don't = see any more conflict with the J2EE server's resource management here = than in the case of Quartz... =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Eugene Kuleshov Gesendet: Mi 27.10.2004 20:20 An: spr...@li... Cc: de...@ac... Betreff: Re: [Springframework-developer] Re: [activemq-dev] Re: message = driven POJOs, a lightweight JCA container available jas...@ma... wrote: >> I'm pretty much aware of both options and can see number of >> disadvantages for solution based on Tomkat. > > Like what? :) Besides vendor reputation and acceptance on the entrprise market its primarily cluster-related, especially in a cluster that has stateful components. Failover and resource management (jdbc and external jms) also quite limited there. Monitoring capabilities probably also less advanced. >> Also it could be not even an option in many cases. Anyway it seems >> that you have ignored the last part of my original message. > > Sorry I wasn't very clear before - here's another go. > > The WorkManager part is a non issue. It was never in any other J2EE > version and so isn't a versioning issue - you should be able to use = the > WorkManager API in any J2EE container. If the container is J2EE 1.4 > it'll have one, if it doesn't the JCAContainer comes with its own > implementation anyways. > > So the WorkManager isn't the issue - the issue is, does the JCA = version > hardwired into the J2EE container work - I've a feeling previous JCA > versions in J2EE 1.3 containers might not work with the current > JCAContainer as the JCAContainer is dependent on JCA 1.5. That is more or less clear already. :-) By the way you probably could use isolating classloader to keep WorkManager API away/separate from the J2EE classpath. >> Most likely you'll have to have container-specific WorkManager >> implementation that will not interfere with container life cycle. > > I don't follow. The JCAContainer just uses any WorkManager > implementation. Either your container provides one, or you can use the > bundled one in JCAContainer. Its a fairly trivial bit of code the > WorkManager - you could even write your own using your containers > ThreadPools if it doesn't yet support the WorkManager APIs. Ok. Here is the scenario I'm talking about. Let say WorkManager started some relatively long-running transactional or nontransactional process (message processing in POJO may take some time for a variety of reasons) and nearly after that thread has been started J2EE container decide to go down (doesn't really matter why, and number of reasons will increase for large environment). So, now I can't see how proprietory WorkManager implementation can coordinate with the container lifecycle in such case. Am I missing something? >> And most likely those implementations will be different even between >> Tomkat and Jetty. > > Tomcat and Jetty don't have WorkManager implementations as they are = not > JCA 1.5 containers nor are they full J2EE containers. So the > JCAContainer's WorkManager is fine for us in any Spring deployment - > unless its a pre-J2EE 1.4 container in which case the JCA versions = could > clash. Sure they don't. I'm talking about integrating your JCA container's WorkManager into J2EE/Web server lifecycle. regards, Eugene ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-10-28 08:49:51
|
James, Regarding pooling of the MessageListener objects: In many cases, this = won't be necessary, as the MessageListener implementation will be = thread-safe anyway - similar to the DAO and service object case, where a = shared singleton instance is fine in 99% of the cases, so there's no = need to pool them (like Stateless Session Beans force you to). This means that in many cases, there's no need for a pool of listeners, = i.e. there's no need to specify a TargetSource as message handler - a = plain target object will do, specified as shared MessageListener bean. If there's an actual need to pool those target listeners, this could = always be achieved through a ProxyFactoryBean with a pooling = TargetSource, with the proxy implementing the MessageListener interface: = From the point of view of the ActiveMQ message dispatcher, it would = simply keep calling the shared MessageListener onMessage method, but = this time on the proxy which will delegate to one of the instances in = its backend pool. Essentially, it seems to me that the ActiveMQ container does not have to = be aware of Spring's TargetSource mechanism: Just invoking a provided = MessageListener reference should be enough, without worrying about the = backend. Of course, the above argument does not affect the pooling of JMS = Sessions in the background: That's the core of what ActiveMQ does here. = I'm just talking about the need to pool the MessageListener = implementation beans, which is probably as rare as the need to pool = DAOs. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of jas...@ma... Sent: Thursday, October 28, 2004 10:24 AM To: spr...@li... Cc: de...@ac... Subject: Re: [activemq-dev] Re: [Springframework-developer] Re: [activemq-dev] Re: message driven POJOs, a lightweight JCA container available On 27 Oct 2004, at 20:11, Eugene Kuleshov wrote: > James Strachan wrote: >>> I think Eugene has a point. >>> >>> The work manager isn't the problem, it's integrating message=20 >>> delivery to mdbs without container support. This is going to be=20 >>> even more unlikely to work for CMT mdbs. >>> >>> If you want to use your spring psuedo-mdbs inside a j2ee container,=20 >>> there's still the problem of transactional message delivery. =20 >>> There's no standard way to find the TM and even if you get it I=20 >>> would investigate extensively before thinking that using it directly = >>> will give you the correct semantics. >> Agreed - though we're delegating to Spring for this issue.... > > By the way, there was a huge discussion related to CMT and Spring=20 > manged transaction and as far as I remember everybody agreed that in=20 > general it is a bad idea to mix those. BTW I think its worth saying, that in all the projects I've used JMS=20 (which is most of them over the last 5 years), I think I use XA=20 delivery less than 2% of the time. So for 98% of the time at least, I=20 tend to use regular JMS with no transactions and just use the regular=20 JMS acknowledge() or commit() mechanisms, which requires no J2EE=20 transaction manager or special container hooks whatsoever. So even if the JCA Container never supported J2EE transactions or=20 didn't support them any where near as well as a full J2EE container,=20 its still very, very useful IMHO. James ------- http://radio.weblogs.com/0112098/ ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jas...@ma...> - 2004-10-28 09:16:29
|
On 28 Oct 2004, at 09:52, j=FCrgen h=F6ller [werk3AT] wrote: > James, > > Regarding pooling of the MessageListener objects: In many cases, this=20= > won't be necessary, as the MessageListener implementation will be=20 > thread-safe anyway - similar to the DAO and service object case, where=20= > a shared singleton instance is fine in 99% of the cases, so there's no=20= > need to pool them (like Stateless Session Beans force you to). > > This means that in many cases, there's no need for a pool of=20 > listeners, i.e. there's no need to specify a TargetSource as message=20= > handler - a plain target object will do, specified as shared=20 > MessageListener bean. Agreed. I guess it depends if the MessageListener is stateful /=20 thread-safe or not. Most of the MessageListener instances I write are=20= not thread safe but that could be just me; though I can imagine ones=20 that are thread safe. > If there's an actual need to pool those target listeners, this could=20= > always be achieved through a ProxyFactoryBean with a pooling=20 > TargetSource, with the proxy implementing the MessageListener=20 > interface: =46rom the point of view of the ActiveMQ message = dispatcher,=20 > it would simply keep calling the shared MessageListener onMessage=20 > method, but this time on the proxy which will delegate to one of the=20= > instances in its backend pool. Great idea. > Essentially, it seems to me that the ActiveMQ container does not have=20= > to be aware of Spring's TargetSource mechanism: Just invoking a=20 > provided MessageListener reference should be enough, without worrying=20= > about the backend. > > Of course, the above argument does not affect the pooling of JMS=20 > Sessions in the background: That's the core of what ActiveMQ does=20 > here. I'm just talking about the need to pool the MessageListener=20 > implementation beans, which is probably as rare as the need to pool=20 > DAOs. I guess it'd make things simpler if we assumed no pooling was needed=20 and then used the ProxyBeanFactory to add pooling when we need it.=20 Though the JCA ResourceAdapter already has to pool Endpoint objects=20 anyways in case they are stateful, so I figured it was easier to just=20 let the Endpoint talk to Spring's pool - but you're right, it'd be=20 cleaner to use the ProxyBeanFactory to add pooling when its required.=20 If nothing else it'd make it easier to use thread safe listeners=20 easier. James ------- http://radio.weblogs.com/0112098/ |
|
From: Rod J. <ro...@in...> - 2004-10-28 13:02:01
|
> Regarding pooling of the MessageListener objects: In many cases, this won't be necessary, as the MessageListener implementation will be thread-safe anyway - similar to the DAO and service object case, where a shared singleton instance is fine in 99% of the cases, so there's no need to pool them (like Stateless Session Beans force you to). > > This means that in many cases, there's no need for a pool of listeners, i.e. there's no need to specify a TargetSource as message handler - a plain target object will do, specified as shared MessageListener bean. > > If there's an actual need to pool those target listeners, this could always be achieved through a ProxyFactoryBean with a pooling TargetSource, with the proxy implementing the MessageListener interface: >From the point of view of the ActiveMQ message dispatcher, it would simply keep calling the shared MessageListener onMessage method, but this time on the proxy which will delegate to one of the instances in its backend pool. Indeed. Transparent, and enabling the simplest thing that can possibly work. We shouldn't slip into EJB-think--"pooling is always necessary". R |
|
From: <jas...@ma...> - 2004-10-28 14:37:03
|
On 28 Oct 2004, at 09:52, j=FCrgen h=F6ller [werk3AT] wrote: > If there's an actual need to pool those target listeners, this could =20= > always be achieved through a ProxyFactoryBean with a pooling =20 > TargetSource, with the proxy implementing the MessageListener =20 > interface: =46rom the point of view of the ActiveMQ message = dispatcher, =20 > it would simply keep calling the shared MessageListener onMessage =20 > method, but this time on the proxy which will delegate to one of the =20= > instances in its backend pool. I went a head and refactored to just use a MessageListener and so then =20= its up to the MessageListener instance to handle pooling - if its =20 needed. This makes the code much cleaner - great suggestion j=FCrgen. I tried using the ProxyFactoryBean. Firstly this introduced a new =20 runtime dependency on cglib. Secondly it created this exception.. org.springframework.beans.factory.BeanCreationException: Error creating =20= bean with name 'inboundMessageB' defined in class path resource =20 [spring-with-proxyfactory.xml]: Can't resolve reference to bean =20 'pooledEchoBean' while setting property 'messageListener'; nested =20 exception is org.springframework.beans.factory.BeanCreationException: =20= Error creating bean with name 'pooledEchoBean' defined in class path =20 resource [spring-with-proxyfactory.xml]: Initialization of bean failed; =20= nested exception is org.aopalliance.aop.AspectException: null org.springframework.beans.factory.BeanCreationException: Error creating =20= bean with name 'pooledEchoBean' defined in class path resource =20 [spring-with-proxyfactory.xml]: Initialization of bean failed; nested =20= exception is org.aopalliance.aop.AspectException: null java.lang.IllegalStateException: Unknown callback class =20 org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedIntercept=20= or at =20 net.sf.cglib.proxy.CallbackUtils.getGenerator(CallbackUtils.java:102) The XML config file I was using is here... http://cvs.activemq.codehaus.org/viewrep/activemq/activemq/modules/=20 container/src/test/org/codehaus/activemq/jca/spring-with-=20 proxyfactory.xml?r=3D1.1 and the test case is JCAContainerWithProxyFactoryTest. Any ideas why I get this error? Its OK to use a ProxyFactoryBean with a =20= pooled TargetSource without using any AOP advice right? As a work around and to avoid the cglib dependency, I've added a little =20= TargetSourceMessageListener helper class which works in a similar =20 way... http://cvs.activemq.codehaus.org/viewrep/activemq/activemq/modules/=20 container/src/test/org/codehaus/activemq/jca/spring.xml?r=3D1.3 In terms of simplicity in the XML configuration file they're of similar =20= order. Incidentally there's also an XA based test case to show how to use XA =20= based message consumption; you basically just ocnfigure the =20 TransactionManager to use. http://cvs.activemq.codehaus.org/viewrep/activemq/activemq/modules/=20 container/src/test/org/codehaus/activemq/jca/spring-with-xa.xml?r=3D1.1 In this particular test case, JCAContainerUsingXATest we just use =20 JOTM directly. James ------- http://radio.weblogs.com/0112098/ |
|
From: Chris N. <ch...@si...> - 2004-10-29 07:13:41
|
jas...@ma... wrote: > java.lang.IllegalStateException: Unknown callback class > org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedIntercept > or at > net.sf.cglib.proxy.CallbackUtils.getGenerator(CallbackUtils.java:102) Seems like you've worked around this, but FWIW this was a known bug in an older version of CGLIB (the CallbackUtils class does not exist anymore). Not sure where you're pulling your jar from, but perhaps you could point them to the latest version (2.0.2). Chris |
|
From: <jue...@we...> - 2004-10-28 15:34:30
|
I guess all you're missing here is an interface that ProxyFactoryBean =
should you use for the proxy: This will also remove the implicit CGLIB =
dependency, automatically using a JDK dynamic proxy instead.
<bean id=3D"pooledEchoBean" =
class=3D"org.springframework.aop.framework.ProxyFactoryBean">
<property name=3D"proxyInterfaces">
<value>javax.jms.MessageListener</value>
</property>
<property name=3D"targetSource">
<ref local=3D"pooledEchoBeanTargetSource"/>
</property>
</bean>
ProxyFactoryBean can work without explicitly specified =
"proxyInterfaces", but just if there's a direct target object to =
analyze: It will proxy all interfaces implemented by the target then, or =
create a CGLIB proxy for the target if there are no interfaces.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of jas...@ma...
Sent: Thursday, October 28, 2004 4:37 PM
To: spr...@li...
Subject: Re: [Springframework-developer] message driven POJOs, a
lightweight JCA container available
On 28 Oct 2004, at 09:52, j=FCrgen h=F6ller [werk3AT] wrote:
> If there's an actual need to pool those target listeners, this could =20
> always be achieved through a ProxyFactoryBean with a pooling =20
> TargetSource, with the proxy implementing the MessageListener =20
> interface: From the point of view of the ActiveMQ message dispatcher, =
> it would simply keep calling the shared MessageListener onMessage =20
> method, but this time on the proxy which will delegate to one of the =20
> instances in its backend pool.
I went a head and refactored to just use a MessageListener and so then =20
its up to the MessageListener instance to handle pooling - if its =20
needed. This makes the code much cleaner - great suggestion j=FCrgen.
I tried using the ProxyFactoryBean. Firstly this introduced a new =20
runtime dependency on cglib. Secondly it created this exception..
org.springframework.beans.factory.BeanCreationException: Error creating =
bean with name 'inboundMessageB' defined in class path resource =20
[spring-with-proxyfactory.xml]: Can't resolve reference to bean =20
'pooledEchoBean' while setting property 'messageListener'; nested =20
exception is org.springframework.beans.factory.BeanCreationException: =20
Error creating bean with name 'pooledEchoBean' defined in class path =20
resource [spring-with-proxyfactory.xml]: Initialization of bean failed; =
nested exception is org.aopalliance.aop.AspectException: null
org.springframework.beans.factory.BeanCreationException: Error creating =
bean with name 'pooledEchoBean' defined in class path resource =20
[spring-with-proxyfactory.xml]: Initialization of bean failed; nested =20
exception is org.aopalliance.aop.AspectException: null
java.lang.IllegalStateException: Unknown callback class =20
org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedIntercept =
or
at =20
net.sf.cglib.proxy.CallbackUtils.getGenerator(CallbackUtils.java:102)
The XML config file I was using is here...
http://cvs.activemq.codehaus.org/viewrep/activemq/activemq/modules/=20
container/src/test/org/codehaus/activemq/jca/spring-with-=20
proxyfactory.xml?r=3D1.1
and the test case is JCAContainerWithProxyFactoryTest.
Any ideas why I get this error? Its OK to use a ProxyFactoryBean with a =
pooled TargetSource without using any AOP advice right?
As a work around and to avoid the cglib dependency, I've added a little =
TargetSourceMessageListener helper class which works in a similar =20
way...
http://cvs.activemq.codehaus.org/viewrep/activemq/activemq/modules/=20
container/src/test/org/codehaus/activemq/jca/spring.xml?r=3D1.3
In terms of simplicity in the XML configuration file they're of similar =
order.
Incidentally there's also an XA based test case to show how to use XA =20
based message consumption; you basically just ocnfigure the =20
TransactionManager to use.
http://cvs.activemq.codehaus.org/viewrep/activemq/activemq/modules/=20
container/src/test/org/codehaus/activemq/jca/spring-with-xa.xml?r=3D1.1
In this particular test case, JCAContainerUsingXATest we just use =20
JOTM directly.
James
-------
http://radio.weblogs.com/0112098/
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jas...@ma...> - 2004-10-28 15:59:46
|
On 28 Oct 2004, at 16:36, j=FCrgen h=F6ller [werk3AT] wrote: > I guess all you're missing here is an interface that ProxyFactoryBean=20= > should you use for the proxy: DOH! It might be worth mentioning this in the manual; I tried my best=20 to figure it out from the docs. > This will also remove the implicit CGLIB dependency, automatically=20 > using a JDK dynamic proxy instead. > > <bean id=3D"pooledEchoBean"=20 > class=3D"org.springframework.aop.framework.ProxyFactoryBean"> > <property name=3D"proxyInterfaces"> > <value>javax.jms.MessageListener</value> > </property> > <property name=3D"targetSource"> > <ref local=3D"pooledEchoBeanTargetSource"/> > </property> > </bean> > > ProxyFactoryBean can work without explicitly specified=20 > "proxyInterfaces", but just if there's a direct target object to=20 > analyze: It will proxy all interfaces implemented by the target then,=20= > or create a CGLIB proxy for the target if there are no interfaces. Fantastic! Many thanks j=FCrgen again. I've made this change in CVS and its all=20 working well now. James ------- http://radio.weblogs.com/0112098/ |
|
From: <jas...@ma...> - 2004-10-27 18:55:39
|
On 27 Oct 2004, at 19:38, j=FCrgen h=F6ller [werk3AT] wrote: > First of all - great work, James :-) Thanks! > In the long run, do you intend to move the generic parts over to the=20= > Spring codebase, or will those remain part of the ActiveMQ project=20 > too? For simplicity sake I was gonna leave it in ActiveMQ for now -=20 particularly as we need it for other things in the ActiveMQ project and=20= we'll be revving it pretty quickly. I also figured it was probably=20 better not to tie it to the Spring release schedule just yet. (e.g.=20 witness what's happening to the little JMS remoting stuff :) Plus I figured it was maybe a bit big for Spring. To be a general=20 solution for all JMS providers, Spring users may need a JCA=20 ResourceAdapter for their JMS provider if their provider doesn't have=20 one - in which case both activemq-container.jar and activemq-ra.jar=20 will be needed (rather than just activemq-container.jar). Also over time we're putting together a set of useful JMS POJOs for=20 doing things like bridging JMS providers, transforming messages,=20 applying rules and workflow; which again are probably outside of the=20 scope of Spring. > It's not immediately obvious to me which classes depend on the actual=20= > ActiveMQ message broker and which just reside there but are generic in=20= > nature... (I've just looked at the sample configuration yet.) The JCA Container doesn't depend on the ActiveMQ broker at all - its=20 just the demo uses ActiveMQ's Resource Adapter. > Eugene, regarding integrating the WorkManager into the server=20 > lifecycle: If the WorkManager implements Spring's DisposableBean=20 > interface or has a declaratively specified destroy method, it will=20 > receive a proper shutdown callback - when the Spring application=20 > context gets closed (for example, when the web application gets shut=20= > down). Agreed. I think Eugene's concern was shutting down the container while=20= the WorkManager was processing a message. > Effectively, the WorkManager is similar to a Quartz Scheduler: It=20 > fires up with the Spring context, manages a couple of threads for=20 > asynchronous processing there, and closed down with the Spring context=20= > again. I don't see any more conflict with the J2EE server's resource=20= > management here than in the case of Quartz... Agreed. James ------- http://radio.weblogs.com/0112098/ |
