Andreas Veithen wrote:
There is an alternative to all this:
1. Create an implementation of the Startup interface together with a
StartupFactory and StartupSerializer.
2. When the init method (defined by ManagedLifecycle) is called on the
Startup (at Synapse startup as the name implies), it gets the
SynapseEnvironment as parameter. From there you can get access to the
SynapseConfiguration and the Axis2 ConfigurationContext (provided that
SYNAPSE-382 is fixed).
3. SynapseConfiguration#getProxyServices gives you the list of defined
proxy services and ProxyService#getTargetEndpoint gives you the target
endpoint.
4. ConfigurationContext#getAxisConfiguration gives you the
AxisConfiguration and from there you can locate a transport sender by
using AxisConfiguration#getTransport(s)(In|Out) (call
get(Reveiver|Sender) on the Transport(In|Out)Description).
This should give you all the information you need to access the
transport and tell it to start the relevant sessions.
But this would make this Synapse specific with a startup class
involvement? Also this will prevent JMX access from starting and
stopping the transports cleanly as the startup is involved.. I think the
transports should be handled behind the transport abstraction, without
mixing it with Synapse.., and this is possible as I understand, using
the same way the JMS sender operates
I discussed this with Asanka A. who raised this original question and he
agreed that what we have for the JMS sender is what they need. I do not
understand FIX or the transport/implementation much, but AFAIK what they
mean as the "URL" here is not what others seems to think.. Asanka A - if
you agree with me, could you please reply to this list if what I suggest
is an appropriate approach, else please tell me why it will not work?
asankha
--
Asankha C. Perera
WSO2 - http://wso2.org
http://esbmagic.blogspot.com
