RE: [activemq-dev] Re: [Springframework-developer] Re: [activemq-dev] Re: message driven POJOs, a lightweight JCA container available

[Stefan K. <st...@kl...>]

Great work James, and thanks to Eugene for challenging him!  ;-)

-Stefan


> -----Original Message-----
> From: spr...@li... 
> [mailto:spr...@li...]
>  On Behalf Of Eugene Kuleshov
> Sent: Wednesday, October 27, 2004 9:20 PM
> To: spr...@li...; 
> de...@ac...
> Subject: Re: [activemq-dev] Re: [Springframework-developer] 
> Re: [activemq-dev] Re: message driven POJOs, a lightweight 
> JCA container available
> 
> 
> jas...@ma... wrote:
> 
>    Great James! Now we agreed on everything. :-)
>    So that is why I suggested to write up some best 
> practices/patterns 
> and publish it somewhere neat Spring/ActiveMQ.
> 
>    Also see few more comments below.
> 
>    regards,
>    Eugene
> 
> >>>>   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.
> > Agreed.
> >> Failover and resource management (jdbc and external jms) 
> also quite 
> >> limited there.
> > Oh I don't know, I know a pretty good clustered JMS 
> > (http://activemq.codehaus.org/) :)
> 
>    It is a JMS cluster, but not J2EE. Isn't it? :)
> 
> > I take your point though.
> > 
> >>>>  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. :-)
> > OK :)
> 
> >>   By the way you probably could use isolating classloader to keep 
> >> WorkManager API away/separate from the J2EE classpath.
> > Good idea. Though I think its JCA which will be the 
> classloading issue, 
> > not the WorkManager.
> 
>    Doesn't matter. Isolating classolader could probably use 
> its own JCA 
> jar and break classloading delegation chain.
> 
> >>>>   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?
> > 
> > 
> > OK, I'm with you now - sorry for the confusion.
> > 
> > It totally depends on the WorkManager implementation. The 
> Spring one 
> > uses Spring's container lifecycle. If you want to use the J2EE 
> > container's lifecycle, then use the J2EE containers 
> WorkManager - such 
> > as the one in Geronimo if you're deploying in Geronimo.
> > 
> > Note I can imagine a version of the 'message driven pojo' container 
> > being developed for Geronimo which reuses Geronimo's transaction 
> > manager, container lifecycle, work manager and MDB 
> container, but just 
> > used Spring to create the MessageListener POJOs using 
> dependency injection.
> > 
> > The same 'message driven pojo' concept should be usable 
> both within a 
> > J2EE container or outside of one.
> > 
> > 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=5588&alloc_id=12065&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>