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 took a lot at spring-support sources. Have some questions.
By single "stand-alone-launcher" you mean that webservices not depending
on transports will use WSSpringServlet for deploying?
Now it's implemented to support HTTP, but for sure can be extended.
I've tried to deploy JMS listener to Spring JMS container via web
application and it's working fine. Just several beans should be declared
additionaly (attached)
So think we can start to proceed in extending launcher (if I get your
idea right).
WBR,
Alexey.
>
> We can talk over the phone if it helps.
>
>
> [1] https://jax-ws-commons.dev.java.net/nonav/spring/