Oleksiy Stashok wrote:
> Hi,
>
>>> 3. Adding spring support as the deployment mechanism
>>
>> I have a question/brainstorming with respect to the deployment
>> mechanism of the JMS transport.
>>
>> While looking at the JMS transport (and thinking about other
>> transports, like SMTP), it became clear to me that we can't afford to
>> have different deployment mechanisms for each one of them.
>>
>> So I'd like to rework the deployment of the JMS transport around our
>> Spring support [1]. This would enable the consistent configuration
>> mechanism across all transports. For example, you can configure
>> handlers, bindingID, pipeline assembler, etc, all in the same way.
>>
>> Would that be OK to you, Oleksiy? Does that make sense? This makes it
>> possible to deploy JMS transport into AppServer without writing
>> boiler-plate ejb-jar.xml (and similarly we won't need a separate
>> "stand-alone launcher" for each transport.)
> I dont have any spring expirience, so now can't completely imagine how
> it will work in that case. But perspective to get rid off that
> desciptors and personal "stand-alone launcher" for each transport looks
> really interesting.
Good.
> I will try to look in sample you told about on "Spring support" thread
> and clear things out, and also think about applying this to tcp
> transport in future.
Thanks. Yeah, this could also work nicely with the TCP transport,
although there seems to be some interesting interaction between servlet
and TCP (like port unification stuff), so I need a better understanding
of those, too.
>> We can talk over the phone if it helps.
> I'll look into examples, then if will have question we can discuss them :)
OK, let me know how it goes.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com