Nice! Paul
On Mon, Jun 30, 2008 at 6:08 PM, Andreas Veithen <[EMAIL PROTECTED]> 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. > > Andreas > > On 30 juin 08, at 13:58, Hiranya Jayathilaka wrote: > >> Hi, >> >> On Mon, Jun 30, 2008 at 11:24 AM, Asanka Abeysinghe <[EMAIL PROTECTED]> >> wrote: >> I totally agree with Asankha to take a similar approach like JMS >> connection pools. Even FIX transport does the same to create the >> ***Initiator*** session(s) by starting the FIX engine inside >> 'startListerningForServices' method in the FIX transport listener. So if >> we start the ***Acceptor** *FIX Engine by providing the session(s) info at >> the same level we will solving our problem. when message transports it will >> check the availability of the session and if exists use the session and >> dispatch the message else create a new session (as it is now) . >> >> Currently we read a service parameter (transport.fix.AccetorConfigURL) >> inside the startListeningForService method and create the acceptors as >> necessary. If we are to do the same for creating initiators we will have to >> introduce a new parameter and ask the user to specify the target URL in that >> parameter in addition to in the target element of the service definition. >> But this approach suffers the drawback I mentioned previously. That is with >> one parameter we can specify only one target URL. Then we will be able to >> create only one acceptor session at the start up. If there's a way we can >> specify multiple URL values with one parameter then implementing the rest is >> easy. >> >> Any Ideas? >> >> Thanks >> >> Best Regards, >> Hiranya >> >> Asanka A. >> >> Asankha C. Perera wrote: >> Asanka >> Primary reason is that and I can add few more use cases >> 1. Acceptor can send messages for a specific session before sending >> messages from the initiator (fills, corrections and acknowledgments for the >> previously posted transactions). >> 2. FIX recovery happens with the session creation, so with the current >> implementation recovery has to wait till the first message sends. >> >> Around how many of these "sessions" will a typical usecase have? in the >> order of services deployed, or a small fixed number - like the JMS >> connection factories? If this is a small fixed number, you could define this >> similarly to the way the JMS sender defines connection pools >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
