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.
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.
> We can talk over the phone if it helps.
I'll look into examples, then if will have question we can discuss them :)
Thank you.
WBR,
Alexey.
>
>
> [1] https://jax-ws-commons.dev.java.net/nonav/spring/