Axis2 integration... - going well

[Jules Gosnell-4]

So,

I have just checked in enough of an integration to get the
Axis2SessionCreationTest working on top of WADI (It pulls in WebSpec
dependencies at the moment, because I am just reusing the Web Session
framework, which fits very closely) - but at the moment, I can't enable
it in the build, because it uses the full WADI stack including a Spring
config that requires Derby and ActiveMQ running - I will disentangle
this stuff soon...

I thought that I would come straight back to Rajith with issues
uncovered so far, before moving on to the next test - so here goes :-)

SessionManager lifecycle :

WADI has a requirement for a definite start/stop() lifecycle - but
org.apache.axis2.session.SessionManager does not see to provide this.
For the moment, I am using the ctor to call my start() method, and my
stop() method is not being called - can we extend the SessionManager
interface with a lifecycle and hook it up on the Axis2 side ?

Invocation lifecycle :

WADI needs to know when an invocation for a Session arrives at the edge
of the container, when it leaves and which Session it requires. There
does not appear to be provision for this in
org.apache.axis2.session.SessionManager - can we provide it ? Without
this, WADI cannot decide when a Session is inactive, and may be migrated
to store or another node. Ideally, the invocation would be passed with
the notification e.g. :

DumbWADISessionManager
{
...
  void enter(Invocation i);
  void leave(Invocation i);
...
}

If you want to give WADI enough rope to be able to relocate not only
Sessions, but also Invocations, then you need to pass flow control into
the 'enter()' method as well - with the Servlet spec, this is currently
done using a FilterChain - but we can abstract to any sort of e.g.
Chain. The 'Chain' will have an e.g. 'next(Invocation i)' method on it,
which WADI calls if it wants this Invocation to continue into the local
container, but WADI may want to relocate the Invocation to a remote
Axis2 instance, where the relevant Session actually resides. in this
case, it does not call Chain.next(), but would use tier specific
redirection or proxying code to achieve this - e.g.

CleverWADISessionManager
{
...
  void enter(Chain , Invocation i);
  void leave(Invocation i);
}

I am happy to go with the 'DumbWADISessionManager' approach initially -
but the requirements of the 'CleverWADISessionManager' should be borne
in mind.

Axis2 must support some form of Invocation type - if you can pass that
down, I can adapt WADI to it. If it has an accessor to the Session key,
I will use that, otherwise I will need the Session key passed as well.


activate/passivateSession(String key) :

org.apache.axis2.session.SessionManager contains these two methods. I
have found that passivateSession is called at the end of the test - I
guess to passivate the session that was created. This implies that Axis2
is keeping tabs on Sessions itself, rather than delegating this
reponsibility to WADI. Since WADI may move Sessions in and out of the
container at any time, this is likely to cause problems :-). I can just
ignore these methods, but then Axis2 may get the idea that a Session is
present when it is not available... There doesn't seem to be a way to
communicate to the container that a Session has been timed-out, so the
container's copy of the Session list is going to fall out of sync
anyway. I think Axis2 should simply call start/stop on the
SessionManager and let it worry about what needs activating/passivating
and when.

get/setSessions() :

These accessors assume that Sessions are stored in a Map and that this
is readily get/settable - this is not be the case - Does Axis2 really
need it ? If session management is delegated to the SessionManager, why
should Axis2 be doing this sort of thing anyway ? Probably to get a list
of keys on which to call SessionManager.passivate(String key) ?

There are a number of other issues - but they are all resolvable from
the WADI side - although, I think that discussion would be useful.

Sorry to push back at you so hard, Rajith, :-)

BTW - I can't really continue onto to the next test, until we have the
enter/leave stuff in, as WADI needs to know when a Session is inactive
in order to migrate it...

If you want to run the test yourself, you will need to follow the
getting Started guide to get ActiveMQ and Derby instances up and
running, and change out your SessionManager for an
org.codehaus.wadi.axis2.Axis2Manager.


Jules




--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Rajith Attapattu-2]

Jules,

First of all thanks for the effort, I really appreciate it.
Comments are below

On 4/26/06, Jules Gosnell <jules@...> wrote:

>
> So,
>
> I have just checked in enough of an integration to get the
> Axis2SessionCreationTest working on top of WADI (It pulls in WebSpec
> dependencies at the moment, because I am just reusing the Web Session
> framework, which fits very closely) - but at the moment, I can't enable
> it in the build, because it uses the full WADI stack including a Spring
> config that requires Derby and ActiveMQ running - I will disentangle
> this stuff soon...
>
> I thought that I would come straight back to Rajith with issues
> uncovered so far, before moving on to the next test - so here goes :-)
>
> SessionManager lifecycle :
>
> WADI has a requirement for a definite start/stop() lifecycle - but
> org.apache.axis2.session.SessionManager does not see to provide this.
> For the moment, I am using the ctor to call my start() method, and my
> stop() method is not being called - can we extend the SessionManager
> interface with a lifecycle and hook it up on the Axis2 side ?

   I can include this.
   I am sure about the start, however I can't garuntee about the stop method
so that you can do the cleanup properly.
   I maybe able to get a shutdown hook around it, but other than that I
can't think of a business case where stop will be called programaticaly from
axis2 side

Invocation lifecycle :
>
> WADI needs to know when an invocation for a Session arrives at the edge
> of the container, when it leaves and which Session it requires. There
> does not appear to be provision for this in
> org.apache.axis2.session.SessionManager - can we provide it ? Without
> this, WADI cannot decide when a Session is inactive, and may be migrated
> to store or another node. Ideally, the invocation would be passed with
> the notification e.g. :


  There is already two methods for this
  public void activateSession(String sessionId);
  public void passivateSession(String sessionId);


DumbWADISessionManager
> {
> ...
>   void enter(Invocation i);
>   void leave(Invocation i);
> ...
> }


If you want to give WADI enough rope to be able to relocate not only

> Sessions, but also Invocations, then you need to pass flow control into
> the 'enter()' method as well - with the Servlet spec, this is currently
> done using a FilterChain - but we can abstract to any sort of e.g.
> Chain. The 'Chain' will have an e.g. 'next(Invocation i)' method on it,
> which WADI calls if it wants this Invocation to continue into the local
> container, but WADI may want to relocate the Invocation to a remote
> Axis2 instance, where the relevant Session actually resides. in this
> case, it does not call Chain.next(), but would use tier specific
> redirection or proxying code to achieve this - e.g.
>
> CleverWADISessionManager
> {
> ...
>   void enter(Chain , Invocation i);
>   void leave(Invocation i);
> }
>
> I am happy to go with the 'DumbWADISessionManager' approach initially -
> but the requirements of the 'CleverWADISessionManager' should be borne
> in mind.
>
> Axis2 must support some form of Invocation type - if you can pass that
> down, I can adapt WADI to it. If it has an accessor to the Session key,
> I will use that, otherwise I will need the Session key passed as well.

From an axis2 POV I am not sure how I can abstract the invovation.
The only thing I get is the sessiond_id extracted from the SOAP envelope.
Hence I  pass it down.

Well it would be very difficult for WADI (or anything else that sits below
Axis2) to redirect the invocation.
Redirecting the invocation means redirecting the entire SOAP envelope.
This will be a tricky area and I need think and talk to people before
settling on this.
For now as you said lets only worry about replicating and the session
manager being dumb.
So for the time being the session manager will always request a session
migration if a node does not have a copy of the session.

activate/passivateSession(String key) :

>
> org.apache.axis2.session.SessionManager contains these two methods. I
> have found that passivateSession is called at the end of the test - I
> guess to passivate the session that was created. This implies that Axis2
> is keeping tabs on Sessions itself, rather than delegating this
> reponsibility to WADI. Since WADI may move Sessions in and out of the
> container at any time, this is likely to cause problems :-). I can just
> ignore these methods, but then Axis2 may get the idea that a Session is
> present when it is not available... There doesn't seem to be a way to
> communicate to the container that a Session has been timed-out, so the
> container's copy of the Session list is going to fall out of sync
> anyway. I think Axis2 should simply call start/stop on the
> SessionManager and let it worry about what needs activating/passivating
> and when.

Jules, over here I don't worry about managing the actual session. I just
blindly call the activateSession(String id)
and it will be delegated to the WADI session manager.
So if you implement this method you know a request has arrived for that
particular session.

Simillaly I call passivateSession(String id) at the end of request and will
be delegated to you blindly. So u can then either persist and/or replicate
it.
I do not explicitly manage the physical session, all methods are delegated
to the underlying implementation and in this case WADI

I don't even have time out within the Axis2SessionManager. Timeout and other
things are managed by the Hard impl of the session manager interface.
So WADI will be managing it. I will be passing down all the info by way of
delegate.setXXX so you will be getting things like max_no_of sessions,
max_inactive_time_interval etc.

So essentialy you (WADI) will be managing all this. So I don't see how the
container going out of sync with WADI as the container doesn't have
anything, and WADI is supposed to manage it.

get/setSessions() :
>
> These accessors assume that Sessions are stored in a Map and that this
> is readily get/settable - this is not be the case - Does Axis2 really
> need it ? If session management is delegated to the SessionManager, why
> should Axis2 be doing this sort of thing anyway ? Probably to get a list
> of keys on which to call SessionManager.passivate(String key) ?
>
> There are a number of other issues - but they are all resolvable from
> the WADI side - although, I think that discussion would be useful.


 Jules, this  is a mistake, even the transient session manager I have
doesn't implement it
 You can ignore this method. I don't manage a hastable of sessions in the
Axis2SessionManager.
 It just blindly delegates to the underlying impl.

 If replication/persistance is there then it will be WADI.
 If people are only using standalone it will be the TransientSessionManager
I have inside Axis2.

Sorry to push back at you so hard, Rajith, :-)


LOL, what do you mean. Constructive critisism is what makes an impl better.
If you don't do it then you are not my friend. I appreciate your concern and
effort.

BTW - I can't really continue onto to the next test, until we have the
> enter/leave stuff in, as WADI needs to know when a Session is inactive
> in order to migrate it...


Can't you use the activate/passivateSession(String id) method and  adapt by
wrapping the session id in this invocation object.
After the explanations above, is this still not good enough??

If I use enter(Invocation I) and leave(Invocation I) It will be like
renaming the above 2 methods and wrapping the string session_id inside an
invocation object.
So I don't see how that adds anything significant?

If you want to run the test yourself, you will need to follow the
> getting Started guide to get ActiveMQ and Derby instances up and
> running, and change out your SessionManager for an
> org.codehaus.wadi.axis2.Axis2Manager.
>
> Jules


Once again you effort it really appreciated

--

> "Open Source is a self-assembling organism. You dangle a piece of
> string into a super-saturated solution and a whole operating-system
> crystallises out around it."
>
> /**********************************
> * Jules Gosnell
> * Partner
> * Core Developers Network (Europe)
> *
> *    www.coredevelopers.net
> *
> * Open Source Training & Support.
> **********************************/
>
>

[Rajith Attapattu-2]

Jules,

Btw, I have tried to manage sessions explicitly for testing. So I am not
sure if thats why you might have got confused about axis2 managing sessions
explicitly.

Let me send you an update source.zip and Axis2.jar that basicaly doesn't
have these design glitches. However you can continue with the current one as
you can be rest assure it will be delegate directly and blindly to WADI.

Regards,

Rajith

On 4/26/06, Rajith Attapattu <rajith77@...> wrote:

>
> Jules,
>
> First of all thanks for the effort, I really appreciate it.
> Comments are below
>
> On 4/26/06, Jules Gosnell < jules@...> wrote:
> >
> > So,
> >
> > I have just checked in enough of an integration to get the
> > Axis2SessionCreationTest working on top of WADI (It pulls in WebSpec
> > dependencies at the moment, because I am just reusing the Web Session
> > framework, which fits very closely) - but at the moment, I can't enable
> > it in the build, because it uses the full WADI stack including a Spring
> > config that requires Derby and ActiveMQ running - I will disentangle
> > this stuff soon...
> >
> > I thought that I would come straight back to Rajith with issues
> > uncovered so far, before moving on to the next test - so here goes :-)
> >
> > SessionManager lifecycle :
> >
> > WADI has a requirement for a definite start/stop() lifecycle - but
> > org.apache.axis2.session.SessionManager does not see to provide this.
> > For the moment, I am using the ctor to call my start() method, and my
> > stop() method is not being called - can we extend the SessionManager
> > interface with a lifecycle and hook it up on the Axis2 side ?
>
>    I can include this.
>    I am sure about the start, however I can't garuntee about the stop
> method so that you can do the cleanup properly.
>    I maybe able to get a shutdown hook around it, but other than that I
> can't think of a business case where stop will be called programaticaly from
> axis2 side
>
> Invocation lifecycle :
> >
> > WADI needs to know when an invocation for a Session arrives at the edge
> > of the container, when it leaves and which Session it requires. There
> > does not appear to be provision for this in
> > org.apache.axis2.session.SessionManager - can we provide it ? Without
> > this, WADI cannot decide when a Session is inactive, and may be migrated
> >
> > to store or another node. Ideally, the invocation would be passed with
> > the notification e.g. :
>
>
>   There is already two methods for this
>   public void activateSession(String sessionId);
>   public void passivateSession(String sessionId);
>
>
> DumbWADISessionManager
> > {
> > ...
> >   void enter(Invocation i);
> >   void leave(Invocation i);
> > ...
> > }
>
>
> If you want to give WADI enough rope to be able to relocate not only
> > Sessions, but also Invocations, then you need to pass flow control into
> > the 'enter()' method as well - with the Servlet spec, this is currently
> > done using a FilterChain - but we can abstract to any sort of e.g.
> > Chain. The 'Chain' will have an e.g. 'next(Invocation i)' method on it,
> > which WADI calls if it wants this Invocation to continue into the local
> > container, but WADI may want to relocate the Invocation to a remote
> > Axis2 instance, where the relevant Session actually resides. in this
> > case, it does not call Chain.next(), but would use tier specific
> > redirection or proxying code to achieve this - e.g.
> >
> > CleverWADISessionManager
> > {
> > ...
> >   void enter(Chain , Invocation i);
> >   void leave(Invocation i);
> > }
> >
> > I am happy to go with the 'DumbWADISessionManager' approach initially -
> > but the requirements of the 'CleverWADISessionManager' should be borne
> > in mind.
> >
> > Axis2 must support some form of Invocation type - if you can pass that
> > down, I can adapt WADI to it. If it has an accessor to the Session key,
> > I will use that, otherwise I will need the Session key passed as well.
>
>
> From an axis2 POV I am not sure how I can abstract the invovation.
> The only thing I get is the sessiond_id extracted from the SOAP envelope.
> Hence I  pass it down.
>
> Well it would be very difficult for WADI (or anything else that sits below
> Axis2) to redirect the invocation.
> Redirecting the invocation means redirecting the entire SOAP envelope.
> This will be a tricky area and I need think and talk to people before
> settling on this.
> For now as you said lets only worry about replicating and the session
> manager being dumb.
> So for the time being the session manager will always request a session
> migration if a node does not have a copy of the session.
>
> activate/passivateSession(String key) :
> >
> > org.apache.axis2.session.SessionManager contains these two methods. I
> > have found that passivateSession is called at the end of the test - I
> > guess to passivate the session that was created. This implies that Axis2
> > is keeping tabs on Sessions itself, rather than delegating this
> > reponsibility to WADI. Since WADI may move Sessions in and out of the
> > container at any time, this is likely to cause problems :-). I can just
> > ignore these methods, but then Axis2 may get the idea that a Session is
> > present when it is not available... There doesn't seem to be a way to
> > communicate to the container that a Session has been timed-out, so the
> > container's copy of the Session list is going to fall out of sync
> > anyway. I think Axis2 should simply call start/stop on the
> > SessionManager and let it worry about what needs activating/passivating
> > and when.
>
>
> Jules, over here I don't worry about managing the actual session. I just
> blindly call the activateSession(String id)
> and it will be delegated to the WADI session manager.
> So if you implement this method you know a request has arrived for that
> particular session.
>
> Simillaly I call passivateSession(String id) at the end of request and
> will be delegated to you blindly. So u can then either persist and/or
> replicate it.
> I do not explicitly manage the physical session, all methods are delegated
> to the underlying implementation and in this case WADI
>
> I don't even have time out within the Axis2SessionManager. Timeout and
> other things are managed by the Hard impl of the session manager interface.
> So WADI will be managing it. I will be passing down all the info by way of
> delegate.setXXX so you will be getting things like max_no_of sessions,
> max_inactive_time_interval etc.
>
> So essentialy you (WADI) will be managing all this. So I don't see how the
> container going out of sync with WADI as the container doesn't have
> anything, and WADI is supposed to manage it.
>
> get/setSessions() :
> >
> > These accessors assume that Sessions are stored in a Map and that this
> > is readily get/settable - this is not be the case - Does Axis2 really
> > need it ? If session management is delegated to the SessionManager, why
> > should Axis2 be doing this sort of thing anyway ? Probably to get a list
> >
> > of keys on which to call SessionManager.passivate(String key) ?
> >
> > There are a number of other issues - but they are all resolvable from
> > the WADI side - although, I think that discussion would be useful.
>
>
>  Jules, this  is a mistake, even the transient session manager I have
> doesn't implement it
>  You can ignore this method. I don't manage a hastable of sessions in the
> Axis2SessionManager.
>  It just blindly delegates to the underlying impl.
>
>  If replication/persistance is there then it will be WADI.
>  If people are only using standalone it will be the
> TransientSessionManager I have inside Axis2.
>
> Sorry to push back at you so hard, Rajith, :-)
>
>
> LOL, what do you mean. Constructive critisism is what makes an impl
> better.
> If you don't do it then you are not my friend. I appreciate your concern
> and effort.
>
> BTW - I can't really continue onto to the next test, until we have the
> > enter/leave stuff in, as WADI needs to know when a Session is inactive
> > in order to migrate it...
>
>
> Can't you use the activate/passivateSession(String id) method and  adapt
> by wrapping the session id in this invocation object.
> After the explanations above, is this still not good enough??
>
> If I use enter(Invocation I) and leave (Invocation I) It will be like
> renaming the above 2 methods and wrapping the string session_id inside an
> invocation object.
> So I don't see how that adds anything significant?
>
> If you want to run the test yourself, you will need to follow the
> > getting Started guide to get ActiveMQ and Derby instances up and
> > running, and change out your SessionManager for an
> > org.codehaus.wadi.axis2.Axis2Manager.
> >
> > Jules
>
>
> Once again you effort it really appreciated
>
> --
>
>
> "Open Source is a self-assembling organism. You dangle a piece of
> string into a super-saturated solution and a whole operating-system
> crystallises out around it."
>
> /**********************************
> * Jules Gosnell
> * Partner
> * Core Developers Network (Europe)
> *
> *    www.coredevelopers.net
> *
> * Open Source Training & Support.
> **********************************/
>
>
>

[Jules Gosnell-4]

Rajith Attapattu wrote:

>Jules,
>
>First of all thanks for the effort, I really appreciate it.
>Comments are below
>
>On 4/26/06, Jules Gosnell <jules@...> wrote:
>  
>
>>So,
>>
>>I have just checked in enough of an integration to get the
>>Axis2SessionCreationTest working on top of WADI (It pulls in WebSpec
>>dependencies at the moment, because I am just reusing the Web Session
>>framework, which fits very closely) - but at the moment, I can't enable
>>it in the build, because it uses the full WADI stack including a Spring
>>config that requires Derby and ActiveMQ running - I will disentangle
>>this stuff soon...
>>
>>I thought that I would come straight back to Rajith with issues
>>uncovered so far, before moving on to the next test - so here goes :-)
>>
>>SessionManager lifecycle :
>>
>>WADI has a requirement for a definite start/stop() lifecycle - but
>>org.apache.axis2.session.SessionManager does not see to provide this.
>>For the moment, I am using the ctor to call my start() method, and my
>>stop() method is not being called - can we extend the SessionManager
>>interface with a lifecycle and hook it up on the Axis2 side ?
>>    
>>
>
>   I can include this.
>   I am sure about the start, however I can't garuntee about the stop method
>so that you can do the cleanup properly.
>   I maybe able to get a shutdown hook around it, but other than that I
>can't think of a business case where stop will be called programaticaly from
>axis2 side
>  
>

Does an axis2 server not have a lifecycle itself, that it percolates
down to subcomponents - all I need is to know when the Axis2 Server
shuts down, so I can shutdown myself... - a shutdown hook is likely to
be problematic, because the ordering may be haphazard, some of the
things that I expect to be alive may have attached their own shutdown
hooks and already shutdown - I've had this problem with AMQ...

>Invocation lifecycle :
>  
>
>>WADI needs to know when an invocation for a Session arrives at the edge
>>of the container, when it leaves and which Session it requires. There
>>does not appear to be provision for this in
>>org.apache.axis2.session.SessionManager - can we provide it ? Without
>>this, WADI cannot decide when a Session is inactive, and may be migrated
>>to store or another node. Ideally, the invocation would be passed with
>>the notification e.g. :
>>    
>>
>
>
>  There is already two methods for this
>  public void activateSession(String sessionId);
>  public void passivateSession(String sessionId);
>  
>

Ok - then I think that these are misleading names.
Activation/Passivation has a specific meaning in the Web and EJB Session
worlds and it is not this.

I will work with these methods - but I recommed a name change.

>
>DumbWADISessionManager
>  
>
>>{
>>...
>>  void enter(Invocation i);
>>  void leave(Invocation i);
>>...
>>}
>>    
>>
>
>
>If you want to give WADI enough rope to be able to relocate not only
>  
>
>>Sessions, but also Invocations, then you need to pass flow control into
>>the 'enter()' method as well - with the Servlet spec, this is currently
>>done using a FilterChain - but we can abstract to any sort of e.g.
>>Chain. The 'Chain' will have an e.g. 'next(Invocation i)' method on it,
>>which WADI calls if it wants this Invocation to continue into the local
>>container, but WADI may want to relocate the Invocation to a remote
>>Axis2 instance, where the relevant Session actually resides. in this
>>case, it does not call Chain.next(), but would use tier specific
>>redirection or proxying code to achieve this - e.g.
>>
>>CleverWADISessionManager
>>{
>>...
>>  void enter(Chain , Invocation i);
>>  void leave(Invocation i);
>>}
>>
>>I am happy to go with the 'DumbWADISessionManager' approach initially -
>>but the requirements of the 'CleverWADISessionManager' should be borne
>>in mind.
>>
>>Axis2 must support some form of Invocation type - if you can pass that
>>down, I can adapt WADI to it. If it has an accessor to the Session key,
>>I will use that, otherwise I will need the Session key passed as well.
>>    
>>
>
>
>From an axis2 POV I am not sure how I can abstract the invovation.
>The only thing I get is the sessiond_id extracted from the SOAP envelope.
>Hence I  pass it down.
>
>Well it would be very difficult for WADI (or anything else that sits below
>Axis2) to redirect the invocation.
>Redirecting the invocation means redirecting the entire SOAP envelope.
>This will be a tricky area and I need think and talk to people before
>settling on this.
>  
>

Sure. It means that you need some mechanism for intercepting req/res
pairs (invocations) as they enter the container... In the Web tier you
can do this via a standard Filter or proprietary Valve (TC) or Handler
(Jetty). Is there nothing like this in the Axis2 world ?

>For now as you said lets only worry about replicating and the session
>manager being dumb.
>  
>
OK

>So for the time being the session manager will always request a session
>migration if a node does not have a copy of the session.
>  
>
Yes

>activate/passivateSession(String key) :
>  
>
>>org.apache.axis2.session.SessionManager contains these two methods. I
>>have found that passivateSession is called at the end of the test - I
>>guess to passivate the session that was created. This implies that Axis2
>>is keeping tabs on Sessions itself, rather than delegating this
>>reponsibility to WADI. Since WADI may move Sessions in and out of the
>>container at any time, this is likely to cause problems :-). I can just
>>ignore these methods, but then Axis2 may get the idea that a Session is
>>present when it is not available... There doesn't seem to be a way to
>>communicate to the container that a Session has been timed-out, so the
>>container's copy of the Session list is going to fall out of sync
>>anyway. I think Axis2 should simply call start/stop on the
>>SessionManager and let it worry about what needs activating/passivating
>>and when.
>>    
>>
>
>
>Jules, over here I don't worry about managing the actual session. I just
>blindly call the activateSession(String id)
>and it will be delegated to the WADI session manager.
>So if you implement this method you know a request has arrived for that
>particular session.
>
>Simillaly I call passivateSession(String id) at the end of request and will
>be delegated to you blindly. So u can then either persist and/or replicate
>it.
>I do not explicitly manage the physical session, all methods are delegated
>to the underlying implementation and in this case WADI
>
>I don't even have time out within the Axis2SessionManager. Timeout and other
>things are managed by the Hard impl of the session manager interface.
>So WADI will be managing it. I will be passing down all the info by way of
>delegate.setXXX so you will be getting things like max_no_of sessions,
>max_inactive_time_interval etc.
>
>So essentialy you (WADI) will be managing all this. So I don't see how the
>container going out of sync with WADI as the container doesn't have
>anything, and WADI is supposed to manage it.
>
>get/setSessions() :
>  
>
>>These accessors assume that Sessions are stored in a Map and that this
>>is readily get/settable - this is not be the case - Does Axis2 really
>>need it ? If session management is delegated to the SessionManager, why
>>should Axis2 be doing this sort of thing anyway ? Probably to get a list
>>of keys on which to call SessionManager.passivate(String key) ?
>>
>>There are a number of other issues - but they are all resolvable from
>>the WADI side - although, I think that discussion would be useful.
>>    
>>
>
>
> Jules, this  is a mistake, even the transient session manager I have
>doesn't implement it
> You can ignore this method. I don't manage a hastable of sessions in the
>Axis2SessionManager.
> It just blindly delegates to the underlying impl.
>
> If replication/persistance is there then it will be WADI.
> If people are only using standalone it will be the TransientSessionManager
>I have inside Axis2.
>
>Sorry to push back at you so hard, Rajith, :-)
>
>
>LOL, what do you mean. Constructive critisism is what makes an impl better.
>If you don't do it then you are not my friend. I appreciate your concern and
>effort.
>
>BTW - I can't really continue onto to the next test, until we have the
>  
>
>>enter/leave stuff in, as WADI needs to know when a Session is inactive
>>in order to migrate it...
>>    
>>
>
>
>Can't you use the activate/passivateSession(String id) method and  adapt by
>wrapping the session id in this invocation object.
>  
>

Yes - that is what I had already decided to do.

>After the explanations above, is this still not good enough??
>
>If I use enter(Invocation I) and leave(Invocation I) It will be like
>renaming the above 2 methods and wrapping the string session_id inside an
>invocation object.
>So I don't see how that adds anything significant?
>
>If you want to run the test yourself, you will need to follow the
>  
>
>>getting Started guide to get ActiveMQ and Derby instances up and
>>running, and change out your SessionManager for an
>>org.codehaus.wadi.axis2.Axis2Manager.
>>
>>Jules
>>    
>>
>
>
>Once again you effort it really appreciated
>  
>

welcome,

I'll get back to you when I have a little more, maybe later today.


Jules

>--
>  
>
>>"Open Source is a self-assembling organism. You dangle a piece of
>>string into a super-saturated solution and a whole operating-system
>>crystallises out around it."
>>
>>/**********************************
>>* Jules Gosnell
>>* Partner
>>* Core Developers Network (Europe)
>>*
>>*    www.coredevelopers.net
>>*
>>* Open Source Training & Support.
>>**********************************/
>>
>>
>>    
>>
>
>  
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Rajith Attapattu-2]

Actually, The current Axis2 session manager will be more or less the
TransientSessionManager.

I have kept the delegation model in case if something special needs to be
done then it can achived via a decorator instead of really having to do too
many changes.

But as far as WADI is concerned it will have complete control of all aspects
of the session life cycle from creation to destroy. All operations will be
delegated to it.

Regards,

Rajith.

On 4/26/06, Rajith Attapattu <rajith77@...> wrote:

>
> Jules,
>
> Btw, I have tried to manage sessions explicitly for testing. So I am not
> sure if thats why you might have got confused about axis2 managing sessions
> explicitly.
>
> Let me send you an update source.zip and Axis2.jar that basicaly doesn't
> have these design glitches. However you can continue with the current one as
> you can be rest assure it will be delegate directly and blindly to WADI.
>
> Regards,
>
> Rajith
>
>
> On 4/26/06, Rajith Attapattu <rajith77@...> wrote:
> >
> > Jules,
> >
> > First of all thanks for the effort, I really appreciate it.
> > Comments are below
> >
> > On 4/26/06, Jules Gosnell < jules@...> wrote:
> > >
> > > So,
> > >
> > > I have just checked in enough of an integration to get the
> > > Axis2SessionCreationTest working on top of WADI (It pulls in WebSpec
> > > dependencies at the moment, because I am just reusing the Web Session
> > > framework, which fits very closely) - but at the moment, I can't
> > > enable
> > > it in the build, because it uses the full WADI stack including a
> > > Spring
> > > config that requires Derby and ActiveMQ running - I will disentangle
> > > this stuff soon...
> > >
> > > I thought that I would come straight back to Rajith with issues
> > > uncovered so far, before moving on to the next test - so here goes :-)
> > >
> > > SessionManager lifecycle :
> > >
> > > WADI has a requirement for a definite start/stop() lifecycle - but
> > > org.apache.axis2.session.SessionManager does not see to provide this.
> > > For the moment, I am using the ctor to call my start() method, and my
> > > stop() method is not being called - can we extend the SessionManager
> > > interface with a lifecycle and hook it up on the Axis2 side ?
> >
> >    I can include this.
> >    I am sure about the start, however I can't garuntee about the stop
> > method so that you can do the cleanup properly.
> >    I maybe able to get a shutdown hook around it, but other than that I
> > can't think of a business case where stop will be called programaticaly from
> > axis2 side
> >
> > Invocation lifecycle :
> > >
> > > WADI needs to know when an invocation for a Session arrives at the
> > > edge
> > > of the container, when it leaves and which Session it requires. There
> > > does not appear to be provision for this in
> > > org.apache.axis2.session.SessionManager - can we provide it ? Without
> > > this, WADI cannot decide when a Session is inactive, and may be
> > > migrated
> > > to store or another node. Ideally, the invocation would be passed with
> > > the notification e.g. :
> >
> >
> >   There is already two methods for this
> >   public void activateSession(String sessionId);
> >   public void passivateSession(String sessionId);
> >
> >
> > DumbWADISessionManager
> > > {
> > > ...
> > >   void enter(Invocation i);
> > >   void leave(Invocation i);
> > > ...
> > > }
> >
> >
> > If you want to give WADI enough rope to be able to relocate not only
> > > Sessions, but also Invocations, then you need to pass flow control
> > > into
> > > the 'enter()' method as well - with the Servlet spec, this is
> > > currently
> > > done using a FilterChain - but we can abstract to any sort of e.g.
> > > Chain. The 'Chain' will have an e.g. 'next(Invocation i)' method on
> > > it,
> > > which WADI calls if it wants this Invocation to continue into the
> > > local
> > > container, but WADI may want to relocate the Invocation to a remote
> > > Axis2 instance, where the relevant Session actually resides. in this
> > > case, it does not call Chain.next(), but would use tier specific
> > > redirection or proxying code to achieve this - e.g.
> > >
> > > CleverWADISessionManager
> > > {
> > > ...
> > >   void enter(Chain , Invocation i);
> > >   void leave(Invocation i);
> > > }
> > >
> > > I am happy to go with the 'DumbWADISessionManager' approach initially
> > > -
> > > but the requirements of the 'CleverWADISessionManager' should be borne
> > >
> > > in mind.
> > >
> > > Axis2 must support some form of Invocation type - if you can pass that
> > > down, I can adapt WADI to it. If it has an accessor to the Session
> > > key,
> > > I will use that, otherwise I will need the Session key passed as well.
> > >
> >
> >
> > From an axis2 POV I am not sure how I can abstract the invovation.
> > The only thing I get is the sessiond_id extracted from the SOAP
> > envelope.
> > Hence I  pass it down.
> >
> > Well it would be very difficult for WADI (or anything else that sits
> > below Axis2) to redirect the invocation.
> > Redirecting the invocation means redirecting the entire SOAP envelope.
> > This will be a tricky area and I need think and talk to people before
> > settling on this.
> >  For now as you said lets only worry about replicating and the session
> > manager being dumb.
> > So for the time being the session manager will always request a session
> > migration if a node does not have a copy of the session.
> >
> > activate/passivateSession(String key) :
> > >
> > > org.apache.axis2.session.SessionManager contains these two methods. I
> > > have found that passivateSession is called at the end of the test - I
> > > guess to passivate the session that was created. This implies that
> > > Axis2
> > > is keeping tabs on Sessions itself, rather than delegating this
> > > reponsibility to WADI. Since WADI may move Sessions in and out of the
> > > container at any time, this is likely to cause problems :-). I can
> > > just
> > > ignore these methods, but then Axis2 may get the idea that a Session
> > > is
> > > present when it is not available... There doesn't seem to be a way to
> > > communicate to the container that a Session has been timed-out, so the
> > > container's copy of the Session list is going to fall out of sync
> > > anyway. I think Axis2 should simply call start/stop on the
> > > SessionManager and let it worry about what needs
> > > activating/passivating
> > > and when.
> >
> >
> > Jules, over here I don't worry about managing the actual session. I just
> > blindly call the activateSession(String id)
> > and it will be delegated to the WADI session manager.
> > So if you implement this method you know a request has arrived for that
> > particular session.
> >
> > Simillaly I call passivateSession(String id) at the end of request and
> > will be delegated to you blindly. So u can then either persist and/or
> > replicate it.
> > I do not explicitly manage the physical session, all methods are
> > delegated to the underlying implementation and in this case WADI
> >
> > I don't even have time out within the Axis2SessionManager. Timeout and
> > other things are managed by the Hard impl of the session manager interface.
> > So WADI will be managing it. I will be passing down all the info by way
> > of delegate.setXXX so you will be getting things like max_no_of
> > sessions, max_inactive_time_interval etc.
> >
> > So essentialy you (WADI) will be managing all this. So I don't see how
> > the container going out of sync with WADI as the container doesn't have
> > anything, and WADI is supposed to manage it.
> >
> > get/setSessions() :
> > >
> > > These accessors assume that Sessions are stored in a Map and that this
> > >
> > > is readily get/settable - this is not be the case - Does Axis2 really
> > > need it ? If session management is delegated to the SessionManager,
> > > why
> > > should Axis2 be doing this sort of thing anyway ? Probably to get a
> > > list
> > > of keys on which to call SessionManager.passivate(String key) ?
> > >
> > > There are a number of other issues - but they are all resolvable from
> > > the WADI side - although, I think that discussion would be useful.
> >
> >
> >  Jules, this  is a mistake, even the transient session manager I have
> > doesn't implement it
> >   You can ignore this method. I don't manage a hastable of sessions in
> > the Axis2SessionManager.
> >  It just blindly delegates to the underlying impl.
> >
> >  If replication/persistance is there then it will be WADI.
> >  If people are only using standalone it will be the
> > TransientSessionManager I have inside Axis2.
> >
> > Sorry to push back at you so hard, Rajith, :-)
> >
> >
> > LOL, what do you mean. Constructive critisism is what makes an impl
> > better.
> > If you don't do it then you are not my friend. I appreciate your concern
> > and effort.
> >
> > BTW - I can't really continue onto to the next test, until we have the
> > > enter/leave stuff in, as WADI needs to know when a Session is inactive
> > > in order to migrate it...
> >
> >
> > Can't you use the activate/passivateSession(String id) method and  adapt
> > by wrapping the session id in this invocation object.
> > After the explanations above, is this still not good enough??
> >
> > If I use enter(Invocation I) and leave (Invocation I) It will be like
> > renaming the above 2 methods and wrapping the string session_id inside an
> > invocation object.
> > So I don't see how that adds anything significant?
> >
> > If you want to run the test yourself, you will need to follow the
> > > getting Started guide to get ActiveMQ and Derby instances up and
> > > running, and change out your SessionManager for an
> > > org.codehaus.wadi.axis2.Axis2Manager.
> > >
> > > Jules
> >
> >
> > Once again you effort it really appreciated
> >
> > --
> >
> >
> > "Open Source is a self-assembling organism. You dangle a piece of
> > string into a super-saturated solution and a whole operating-system
> > crystallises out around it."
> >
> > /**********************************
> > * Jules Gosnell
> > * Partner
> > * Core Developers Network (Europe)
> > *
> > *     www.coredevelopers.net
> > *
> > * Open Source Training & Support.
> > **********************************/
> >
> >
> >
>

[Jules Gosnell-4]

So, I've finally got back onto this...

Rajith - is the 'release(String key)' method intended to explicitly
remove a session from service and destroy it ?

Jules


Rajith Attapattu wrote:

>Actually, The current Axis2 session manager will be more or less the
>TransientSessionManager.
>
>I have kept the delegation model in case if something special needs to be
>done then it can achived via a decorator instead of really having to do too
>many changes.
>
>But as far as WADI is concerned it will have complete control of all aspects
>of the session life cycle from creation to destroy. All operations will be
>delegated to it.
>
>Regards,
>
>Rajith.
>
>On 4/26/06, Rajith Attapattu <rajith77@...> wrote:
>  
>
>>Jules,
>>
>>Btw, I have tried to manage sessions explicitly for testing. So I am not
>>sure if thats why you might have got confused about axis2 managing sessions
>>explicitly.
>>
>>Let me send you an update source.zip and Axis2.jar that basicaly doesn't
>>have these design glitches. However you can continue with the current one as
>>you can be rest assure it will be delegate directly and blindly to WADI.
>>
>>Regards,
>>
>>Rajith
>>
>>
>>On 4/26/06, Rajith Attapattu <rajith77@...> wrote:
>>    
>>
>>>Jules,
>>>
>>>First of all thanks for the effort, I really appreciate it.
>>>Comments are below
>>>
>>>On 4/26/06, Jules Gosnell < jules@...> wrote:
>>>      
>>>
>>>>So,
>>>>
>>>>I have just checked in enough of an integration to get the
>>>>Axis2SessionCreationTest working on top of WADI (It pulls in WebSpec
>>>>dependencies at the moment, because I am just reusing the Web Session
>>>>framework, which fits very closely) - but at the moment, I can't
>>>>enable
>>>>it in the build, because it uses the full WADI stack including a
>>>>Spring
>>>>config that requires Derby and ActiveMQ running - I will disentangle
>>>>this stuff soon...
>>>>
>>>>I thought that I would come straight back to Rajith with issues
>>>>uncovered so far, before moving on to the next test - so here goes :-)
>>>>
>>>>SessionManager lifecycle :
>>>>
>>>>WADI has a requirement for a definite start/stop() lifecycle - but
>>>>org.apache.axis2.session.SessionManager does not see to provide this.
>>>>For the moment, I am using the ctor to call my start() method, and my
>>>>stop() method is not being called - can we extend the SessionManager
>>>>interface with a lifecycle and hook it up on the Axis2 side ?
>>>>        
>>>>
>>>   I can include this.
>>>   I am sure about the start, however I can't garuntee about the stop
>>>method so that you can do the cleanup properly.
>>>   I maybe able to get a shutdown hook around it, but other than that I
>>>can't think of a business case where stop will be called programaticaly from
>>>axis2 side
>>>
>>>Invocation lifecycle :
>>>      
>>>
>>>>WADI needs to know when an invocation for a Session arrives at the
>>>>edge
>>>>of the container, when it leaves and which Session it requires. There
>>>>does not appear to be provision for this in
>>>>org.apache.axis2.session.SessionManager - can we provide it ? Without
>>>>this, WADI cannot decide when a Session is inactive, and may be
>>>>migrated
>>>>to store or another node. Ideally, the invocation would be passed with
>>>>the notification e.g. :
>>>>        
>>>>
>>>  There is already two methods for this
>>>  public void activateSession(String sessionId);
>>>  public void passivateSession(String sessionId);
>>>
>>>
>>>DumbWADISessionManager
>>>      
>>>
>>>>{
>>>>...
>>>>  void enter(Invocation i);
>>>>  void leave(Invocation i);
>>>>...
>>>>}
>>>>        
>>>>
>>>If you want to give WADI enough rope to be able to relocate not only
>>>      
>>>
>>>>Sessions, but also Invocations, then you need to pass flow control
>>>>into
>>>>the 'enter()' method as well - with the Servlet spec, this is
>>>>currently
>>>>done using a FilterChain - but we can abstract to any sort of e.g.
>>>>Chain. The 'Chain' will have an e.g. 'next(Invocation i)' method on
>>>>it,
>>>>which WADI calls if it wants this Invocation to continue into the
>>>>local
>>>>container, but WADI may want to relocate the Invocation to a remote
>>>>Axis2 instance, where the relevant Session actually resides. in this
>>>>case, it does not call Chain.next(), but would use tier specific
>>>>redirection or proxying code to achieve this - e.g.
>>>>
>>>>CleverWADISessionManager
>>>>{
>>>>...
>>>>  void enter(Chain , Invocation i);
>>>>  void leave(Invocation i);
>>>>}
>>>>
>>>>I am happy to go with the 'DumbWADISessionManager' approach initially
>>>>-
>>>>but the requirements of the 'CleverWADISessionManager' should be borne
>>>>
>>>>in mind.
>>>>
>>>>Axis2 must support some form of Invocation type - if you can pass that
>>>>down, I can adapt WADI to it. If it has an accessor to the Session
>>>>key,
>>>>I will use that, otherwise I will need the Session key passed as well.
>>>>
>>>>        
>>>>
>>>From an axis2 POV I am not sure how I can abstract the invovation.
>>>The only thing I get is the sessiond_id extracted from the SOAP
>>>envelope.
>>>Hence I  pass it down.
>>>
>>>Well it would be very difficult for WADI (or anything else that sits
>>>below Axis2) to redirect the invocation.
>>>Redirecting the invocation means redirecting the entire SOAP envelope.
>>>This will be a tricky area and I need think and talk to people before
>>>settling on this.
>>> For now as you said lets only worry about replicating and the session
>>>manager being dumb.
>>>So for the time being the session manager will always request a session
>>>migration if a node does not have a copy of the session.
>>>
>>>activate/passivateSession(String key) :
>>>      
>>>
>>>>org.apache.axis2.session.SessionManager contains these two methods. I
>>>>have found that passivateSession is called at the end of the test - I
>>>>guess to passivate the session that was created. This implies that
>>>>Axis2
>>>>is keeping tabs on Sessions itself, rather than delegating this
>>>>reponsibility to WADI. Since WADI may move Sessions in and out of the
>>>>container at any time, this is likely to cause problems :-). I can
>>>>just
>>>>ignore these methods, but then Axis2 may get the idea that a Session
>>>>is
>>>>present when it is not available... There doesn't seem to be a way to
>>>>communicate to the container that a Session has been timed-out, so the
>>>>container's copy of the Session list is going to fall out of sync
>>>>anyway. I think Axis2 should simply call start/stop on the
>>>>SessionManager and let it worry about what needs
>>>>activating/passivating
>>>>and when.
>>>>        
>>>>
>>>Jules, over here I don't worry about managing the actual session. I just
>>>blindly call the activateSession(String id)
>>>and it will be delegated to the WADI session manager.
>>>So if you implement this method you know a request has arrived for that
>>>particular session.
>>>
>>>Simillaly I call passivateSession(String id) at the end of request and
>>>will be delegated to you blindly. So u can then either persist and/or
>>>replicate it.
>>>I do not explicitly manage the physical session, all methods are
>>>delegated to the underlying implementation and in this case WADI
>>>
>>>I don't even have time out within the Axis2SessionManager. Timeout and
>>>other things are managed by the Hard impl of the session manager interface.
>>>So WADI will be managing it. I will be passing down all the info by way
>>>of delegate.setXXX so you will be getting things like max_no_of
>>>sessions, max_inactive_time_interval etc.
>>>
>>>So essentialy you (WADI) will be managing all this. So I don't see how
>>>the container going out of sync with WADI as the container doesn't have
>>>anything, and WADI is supposed to manage it.
>>>
>>>get/setSessions() :
>>>      
>>>
>>>>These accessors assume that Sessions are stored in a Map and that this
>>>>
>>>>is readily get/settable - this is not be the case - Does Axis2 really
>>>>need it ? If session management is delegated to the SessionManager,
>>>>why
>>>>should Axis2 be doing this sort of thing anyway ? Probably to get a
>>>>list
>>>>of keys on which to call SessionManager.passivate(String key) ?
>>>>
>>>>There are a number of other issues - but they are all resolvable from
>>>>the WADI side - although, I think that discussion would be useful.
>>>>        
>>>>
>>> Jules, this  is a mistake, even the transient session manager I have
>>>doesn't implement it
>>>  You can ignore this method. I don't manage a hastable of sessions in
>>>the Axis2SessionManager.
>>> It just blindly delegates to the underlying impl.
>>>
>>> If replication/persistance is there then it will be WADI.
>>> If people are only using standalone it will be the
>>>TransientSessionManager I have inside Axis2.
>>>
>>>Sorry to push back at you so hard, Rajith, :-)
>>>
>>>
>>>LOL, what do you mean. Constructive critisism is what makes an impl
>>>better.
>>>If you don't do it then you are not my friend. I appreciate your concern
>>>and effort.
>>>
>>>BTW - I can't really continue onto to the next test, until we have the
>>>      
>>>
>>>>enter/leave stuff in, as WADI needs to know when a Session is inactive
>>>>in order to migrate it...
>>>>        
>>>>
>>>Can't you use the activate/passivateSession(String id) method and  adapt
>>>by wrapping the session id in this invocation object.
>>>After the explanations above, is this still not good enough??
>>>
>>>If I use enter(Invocation I) and leave (Invocation I) It will be like
>>>renaming the above 2 methods and wrapping the string session_id inside an
>>>invocation object.
>>>So I don't see how that adds anything significant?
>>>
>>>If you want to run the test yourself, you will need to follow the
>>>      
>>>
>>>>getting Started guide to get ActiveMQ and Derby instances up and
>>>>running, and change out your SessionManager for an
>>>>org.codehaus.wadi.axis2.Axis2Manager.
>>>>
>>>>Jules
>>>>        
>>>>
>>>Once again you effort it really appreciated
>>>
>>>--
>>>
>>>
>>>"Open Source is a self-assembling organism. You dangle a piece of
>>>string into a super-saturated solution and a whole operating-system
>>>crystallises out around it."
>>>
>>>/**********************************
>>>* Jules Gosnell
>>>* Partner
>>>* Core Developers Network (Europe)
>>>*
>>>*     www.coredevelopers.net
>>>*
>>>* Open Source Training & Support.
>>>**********************************/
>>>
>>>
>>>
>>>      
>>>
>
>  
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Rajith Attapattu-2]

Yep, thats to get rid of the session.

Jules let me actually send a description of the methods so that if there is
any dobut it will clear it up.
Sorry if the names confuse you.

Regards,

Rajith

On 4/27/06, Jules Gosnell <jules@...> wrote:

>
> So, I've finally got back onto this...
>
> Rajith - is the 'release(String key)' method intended to explicitly
> remove a session from service and destroy it ?
>
> Jules
>
>
> Rajith Attapattu wrote:
>
> >Actually, The current Axis2 session manager will be more or less the
> >TransientSessionManager.
> >
> >I have kept the delegation model in case if something special needs to be
> >done then it can achived via a decorator instead of really having to do
> too
> >many changes.
> >
> >But as far as WADI is concerned it will have complete control of all
> aspects
> >of the session life cycle from creation to destroy. All operations will
> be
> >delegated to it.
> >
> >Regards,
> >
> >Rajith.
> >
> >On 4/26/06, Rajith Attapattu <rajith77@...> wrote:
> >
> >
> >>Jules,
> >>
> >>Btw, I have tried to manage sessions explicitly for testing. So I am not
> >>sure if thats why you might have got confused about axis2 managing
> sessions
> >>explicitly.
> >>
> >>Let me send you an update source.zip and Axis2.jar that basicaly doesn't
> >>have these design glitches. However you can continue with the current
> one as
> >>you can be rest assure it will be delegate directly and blindly to WADI.
> >>
> >>Regards,
> >>
> >>Rajith
> >>
> >>
> >>On 4/26/06, Rajith Attapattu <rajith77@...> wrote:
> >>
> >>
> >>>Jules,
> >>>
> >>>First of all thanks for the effort, I really appreciate it.
> >>>Comments are below
> >>>
> >>>On 4/26/06, Jules Gosnell < jules@...> wrote:
> >>>
> >>>
> >>>>So,
> >>>>
> >>>>I have just checked in enough of an integration to get the
> >>>>Axis2SessionCreationTest working on top of WADI (It pulls in WebSpec
> >>>>dependencies at the moment, because I am just reusing the Web Session
> >>>>framework, which fits very closely) - but at the moment, I can't
> >>>>enable
> >>>>it in the build, because it uses the full WADI stack including a
> >>>>Spring
> >>>>config that requires Derby and ActiveMQ running - I will disentangle
> >>>>this stuff soon...
> >>>>
> >>>>I thought that I would come straight back to Rajith with issues
> >>>>uncovered so far, before moving on to the next test - so here goes :-)
> >>>>
> >>>>SessionManager lifecycle :
> >>>>
> >>>>WADI has a requirement for a definite start/stop() lifecycle - but
> >>>>org.apache.axis2.session.SessionManager does not see to provide this.
> >>>>For the moment, I am using the ctor to call my start() method, and my
> >>>>stop() method is not being called - can we extend the SessionManager
> >>>>interface with a lifecycle and hook it up on the Axis2 side ?
> >>>>
> >>>>
> >>>   I can include this.
> >>>   I am sure about the start, however I can't garuntee about the stop
> >>>method so that you can do the cleanup properly.
> >>>   I maybe able to get a shutdown hook around it, but other than that I
> >>>can't think of a business case where stop will be called programaticaly
> from
> >>>axis2 side
> >>>
> >>>Invocation lifecycle :
> >>>
> >>>
> >>>>WADI needs to know when an invocation for a Session arrives at the
> >>>>edge
> >>>>of the container, when it leaves and which Session it requires. There
> >>>>does not appear to be provision for this in
> >>>>org.apache.axis2.session.SessionManager - can we provide it ? Without
> >>>>this, WADI cannot decide when a Session is inactive, and may be
> >>>>migrated
> >>>>to store or another node. Ideally, the invocation would be passed with
> >>>>the notification e.g. :
> >>>>
> >>>>
> >>>  There is already two methods for this
> >>>  public void activateSession(String sessionId);
> >>>  public void passivateSession(String sessionId);
> >>>
> >>>
> >>>DumbWADISessionManager
> >>>
> >>>
> >>>>{
> >>>>...
> >>>>  void enter(Invocation i);
> >>>>  void leave(Invocation i);
> >>>>...
> >>>>}
> >>>>
> >>>>
> >>>If you want to give WADI enough rope to be able to relocate not only
> >>>
> >>>
> >>>>Sessions, but also Invocations, then you need to pass flow control
> >>>>into
> >>>>the 'enter()' method as well - with the Servlet spec, this is
> >>>>currently
> >>>>done using a FilterChain - but we can abstract to any sort of e.g.
> >>>>Chain. The 'Chain' will have an e.g. 'next(Invocation i)' method on
> >>>>it,
> >>>>which WADI calls if it wants this Invocation to continue into the
> >>>>local
> >>>>container, but WADI may want to relocate the Invocation to a remote
> >>>>Axis2 instance, where the relevant Session actually resides. in this
> >>>>case, it does not call Chain.next(), but would use tier specific
> >>>>redirection or proxying code to achieve this - e.g.
> >>>>
> >>>>CleverWADISessionManager
> >>>>{
> >>>>...
> >>>>  void enter(Chain , Invocation i);
> >>>>  void leave(Invocation i);
> >>>>}
> >>>>
> >>>>I am happy to go with the 'DumbWADISessionManager' approach initially
> >>>>-
> >>>>but the requirements of the 'CleverWADISessionManager' should be borne
> >>>>
> >>>>in mind.
> >>>>
> >>>>Axis2 must support some form of Invocation type - if you can pass that
> >>>>down, I can adapt WADI to it. If it has an accessor to the Session
> >>>>key,
> >>>>I will use that, otherwise I will need the Session key passed as well.
> >>>>
> >>>>
> >>>>
> >>>From an axis2 POV I am not sure how I can abstract the invovation.
> >>>The only thing I get is the sessiond_id extracted from the SOAP
> >>>envelope.
> >>>Hence I  pass it down.
> >>>
> >>>Well it would be very difficult for WADI (or anything else that sits
> >>>below Axis2) to redirect the invocation.
> >>>Redirecting the invocation means redirecting the entire SOAP envelope.
> >>>This will be a tricky area and I need think and talk to people before
> >>>settling on this.
> >>> For now as you said lets only worry about replicating and the session
> >>>manager being dumb.
> >>>So for the time being the session manager will always request a session
> >>>migration if a node does not have a copy of the session.
> >>>
> >>>activate/passivateSession(String key) :
> >>>
> >>>
> >>>>org.apache.axis2.session.SessionManager contains these two methods. I
> >>>>have found that passivateSession is called at the end of the test - I
> >>>>guess to passivate the session that was created. This implies that
> >>>>Axis2
> >>>>is keeping tabs on Sessions itself, rather than delegating this
> >>>>reponsibility to WADI. Since WADI may move Sessions in and out of the
> >>>>container at any time, this is likely to cause problems :-). I can
> >>>>just
> >>>>ignore these methods, but then Axis2 may get the idea that a Session
> >>>>is
> >>>>present when it is not available... There doesn't seem to be a way to
> >>>>communicate to the container that a Session has been timed-out, so the
> >>>>container's copy of the Session list is going to fall out of sync
> >>>>anyway. I think Axis2 should simply call start/stop on the
> >>>>SessionManager and let it worry about what needs
> >>>>activating/passivating
> >>>>and when.
> >>>>
> >>>>
> >>>Jules, over here I don't worry about managing the actual session. I
> just
> >>>blindly call the activateSession(String id)
> >>>and it will be delegated to the WADI session manager.
> >>>So if you implement this method you know a request has arrived for that
> >>>particular session.
> >>>
> >>>Simillaly I call passivateSession(String id) at the end of request and
> >>>will be delegated to you blindly. So u can then either persist and/or
> >>>replicate it.
> >>>I do not explicitly manage the physical session, all methods are
> >>>delegated to the underlying implementation and in this case WADI
> >>>
> >>>I don't even have time out within the Axis2SessionManager. Timeout and
> >>>other things are managed by the Hard impl of the session manager
> interface.
> >>>So WADI will be managing it. I will be passing down all the info by way
> >>>of delegate.setXXX so you will be getting things like max_no_of
> >>>sessions, max_inactive_time_interval etc.
> >>>
> >>>So essentialy you (WADI) will be managing all this. So I don't see how
> >>>the container going out of sync with WADI as the container doesn't have
> >>>anything, and WADI is supposed to manage it.
> >>>
> >>>get/setSessions() :
> >>>
> >>>
> >>>>These accessors assume that Sessions are stored in a Map and that this
> >>>>
> >>>>is readily get/settable - this is not be the case - Does Axis2 really
> >>>>need it ? If session management is delegated to the SessionManager,
> >>>>why
> >>>>should Axis2 be doing this sort of thing anyway ? Probably to get a
> >>>>list
> >>>>of keys on which to call SessionManager.passivate(String key) ?
> >>>>
> >>>>There are a number of other issues - but they are all resolvable from
> >>>>the WADI side - although, I think that discussion would be useful.
> >>>>
> >>>>
> >>> Jules, this  is a mistake, even the transient session manager I have
> >>>doesn't implement it
> >>>  You can ignore this method. I don't manage a hastable of sessions in
> >>>the Axis2SessionManager.
> >>> It just blindly delegates to the underlying impl.
> >>>
> >>> If replication/persistance is there then it will be WADI.
> >>> If people are only using standalone it will be the
> >>>TransientSessionManager I have inside Axis2.
> >>>
> >>>Sorry to push back at you so hard, Rajith, :-)
> >>>
> >>>
> >>>LOL, what do you mean. Constructive critisism is what makes an impl
> >>>better.
> >>>If you don't do it then you are not my friend. I appreciate your
> concern
> >>>and effort.
> >>>
> >>>BTW - I can't really continue onto to the next test, until we have the
> >>>
> >>>
> >>>>enter/leave stuff in, as WADI needs to know when a Session is inactive
> >>>>in order to migrate it...
> >>>>
> >>>>
> >>>Can't you use the activate/passivateSession(String id) method
> and  adapt
> >>>by wrapping the session id in this invocation object.
> >>>After the explanations above, is this still not good enough??
> >>>
> >>>If I use enter(Invocation I) and leave (Invocation I) It will be like
> >>>renaming the above 2 methods and wrapping the string session_id inside
> an
> >>>invocation object.
> >>>So I don't see how that adds anything significant?
> >>>
> >>>If you want to run the test yourself, you will need to follow the
> >>>
> >>>
> >>>>getting Started guide to get ActiveMQ and Derby instances up and
> >>>>running, and change out your SessionManager for an
> >>>>org.codehaus.wadi.axis2.Axis2Manager.
> >>>>
> >>>>Jules
> >>>>
> >>>>
> >>>Once again you effort it really appreciated
> >>>
> >>>--
> >>>
> >>>
> >>>"Open Source is a self-assembling organism. You dangle a piece of
> >>>string into a super-saturated solution and a whole operating-system
> >>>crystallises out around it."
> >>>
> >>>/**********************************
> >>>* Jules Gosnell
> >>>* Partner
> >>>* Core Developers Network (Europe)
> >>>*
> >>>*     www.coredevelopers.net
> >>>*
> >>>* Open Source Training & Support.
> >>>**********************************/
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
>
>
> --
> "Open Source is a self-assembling organism. You dangle a piece of
> string into a super-saturated solution and a whole operating-system
> crystallises out around it."
>
> /**********************************
> * Jules Gosnell
> * Partner
> * Core Developers Network (Europe)
> *
> *    www.coredevelopers.net
> *
> * Open Source Training & Support.
> **********************************/
>
>

[Jules Gosnell-4]

Rajith Attapattu wrote:

>Yep, thats to get rid of the session.
>
>Jules let me actually send a description of the methods so that if there is
>any dobut it will clear it up.
>Sorry if the names confuse you.
>  
>
I think that I have them all figured out now - we just use slightly
different terminology :-) - so don't worry - we can review naming if
necessary once it is all hooked up.

I have been doing some refactoring in WADI to better accomodate the
Axis2 stuff - I hope to get back to it shortly.

Jules

>Regards,
>
>Rajith
>
>On 4/27/06, Jules Gosnell <jules@...> wrote:
>  
>
>>So, I've finally got back onto this...
>>
>>Rajith - is the 'release(String key)' method intended to explicitly
>>remove a session from service and destroy it ?
>>
>>Jules
>>
>>
>>Rajith Attapattu wrote:
>>
>>    
>>
>>>Actually, The current Axis2 session manager will be more or less the
>>>TransientSessionManager.
>>>
>>>I have kept the delegation model in case if something special needs to be
>>>done then it can achived via a decorator instead of really having to do
>>>      
>>>
>>too
>>    
>>
>>>many changes.
>>>
>>>But as far as WADI is concerned it will have complete control of all
>>>      
>>>
>>aspects
>>    
>>
>>>of the session life cycle from creation to destroy. All operations will
>>>      
>>>
>>be
>>    
>>
>>>delegated to it.
>>>
>>>Regards,
>>>
>>>Rajith.
>>>
>>>On 4/26/06, Rajith Attapattu <rajith77@...> wrote:
>>>
>>>
>>>      
>>>
>>>>Jules,
>>>>
>>>>Btw, I have tried to manage sessions explicitly for testing. So I am not
>>>>sure if thats why you might have got confused about axis2 managing
>>>>        
>>>>
>>sessions
>>    
>>
>>>>explicitly.
>>>>
>>>>Let me send you an update source.zip and Axis2.jar that basicaly doesn't
>>>>have these design glitches. However you can continue with the current
>>>>        
>>>>
>>one as
>>    
>>
>>>>you can be rest assure it will be delegate directly and blindly to WADI.
>>>>
>>>>Regards,
>>>>
>>>>Rajith
>>>>
>>>>
>>>>On 4/26/06, Rajith Attapattu <rajith77@...> wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>Jules,
>>>>>
>>>>>First of all thanks for the effort, I really appreciate it.
>>>>>Comments are below
>>>>>
>>>>>On 4/26/06, Jules Gosnell < jules@...> wrote:
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>So,
>>>>>>
>>>>>>I have just checked in enough of an integration to get the
>>>>>>Axis2SessionCreationTest working on top of WADI (It pulls in WebSpec
>>>>>>dependencies at the moment, because I am just reusing the Web Session
>>>>>>framework, which fits very closely) - but at the moment, I can't
>>>>>>enable
>>>>>>it in the build, because it uses the full WADI stack including a
>>>>>>Spring
>>>>>>config that requires Derby and ActiveMQ running - I will disentangle
>>>>>>this stuff soon...
>>>>>>
>>>>>>I thought that I would come straight back to Rajith with issues
>>>>>>uncovered so far, before moving on to the next test - so here goes :-)
>>>>>>
>>>>>>SessionManager lifecycle :
>>>>>>
>>>>>>WADI has a requirement for a definite start/stop() lifecycle - but
>>>>>>org.apache.axis2.session.SessionManager does not see to provide this.
>>>>>>For the moment, I am using the ctor to call my start() method, and my
>>>>>>stop() method is not being called - can we extend the SessionManager
>>>>>>interface with a lifecycle and hook it up on the Axis2 side ?
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>  I can include this.
>>>>>  I am sure about the start, however I can't garuntee about the stop
>>>>>method so that you can do the cleanup properly.
>>>>>  I maybe able to get a shutdown hook around it, but other than that I
>>>>>can't think of a business case where stop will be called programaticaly
>>>>>          
>>>>>
>>from
>>    
>>
>>>>>axis2 side
>>>>>
>>>>>Invocation lifecycle :
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>WADI needs to know when an invocation for a Session arrives at the
>>>>>>edge
>>>>>>of the container, when it leaves and which Session it requires. There
>>>>>>does not appear to be provision for this in
>>>>>>org.apache.axis2.session.SessionManager - can we provide it ? Without
>>>>>>this, WADI cannot decide when a Session is inactive, and may be
>>>>>>migrated
>>>>>>to store or another node. Ideally, the invocation would be passed with
>>>>>>the notification e.g. :
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>> There is already two methods for this
>>>>> public void activateSession(String sessionId);
>>>>> public void passivateSession(String sessionId);
>>>>>
>>>>>
>>>>>DumbWADISessionManager
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>{
>>>>>>...
>>>>>> void enter(Invocation i);
>>>>>> void leave(Invocation i);
>>>>>>...
>>>>>>}
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>If you want to give WADI enough rope to be able to relocate not only
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>Sessions, but also Invocations, then you need to pass flow control
>>>>>>into
>>>>>>the 'enter()' method as well - with the Servlet spec, this is
>>>>>>currently
>>>>>>done using a FilterChain - but we can abstract to any sort of e.g.
>>>>>>Chain. The 'Chain' will have an e.g. 'next(Invocation i)' method on
>>>>>>it,
>>>>>>which WADI calls if it wants this Invocation to continue into the
>>>>>>local
>>>>>>container, but WADI may want to relocate the Invocation to a remote
>>>>>>Axis2 instance, where the relevant Session actually resides. in this
>>>>>>case, it does not call Chain.next(), but would use tier specific
>>>>>>redirection or proxying code to achieve this - e.g.
>>>>>>
>>>>>>CleverWADISessionManager
>>>>>>{
>>>>>>...
>>>>>> void enter(Chain , Invocation i);
>>>>>> void leave(Invocation i);
>>>>>>}
>>>>>>
>>>>>>I am happy to go with the 'DumbWADISessionManager' approach initially
>>>>>>-
>>>>>>but the requirements of the 'CleverWADISessionManager' should be borne
>>>>>>
>>>>>>in mind.
>>>>>>
>>>>>>Axis2 must support some form of Invocation type - if you can pass that
>>>>>>down, I can adapt WADI to it. If it has an accessor to the Session
>>>>>>key,
>>>>>>I will use that, otherwise I will need the Session key passed as well.
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>From an axis2 POV I am not sure how I can abstract the invovation.
>>>>        
>>>>
>>>>>The only thing I get is the sessiond_id extracted from the SOAP
>>>>>envelope.
>>>>>Hence I  pass it down.
>>>>>
>>>>>Well it would be very difficult for WADI (or anything else that sits
>>>>>below Axis2) to redirect the invocation.
>>>>>Redirecting the invocation means redirecting the entire SOAP envelope.
>>>>>This will be a tricky area and I need think and talk to people before
>>>>>settling on this.
>>>>>For now as you said lets only worry about replicating and the session
>>>>>manager being dumb.
>>>>>So for the time being the session manager will always request a session
>>>>>migration if a node does not have a copy of the session.
>>>>>
>>>>>activate/passivateSession(String key) :
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>org.apache.axis2.session.SessionManager contains these two methods. I
>>>>>>have found that passivateSession is called at the end of the test - I
>>>>>>guess to passivate the session that was created. This implies that
>>>>>>Axis2
>>>>>>is keeping tabs on Sessions itself, rather than delegating this
>>>>>>reponsibility to WADI. Since WADI may move Sessions in and out of the
>>>>>>container at any time, this is likely to cause problems :-). I can
>>>>>>just
>>>>>>ignore these methods, but then Axis2 may get the idea that a Session
>>>>>>is
>>>>>>present when it is not available... There doesn't seem to be a way to
>>>>>>communicate to the container that a Session has been timed-out, so the
>>>>>>container's copy of the Session list is going to fall out of sync
>>>>>>anyway. I think Axis2 should simply call start/stop on the
>>>>>>SessionManager and let it worry about what needs
>>>>>>activating/passivating
>>>>>>and when.
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>Jules, over here I don't worry about managing the actual session. I
>>>>>          
>>>>>
>>just
>>    
>>
>>>>>blindly call the activateSession(String id)
>>>>>and it will be delegated to the WADI session manager.
>>>>>So if you implement this method you know a request has arrived for that
>>>>>particular session.
>>>>>
>>>>>Simillaly I call passivateSession(String id) at the end of request and
>>>>>will be delegated to you blindly. So u can then either persist and/or
>>>>>replicate it.
>>>>>I do not explicitly manage the physical session, all methods are
>>>>>delegated to the underlying implementation and in this case WADI
>>>>>
>>>>>I don't even have time out within the Axis2SessionManager. Timeout and
>>>>>other things are managed by the Hard impl of the session manager
>>>>>          
>>>>>
>>interface.
>>    
>>
>>>>>So WADI will be managing it. I will be passing down all the info by way
>>>>>of delegate.setXXX so you will be getting things like max_no_of
>>>>>sessions, max_inactive_time_interval etc.
>>>>>
>>>>>So essentialy you (WADI) will be managing all this. So I don't see how
>>>>>the container going out of sync with WADI as the container doesn't have
>>>>>anything, and WADI is supposed to manage it.
>>>>>
>>>>>get/setSessions() :
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>These accessors assume that Sessions are stored in a Map and that this
>>>>>>
>>>>>>is readily get/settable - this is not be the case - Does Axis2 really
>>>>>>need it ? If session management is delegated to the SessionManager,
>>>>>>why
>>>>>>should Axis2 be doing this sort of thing anyway ? Probably to get a
>>>>>>list
>>>>>>of keys on which to call SessionManager.passivate(String key) ?
>>>>>>
>>>>>>There are a number of other issues - but they are all resolvable from
>>>>>>the WADI side - although, I think that discussion would be useful.
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>Jules, this  is a mistake, even the transient session manager I have
>>>>>doesn't implement it
>>>>> You can ignore this method. I don't manage a hastable of sessions in
>>>>>the Axis2SessionManager.
>>>>>It just blindly delegates to the underlying impl.
>>>>>
>>>>>If replication/persistance is there then it will be WADI.
>>>>>If people are only using standalone it will be the
>>>>>TransientSessionManager I have inside Axis2.
>>>>>
>>>>>Sorry to push back at you so hard, Rajith, :-)
>>>>>
>>>>>
>>>>>LOL, what do you mean. Constructive critisism is what makes an impl
>>>>>better.
>>>>>If you don't do it then you are not my friend. I appreciate your
>>>>>          
>>>>>
>>concern
>>    
>>
>>>>>and effort.
>>>>>
>>>>>BTW - I can't really continue onto to the next test, until we have the
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>enter/leave stuff in, as WADI needs to know when a Session is inactive
>>>>>>in order to migrate it...
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>Can't you use the activate/passivateSession(String id) method
>>>>>          
>>>>>
>>and  adapt
>>    
>>
>>>>>by wrapping the session id in this invocation object.
>>>>>After the explanations above, is this still not good enough??
>>>>>
>>>>>If I use enter(Invocation I) and leave (Invocation I) It will be like
>>>>>renaming the above 2 methods and wrapping the string session_id inside
>>>>>          
>>>>>
>>an
>>    
>>
>>>>>invocation object.
>>>>>So I don't see how that adds anything significant?
>>>>>
>>>>>If you want to run the test yourself, you will need to follow the
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>getting Started guide to get ActiveMQ and Derby instances up and
>>>>>>running, and change out your SessionManager for an
>>>>>>org.codehaus.wadi.axis2.Axis2Manager.
>>>>>>
>>>>>>Jules
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>Once again you effort it really appreciated
>>>>>
>>>>>--
>>>>>
>>>>>
>>>>>"Open Source is a self-assembling organism. You dangle a piece of
>>>>>string into a super-saturated solution and a whole operating-system
>>>>>crystallises out around it."
>>>>>
>>>>>/**********************************
>>>>>* Jules Gosnell
>>>>>* Partner
>>>>>* Core Developers Network (Europe)
>>>>>*
>>>>>*     www.coredevelopers.net
>>>>>*
>>>>>* Open Source Training & Support.
>>>>>**********************************/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>
>>>      
>>>
>>--
>>"Open Source is a self-assembling organism. You dangle a piece of
>>string into a super-saturated solution and a whole operating-system
>>crystallises out around it."
>>
>>/**********************************
>>* Jules Gosnell
>>* Partner
>>* Core Developers Network (Europe)
>>*
>>*    www.coredevelopers.net
>>*
>>* Open Source Training & Support.
>>**********************************/
>>
>>
>>    
>>
>
>  
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Rajith Attapattu-2]

Awesome, to be honest the discussions we had inside Geronimo, offiline and
in WADI really helped me a lot to shape the current Session Mgt API. So
thanks jules for the support.

Btw, I am going to look at the code you have done and slowly pick up the
stuff.

Regards,

Rajith

On 4/27/06, Jules Gosnell <jules@...> wrote:

>
> Rajith Attapattu wrote:
>
> >Yep, thats to get rid of the session.
> >
> >Jules let me actually send a description of the methods so that if there
> is
> >any dobut it will clear it up.
> >Sorry if the names confuse you.
> >
> >
> I think that I have them all figured out now - we just use slightly
> different terminology :-) - so don't worry - we can review naming if
> necessary once it is all hooked up.
>
> I have been doing some refactoring in WADI to better accomodate the
> Axis2 stuff - I hope to get back to it shortly.
>
> Jules
>

[Jules Gosnell-4]

Rajith,

Things are a little trickier than I expected - its a long time since I
wrote this code and I had forgotten how it worked :-( ...

The fallout is that, in order for the solution that I am trying (I think
this solution will be shortterm as it involves some hairy thread
coordination), I need you to call SessionManager.activateSession() even
when you do not have a session - i.e. as an invocation with no session
enters the container - unless you can prove to yourself that it will not
try to create one (in which case you will never have to call passivate
on the way out) .... So, in this case, I need you to call
'SessionManager.activateSession(null)'. Is this OK - can you get [a]
fresh jar[s] to me that do[es] this ?

Cheers,

Jules


Rajith Attapattu wrote:

>Awesome, to be honest the discussions we had inside Geronimo, offline and
>in WADI really helped me a lot to shape the current Session Mgt API. So
>thanks jules for the support.
>
>Btw, I am going to look at the code you have done and slowly pick up the
>stuff.
>
>Regards,
>
>Rajith
>
>On 4/27/06, Jules Gosnell <jules@...> wrote:
>  
>
>>Rajith Attapattu wrote:
>>
>>    
>>
>>>Yep, thats to get rid of the session.
>>>
>>>Jules let me actually send a description of the methods so that if there
>>>      
>>>
>>is
>>    
>>
>>>any dobut it will clear it up.
>>>Sorry if the names confuse you.
>>>
>>>
>>>      
>>>
>>I think that I have them all figured out now - we just use slightly
>>different terminology :-) - so don't worry - we can review naming if
>>necessary once it is all hooked up.
>>
>>I have been doing some refactoring in WADI to better accomodate the
>>Axis2 stuff - I hope to get back to it shortly.
>>
>>Jules
>>
>>    
>>
>
>  
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Rajith Attapattu-2]

Hi Jules,

Sorry for the late reply, but I wanted spend some time looking at the code
before asking questions.

First of all I didn't understand what you meant by
> I need you to call SessionManager.activateSession() even
> when you do not have a session - i.e. as an invocation with no session
enters the container -
In such a case I create a new session. Do u want me to call
activateSession() immediately after creating a session?
just for me to understand why is this nessacery?
what impact does it have on the passivateSession() ?

Ok, I have more questions and I hope you wouldn't mind :-)
(This is merely for my understanding and please do not think I am
scrutinizing your code)
Your comments will really help me to understand the code .

1. Where is the session table maintained? I see you are retriving the
session from the Axis2Invocation?
2. Who is responsible for setting the session into Axis2Invocation?
3.  I assume the Axis2Invocation represents the request ?
4.  I didn't understand the Contextualiser Stack, u have comments on it but
I see no reference to it.
    (I know the Rendezvous is used to exchange an object btw threads in a
thread safe way. I assume it' used here to exchnage control btw the
contextualier stack and the invocation thread?)
5. What does the wadi.around(Invocation inv) method do ?

6. Why does the wadi session implement HttpSession? is it bcos there is a
dependency to this partcular interface inside the core ? I assume you  are
still in the middle of refactoring to make wadi more generic than web
clustering?

7. I understand that everything in wadi is wired through spring right? I
need to find the best place to store the wad-axis2.xml.

Thanks in advance,

Rajith

On 4/28/06, Jules Gosnell <jules@...> wrote:

>
> Rajith,
>
> Things are a little trickier than I expected - its a long time since I
> wrote this code and I had forgotten how it worked :-( ...
>
> The fallout is that, in order for the solution that I am trying (I think
> this solution will be shortterm as it involves some hairy thread
> coordination), I need you to call SessionManager.activateSession() even
> when you do not have a session - i.e. as an invocation with no session
> enters the container - unless you can prove to yourself that it will not
> try to create one (in which case you will never have to call passivate
> on the way out) .... So, in this case, I need you to call
> 'SessionManager.activateSession(null)'. Is this OK - can you get [a]
> fresh jar[s] to me that do[es] this ?
>
> Cheers,
>
> Jules
>
>
> Rajith Attapattu wrote:
>
> >Awesome, to be honest the discussions we had inside Geronimo, offline and
> >in WADI really helped me a lot to shape the current Session Mgt API. So
> >thanks jules for the support.
> >
> >Btw, I am going to look at the code you have done and slowly pick up the
> >stuff.
> >
> >Regards,
> >
> >Rajith
> >
> >On 4/27/06, Jules Gosnell <jules@...> wrote:
> >
> >
> >>Rajith Attapattu wrote:
> >>
> >>
> >>
> >>>Yep, thats to get rid of the session.
> >>>
> >>>Jules let me actually send a description of the methods so that if
> there
> >>>
> >>>
> >>is
> >>
> >>
> >>>any dobut it will clear it up.
> >>>Sorry if the names confuse you.
> >>>
> >>>
> >>>
> >>>
> >>I think that I have them all figured out now - we just use slightly
> >>different terminology :-) - so don't worry - we can review naming if
> >>necessary once it is all hooked up.
> >>
> >>I have been doing some refactoring in WADI to better accomodate the
> >>Axis2 stuff - I hope to get back to it shortly.
> >>
> >>Jules
> >>
> >>
> >>
> >
> >
> >
>
>
> --
> "Open Source is a self-assembling organism. You dangle a piece of
> string into a super-saturated solution and a whole operating-system
> crystallises out around it."
>
> /**********************************
> * Jules Gosnell
> * Partner
> * Core Developers Network (Europe)
> *
> *    www.coredevelopers.net
> *
> * Open Source Training & Support.
> **********************************/
>
>

[Jules Gosnell-4]

Rajith Attapattu wrote:

> Hi Jules,
>
> Sorry for the late reply, but I wanted spend some time looking at the
> code
> before asking questions.
>
> First of all I didn't understand what you meant by
>
>> I need you to call SessionManager.activateSession() even
>> when you do not have a session - i.e. as an invocation with no session
>
> enters the container -

> In such a case I create a new session. Do u want me to call
> activateSession() immediately after creating a session?
> just for me to understand why is this nessacery?
> what impact does it have on the passivateSession() ?


I would need you to call me before creating the session.
Think of activateSession() not as activating a Session, but marking the
entry of a request into the container and giving WADI a chance to
prepare for it.
All Session interactions must be done with WADI between your activate
and passivateSession.

>
> Ok, I have more questions and I hope you wouldn't mind :-)
> (This is merely for my understanding and please do not think I am
> scrutinizing your code)
> Your comments will really help me to understand the code .
>
> 1. Where is the session table maintained? I see you are retriving the
> session from the Axis2Invocation?

It is shared between the various Contextualisers, depending on a
Session's place in the stack - i.e. memory, paged out or persisted
between cluster incarnations.
Sessions retrieved from WADI are cached on the relevant Invocation so
that they may be retrieved multiple times by the request without
creating further contention on the MemoryContextualiser.

Thinking about it, this imposes an extra constraint on you that is
present in the web and ejb specs already - namely that only a request
thread may retrieve and r/w a session.

> 2. Who is responsible for setting the session into Axis2Invocation?

WADI

> 3.  I assume the Axis2Invocation represents the request ?

yes

> 4.  I didn't understand the Contextualiser Stack, u have comments on
> it but
> I see no reference to it.

Think of WADI as inserting an Interceptor into the stack on which an
Axis2 request/response (invocation) travels.
Then imagine that internally, WADI is made of its own interceptor
(Contextualiser) stack.
On intercepting a request/response, WADI wraps it into an Invocation
(common cross-tier representation) and passes it down its own
interceptor stack, which is written in terms of Invocations.
Most of the  contextualisers in WADI's stack map to a form of storage.
As the Invocation travels down the stack, we check Memory, a paging area
(local disc), a clustered store etc for the Session.
As soon as the Session is found it is promoted up into the
MemortyContextualiser, attacked to the Invocation (req/res) and control
is passed back to e.g. the Axis2 interceptor stack, in order that it may
complete the req/res.
If the Session is not found by the time we hit the ClusterContextualiser
we might also choose to relocate the Invocation elsewhere (Not supported
yet for Axis2) and pass control back to the Axis2 interceptor stack.

>    (I know the Rendezvous is used to exchange an object btw threads in a
> thread safe way. I assume it' used here to exchnage control btw the
> contextualier stack and the invocation thread?)

This stuff is a horrible hack necessary, at the moment, because you do
not actually pass me flow-control (i.e. a reference to the next
interceptor in the Axis2 stack that I can call when i finish my work).
So I have to hold up your thread as it enters WADI, descendn the
Contextualiser stack on another pooled thread, release your thread, to
render the req/res, pause it, whilst mine ascends the Contextualiser
stack on the other side, then allow your to continue out of WADI.

> 5. What does the wadi.around(Invocation inv) method do ?

This would be the method that I used if I had flow-control.

>
> 6. Why does the wadi session implement HttpSession? is it bcos there is a
> dependency to this partcular interface inside the core ? I assume you  
> are
> still in the middle of refactoring to make wadi more generic than web
> clustering?

This is one of the reasons. The other is that your session is so like
the web session that the quickest to make it fly was just to reuse all
this code. Ultimately, we will factor out the Axis2 stuff and give you
your own session which does not pull in the servlet spec.

>
> 7. I understand that everything in wadi is wired through spring right? I
> need to find the best place to store the wad-axis2.xml.

Yes

Now, I have a request for you :-)

Gianny knows a bit about Axis2 and he assures me that you have some form
of Interceptor stack, down which your req/res progresses. He also thinks
that this stack is chained, with each interceptor holding a reference to
the next in line and deciding whether or not to call it after it has
done its own work.

It would save us a lot of effort if if we could find a way to insert a
WADI Interceptor at the very front of this stack and pass control to
WADI at this point. I can then put the reference to the next interceptor
into my Axis2Invocation and pass that straight off through WADI's
interceptor stack, without having to do all the messy Thread
coordination. At the bottom of the stack, when the Session has been
found, WADI will pass control back to the Axis2 stack and processing
will continue as usual. When processing is finished, and the response
travels back up the stack the other way, WADI gets a chance to release
locks and other resources acquired on behalf of the Invocation as it
leaves the container.... This is how WADI is intended to work and will
yield a much cleaner, faster and simpler integration....

This is exactly the sort of thing for which an Interceptor stack is
designed, so there must be a way to achieve this simply.

What do you think ? If you can get this going, and pass the request,
response, and next Interceptor into your API somewhere, then we are
really in business.

cheers,


Jules

>
> Thanks in advance,
>
> Rajith
>
> On 4/28/06, Jules Gosnell <jules@...> wrote:
>
>>
>> Rajith,
>>
>> Things are a little trickier than I expected - its a long time since I
>> wrote this code and I had forgotten how it worked :-( ...
>>
>> The fallout is that, in order for the solution that I am trying (I think
>> this solution will be shortterm as it involves some hairy thread
>> coordination), I need you to call SessionManager.activateSession() even
>> when you do not have a session - i.e. as an invocation with no session
>> enters the container - unless you can prove to yourself that it will not
>> try to create one (in which case you will never have to call passivate
>> on the way out) .... So, in this case, I need you to call
>> 'SessionManager.activateSession(null)'. Is this OK - can you get [a]
>> fresh jar[s] to me that do[es] this ?
>>
>> Cheers,
>>
>> Jules
>>
>>
>> Rajith Attapattu wrote:
>>
>> >Awesome, to be honest the discussions we had inside Geronimo,
>> offline and
>> >in WADI really helped me a lot to shape the current Session Mgt API. So
>> >thanks jules for the support.
>> >
>> >Btw, I am going to look at the code you have done and slowly pick up
>> the
>> >stuff.
>> >
>> >Regards,
>> >
>> >Rajith
>> >
>> >On 4/27/06, Jules Gosnell <jules@...> wrote:
>> >
>> >
>> >>Rajith Attapattu wrote:
>> >>
>> >>
>> >>
>> >>>Yep, thats to get rid of the session.
>> >>>
>> >>>Jules let me actually send a description of the methods so that if
>> there
>> >>>
>> >>>
>> >>is
>> >>
>> >>
>> >>>any dobut it will clear it up.
>> >>>Sorry if the names confuse you.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>I think that I have them all figured out now - we just use slightly
>> >>different terminology :-) - so don't worry - we can review naming if
>> >>necessary once it is all hooked up.
>> >>
>> >>I have been doing some refactoring in WADI to better accomodate the
>> >>Axis2 stuff - I hope to get back to it shortly.
>> >>
>> >>Jules
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>> --
>> "Open Source is a self-assembling organism. You dangle a piece of
>> string into a super-saturated solution and a whole operating-system
>> crystallises out around it."
>>
>> /**********************************
>> * Jules Gosnell
>> * Partner
>> * Core Developers Network (Europe)
>> *
>> *    www.coredevelopers.net
>> *
>> * Open Source Training & Support.
>> **********************************/
>>
>>
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Gianny Damour-2]

Jules Gosnell wrote

<snip>

> Now, I have a request for you :-)
>
> Gianny knows a bit about Axis2 and he assures me that you have some
> form of Interceptor stack, down which your req/res progresses. He also
> thinks that this stack is chained, with each interceptor holding a
> reference to the next in line and deciding whether or not to call it
> after it has done its own work.

Let me comment further on that. In the Axis engine, when a
MessageContext is received from a transport, a pipeline of Handler is
built and each one of them is then invoked with the MessageContext. From
this MessageContext it is possible to retrieve the Handler pipeline. A
Handler being invoked does also know its index in this pipeline.

As I am not sure of the Axis2 requirements, I may be completly wrong
about the following.... I think that Axis2 could provide a clustering
module, which could be engaged on request for an Axis archive. This
module defines a Handler which integrates with WADI.

Rajith, does that make sense?

Thanks,
Gianny

>
> It would save us a lot of effort if if we could find a way to insert a
> WADI Interceptor at the very front of this stack and pass control to
> WADI at this point. I can then put the reference to the next
> interceptor into my Axis2Invocation and pass that straight off through
> WADI's interceptor stack, without having to do all the messy Thread
> coordination. At the bottom of the stack, when the Session has been
> found, WADI will pass control back to the Axis2 stack and processing
> will continue as usual. When processing is finished, and the response
> travels back up the stack the other way, WADI gets a chance to release
> locks and other resources acquired on behalf of the Invocation as it
> leaves the container.... This is how WADI is intended to work and will
> yield a much cleaner, faster and simpler integration....
>
> This is exactly the sort of thing for which an Interceptor stack is
> designed, so there must be a way to achieve this simply.
>
> What do you think ? If you can get this going, and pass the request,
> response, and next Interceptor into your API somewhere, then we are
> really in business.
>
> cheers,
>
>
> Jules
>
>>
>> Thanks in advance,
>>
>> Rajith
>>
>> On 4/28/06, Jules Gosnell <jules@...> wrote:
>>
>>>
>>> Rajith,
>>>
>>> Things are a little trickier than I expected - its a long time since I
>>> wrote this code and I had forgotten how it worked :-( ...
>>>
>>> The fallout is that, in order for the solution that I am trying (I
>>> think
>>> this solution will be shortterm as it involves some hairy thread
>>> coordination), I need you to call SessionManager.activateSession() even
>>> when you do not have a session - i.e. as an invocation with no session
>>> enters the container - unless you can prove to yourself that it will
>>> not
>>> try to create one (in which case you will never have to call passivate
>>> on the way out) .... So, in this case, I need you to call
>>> 'SessionManager.activateSession(null)'. Is this OK - can you get [a]
>>> fresh jar[s] to me that do[es] this ?
>>>
>>> Cheers,
>>>
>>> Jules
>>>
>>>
>>> Rajith Attapattu wrote:
>>>
>>> >Awesome, to be honest the discussions we had inside Geronimo,
>>> offline and
>>> >in WADI really helped me a lot to shape the current Session Mgt
>>> API. So
>>> >thanks jules for the support.
>>> >
>>> >Btw, I am going to look at the code you have done and slowly pick
>>> up the
>>> >stuff.
>>> >
>>> >Regards,
>>> >
>>> >Rajith
>>> >
>>> >On 4/27/06, Jules Gosnell <jules@...> wrote:
>>> >
>>> >
>>> >>Rajith Attapattu wrote:
>>> >>
>>> >>
>>> >>
>>> >>>Yep, thats to get rid of the session.
>>> >>>
>>> >>>Jules let me actually send a description of the methods so that if
>>> there
>>> >>>
>>> >>>
>>> >>is
>>> >>
>>> >>
>>> >>>any dobut it will clear it up.
>>> >>>Sorry if the names confuse you.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>I think that I have them all figured out now - we just use slightly
>>> >>different terminology :-) - so don't worry - we can review naming if
>>> >>necessary once it is all hooked up.
>>> >>
>>> >>I have been doing some refactoring in WADI to better accomodate the
>>> >>Axis2 stuff - I hope to get back to it shortly.
>>> >>
>>> >>Jules
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>>
>>>
>>> --
>>> "Open Source is a self-assembling organism. You dangle a piece of
>>> string into a super-saturated solution and a whole operating-system
>>> crystallises out around it."
>>>
>>> /**********************************
>>> * Jules Gosnell
>>> * Partner
>>> * Core Developers Network (Europe)
>>> *
>>> *    www.coredevelopers.net
>>> *
>>> * Open Source Training & Support.
>>> **********************************/
>>>
>>>
>>
>
>

[Jules Gosnell-4]

Gianny Damour wrote:

> Jules Gosnell wrote
>
> <snip>
>
>> Now, I have a request for you :-)
>>
>> Gianny knows a bit about Axis2 and he assures me that you have some
>> form of Interceptor stack, down which your req/res progresses. He
>> also thinks that this stack is chained, with each interceptor holding
>> a reference to the next in line and deciding whether or not to call
>> it after it has done its own work.
>
>
> Let me comment further on that. In the Axis engine, when a
> MessageContext is received from a transport, a pipeline of Handler is
> built and each one of them is then invoked with the MessageContext.
> From this MessageContext it is possible to retrieve the Handler
> pipeline. A Handler being invoked does also know its index in this
> pipeline.
>
> As I am not sure of the Axis2 requirements, I may be completly wrong
> about the following.... I think that Axis2 could provide a clustering
> module, which could be engaged on request for an Axis archive. This
> module defines a Handler which integrates with WADI.

thanks for the clarification, Gianny - much appreciated.

>
> Rajith, does that make sense?


Rajith - I realise that this may not be exactly how you envisaged your
Session management API looking :-) - but there are very good reasons for
WADI working in this way. I suggest that we get it all working, then I
can explain exactly why we do it this way and we can work together on
how best to reconcile this stuff with your API.

How does that sound ?

Jules

>
> Thanks,
> Gianny
>
>>
>> It would save us a lot of effort if if we could find a way to insert
>> a WADI Interceptor at the very front of this stack and pass control
>> to WADI at this point. I can then put the reference to the next
>> interceptor into my Axis2Invocation and pass that straight off
>> through WADI's interceptor stack, without having to do all the messy
>> Thread coordination. At the bottom of the stack, when the Session has
>> been found, WADI will pass control back to the Axis2 stack and
>> processing will continue as usual. When processing is finished, and
>> the response travels back up the stack the other way, WADI gets a
>> chance to release locks and other resources acquired on behalf of the
>> Invocation as it leaves the container.... This is how WADI is
>> intended to work and will yield a much cleaner, faster and simpler
>> integration....
>>
>> This is exactly the sort of thing for which an Interceptor stack is
>> designed, so there must be a way to achieve this simply.
>>
>> What do you think ? If you can get this going, and pass the request,
>> response, and next Interceptor into your API somewhere, then we are
>> really in business.
>>
>> cheers,
>>
>>
>> Jules
>>
>>>
>>> Thanks in advance,
>>>
>>> Rajith
>>>
>>> On 4/28/06, Jules Gosnell <jules@...> wrote:
>>>
>>>>
>>>> Rajith,
>>>>
>>>> Things are a little trickier than I expected - its a long time since I
>>>> wrote this code and I had forgotten how it worked :-( ...
>>>>
>>>> The fallout is that, in order for the solution that I am trying (I
>>>> think
>>>> this solution will be shortterm as it involves some hairy thread
>>>> coordination), I need you to call SessionManager.activateSession()
>>>> even
>>>> when you do not have a session - i.e. as an invocation with no session
>>>> enters the container - unless you can prove to yourself that it
>>>> will not
>>>> try to create one (in which case you will never have to call passivate
>>>> on the way out) .... So, in this case, I need you to call
>>>> 'SessionManager.activateSession(null)'. Is this OK - can you get [a]
>>>> fresh jar[s] to me that do[es] this ?
>>>>
>>>> Cheers,
>>>>
>>>> Jules
>>>>
>>>>
>>>> Rajith Attapattu wrote:
>>>>
>>>> >Awesome, to be honest the discussions we had inside Geronimo,
>>>> offline and
>>>> >in WADI really helped me a lot to shape the current Session Mgt
>>>> API. So
>>>> >thanks jules for the support.
>>>> >
>>>> >Btw, I am going to look at the code you have done and slowly pick
>>>> up the
>>>> >stuff.
>>>> >
>>>> >Regards,
>>>> >
>>>> >Rajith
>>>> >
>>>> >On 4/27/06, Jules Gosnell <jules@...> wrote:
>>>> >
>>>> >
>>>> >>Rajith Attapattu wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >>>Yep, thats to get rid of the session.
>>>> >>>
>>>> >>>Jules let me actually send a description of the methods so that if
>>>> there
>>>> >>>
>>>> >>>
>>>> >>is
>>>> >>
>>>> >>
>>>> >>>any dobut it will clear it up.
>>>> >>>Sorry if the names confuse you.
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>I think that I have them all figured out now - we just use slightly
>>>> >>different terminology :-) - so don't worry - we can review naming if
>>>> >>necessary once it is all hooked up.
>>>> >>
>>>> >>I have been doing some refactoring in WADI to better accomodate the
>>>> >>Axis2 stuff - I hope to get back to it shortly.
>>>> >>
>>>> >>Jules
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>> --
>>>> "Open Source is a self-assembling organism. You dangle a piece of
>>>> string into a super-saturated solution and a whole operating-system
>>>> crystallises out around it."
>>>>
>>>> /**********************************
>>>> * Jules Gosnell
>>>> * Partner
>>>> * Core Developers Network (Europe)
>>>> *
>>>> *    www.coredevelopers.net
>>>> *
>>>> * Open Source Training & Support.
>>>> **********************************/
>>>>
>>>>
>>>
>>
>>
>
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Rajith Attapattu-2]

Jules and Gianny,

Gianny is right, the message ctx passes through the pipeline of handlers and
the session mgt is implemented as a handler that intercepts the request at
the beginning and at the end. You can get the current handler index of you
want to and thereby figuring out who is next.

However the beauty of a pipeline is not knowing (or not caring) who is
before or after you ;-)

Since session mgt is a basic requirment it wasn't defined as a module that
could be engaged dynamically (but there is discussion whether to do this or
not). making it a module (or not) is a simple change as what a module does
is also to introduce handlers to the chain in some predetermined location.

I have no problems inserting a WADI handler, however  I still need to
maintain the unified session API as that was requirement they gave me so
that we can add different approaches to session mgt. So how can I do that
with that (WADI getting direct control) approach
Ex : Http cookie based, WS-A based or WS-Context based.

Actually the SessionHanlder and the EndOfRequestHandler does exactly what
you want.(with the exception of the thread problem which I assume is common
for web and ejb)
(see below for the description)

What if I pause the request thread on my side and then hand you over the
control and wait for a reply from your side? I am more and more convinced
that we need some sort of a bridge btw the 2 architectures to get around
things like this.

(What I am saying is that we should have a WADISessionManager on Axis2 side
that does wadi specific things before handing over control to the
org.codehaus.wadi.AxisManager.

SessionHandler
------------------------
Extracts the session_id from the SOAP headers and call the session managers
create (if no session_id is present) or activate if a session_id is found.

EndOfRequestHandler
---------------------------------
Calls passivate on the session manager and inserts the session_id in the out
out going soap message.


Also don't u have the same problem with the Web and EJB session?
I assume the request comes in it's own thread and then u would still be
using your own thread pool for contextualizer stack navigation?
Did I miss something here?

Regards,

Rajith

On 5/9/06, Jules Gosnell <jules@...> wrote:

>
> Gianny Damour wrote:
>
> > Jules Gosnell wrote
> >
> > <snip>
> >
> >> Now, I have a request for you :-)
> >>
> >> Gianny knows a bit about Axis2 and he assures me that you have some
> >> form of Interceptor stack, down which your req/res progresses. He
> >> also thinks that this stack is chained, with each interceptor holding
> >> a reference to the next in line and deciding whether or not to call
> >> it after it has done its own work.
> >
> >
> > Let me comment further on that. In the Axis engine, when a
> > MessageContext is received from a transport, a pipeline of Handler is
> > built and each one of them is then invoked with the MessageContext.
> > From this MessageContext it is possible to retrieve the Handler
> > pipeline. A Handler being invoked does also know its index in this
> > pipeline.
> >
> > As I am not sure of the Axis2 requirements, I may be completly wrong
> > about the following.... I think that Axis2 could provide a clustering
> > module, which could be engaged on request for an Axis archive. This
> > module defines a Handler which integrates with WADI.
>
> thanks for the clarification, Gianny - much appreciated.
>
> >
> > Rajith, does that make sense?
>
>
> Rajith - I realise that this may not be exactly how you envisaged your
> Session management API looking :-) - but there are very good reasons for
> WADI working in this way. I suggest that we get it all working, then I
> can explain exactly why we do it this way and we can work together on
> how best to reconcile this stuff with your API.
>
> How does that sound ?
>
> Jules
>
> >
> > Thanks,
> > Gianny
> >
> >>
> >> It would save us a lot of effort if if we could find a way to insert
> >> a WADI Interceptor at the very front of this stack and pass control
> >> to WADI at this point. I can then put the reference to the next
> >> interceptor into my Axis2Invocation and pass that straight off
> >> through WADI's interceptor stack, without having to do all the messy
> >> Thread coordination. At the bottom of the stack, when the Session has
> >> been found, WADI will pass control back to the Axis2 stack and
> >> processing will continue as usual. When processing is finished, and
> >> the response travels back up the stack the other way, WADI gets a
> >> chance to release locks and other resources acquired on behalf of the
> >> Invocation as it leaves the container.... This is how WADI is
> >> intended to work and will yield a much cleaner, faster and simpler
> >> integration....
> >>
> >> This is exactly the sort of thing for which an Interceptor stack is
> >> designed, so there must be a way to achieve this simply.
> >>
> >> What do you think ? If you can get this going, and pass the request,
> >> response, and next Interceptor into your API somewhere, then we are
> >> really in business.
> >>
> >> cheers,
> >>
> >>
> >> Jules
> >>
> >>>
> >>> Thanks in advance,
> >>>
> >>> Rajith
> >>>
> >>> On 4/28/06, Jules Gosnell <jules@...> wrote:
> >>>
> >>>>
> >>>> Rajith,
> >>>>
> >>>> Things are a little trickier than I expected - its a long time since
> I
> >>>> wrote this code and I had forgotten how it worked :-( ...
> >>>>
> >>>> The fallout is that, in order for the solution that I am trying (I
> >>>> think
> >>>> this solution will be shortterm as it involves some hairy thread
> >>>> coordination), I need you to call SessionManager.activateSession()
> >>>> even
> >>>> when you do not have a session - i.e. as an invocation with no
> session
> >>>> enters the container - unless you can prove to yourself that it
> >>>> will not
> >>>> try to create one (in which case you will never have to call
> passivate
> >>>> on the way out) .... So, in this case, I need you to call
> >>>> 'SessionManager.activateSession(null)'. Is this OK - can you get [a]
> >>>> fresh jar[s] to me that do[es] this ?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Jules
> >>>>
> >>>>
> >>>> Rajith Attapattu wrote:
> >>>>
> >>>> >Awesome, to be honest the discussions we had inside Geronimo,
> >>>> offline and
> >>>> >in WADI really helped me a lot to shape the current Session Mgt
> >>>> API. So
> >>>> >thanks jules for the support.
> >>>> >
> >>>> >Btw, I am going to look at the code you have done and slowly pick
> >>>> up the
> >>>> >stuff.
> >>>> >
> >>>> >Regards,
> >>>> >
> >>>> >Rajith
> >>>> >
> >>>> >On 4/27/06, Jules Gosnell <jules@...> wrote:
> >>>> >
> >>>> >
> >>>> >>Rajith Attapattu wrote:
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >>>Yep, thats to get rid of the session.
> >>>> >>>
> >>>> >>>Jules let me actually send a description of the methods so that if
> >>>> there
> >>>> >>>
> >>>> >>>
> >>>> >>is
> >>>> >>
> >>>> >>
> >>>> >>>any dobut it will clear it up.
> >>>> >>>Sorry if the names confuse you.
> >>>> >>>
> >>>> >>>
> >>>> >>>
> >>>> >>>
> >>>> >>I think that I have them all figured out now - we just use slightly
> >>>> >>different terminology :-) - so don't worry - we can review naming
> if
> >>>> >>necessary once it is all hooked up.
> >>>> >>
> >>>> >>I have been doing some refactoring in WADI to better accomodate the
> >>>> >>Axis2 stuff - I hope to get back to it shortly.
> >>>> >>
> >>>> >>Jules
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >
> >>>> >
> >>>> >
> >>>>
> >>>>
> >>>> --
> >>>> "Open Source is a self-assembling organism. You dangle a piece of
> >>>> string into a super-saturated solution and a whole operating-system
> >>>> crystallises out around it."
> >>>>
> >>>> /**********************************
> >>>> * Jules Gosnell
> >>>> * Partner
> >>>> * Core Developers Network (Europe)
> >>>> *
> >>>> *    www.coredevelopers.net
> >>>> *
> >>>> * Open Source Training & Support.
> >>>> **********************************/
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> >
>
>
> --
> "Open Source is a self-assembling organism. You dangle a piece of
> string into a super-saturated solution and a whole operating-system
> crystallises out around it."
>
> /**********************************
> * Jules Gosnell
> * Partner
> * Core Developers Network (Europe)
> *
> *    www.coredevelopers.net
> *
> * Open Source Training & Support.
> **********************************/
>
>

[Jules Gosnell-4]

Rajith Attapattu wrote:

> Jules and Gianny,
>
> Gianny is right, the message ctx passes through the pipeline of
> handlers and
> the session mgt is implemented as a handler that intercepts the
> request at
> the beginning and at the end. You can get the current handler index of
> you
> want to and thereby figuring out who is next.
>

good

> However the beauty of a pipeline is not knowing (or not caring) who is
> before or after you ;-)
>
agreed - however, WADI should ideally be as far forward as possible,
because one of the things that it may (ultimately) do, is to 'relocate'
an incoming req/res to the node that owns the relevant session. In this
case, any work done by interceptors in front of it has been wasted.
Furthermore, no interceptor in front of WADI will be able to access the
relevant session, because WADI has not yet had a chance to find it and
attach it to the invocation.

> Since session mgt is a basic requirment it wasn't defined as a module
> that
> could be engaged dynamically (but there is discussion whether to do
> this or
> not). making it a module (or not) is a simple change as what a module
> does
> is also to introduce handlers to the chain in some predetermined
> location.
>
> I have no problems inserting a WADI handler, however  I still need to
> maintain the unified session API as that was requirement they gave me so
> that we can add different approaches to session mgt. So how can I do that
> with that (WADI getting direct control) approach
> Ex : Http cookie based, WS-A based or WS-Context based.

I don't understand this question - can you elucidate ?

If you want to reuse your API with another session manager, then most of
it will look similar - i.e. you create, destroy and fetch sessions
through a common API - the only difference between this and WADI is that
with WADI these operations must only be used on a stack on which a WADI
interceptor has already been called.

Ah - I think I get it... - you are concerned that Axis2 should be in
charge of stuff like actually marking the req/res with the session key,
etc... - that's no problem - you can continue to do all that normally
after calling e.g. createSession() .... If WADI needs any further
fn-ality in this direction - e.g. removing the key when a session is
destroyed, updating its time-to-live when a session is updated, or
changing the value of the key for any reason, we will do it through an
API on the Invocation which will delegate to your req/res... somehow. If
they can do it, we can do it, if they can't, we can't etc.... - is that
clearer ?

>
> Actually the SessionHanlder and the EndOfRequestHandler does exactly what
> you want.(with the exception of the thread problem which I assume is
> common
> for web and ejb)
> (see below for the description)

sounds good.

>
> What if I pause the request thread on my side and then hand you over the
> control and wait for a reply from your side? I am more and more convinced
> that we need some sort of a bridge btw the 2 architectures to get around
> things like this.
>
I don't see why we need to mess with threads - I should be able to do
everything that I need to do on the request thread - shouldn't I ?

> (What I am saying is that we should have a WADISessionManager on Axis2
> side
> that does wadi specific things before handing over control to the
> org.codehaus.wadi.AxisManager.
>
> SessionHandler
> ------------------------
> Extracts the session_id from the SOAP headers and call the session
> managers
> create (if no session_id is present) or activate if a session_id is
> found.
>
> EndOfRequestHandler
> ---------------------------------
> Calls passivate on the session manager and inserts the session_id in
> the out
> out going soap message.
>

this is a step backwards, to what we have already - I want to take a
step forwards and have you hand me the message context and the reference
to the next handler/interceptor. I can then effectvel reroute the flow
of control through WADI, acquire the session, attach it to the context
(or let you do this), and then pass control back to Axis2 via the next
handler/interceptor ref. When the message has been run and flow is
passing back up the interceptor stack, I can intercept it, release the
session and then pass control back up the stack to the interceptor above
me, so that the response can return to the client.

WADI makes an assumption (always dangerous) that, perhaps is holding us
up here....

We assume that the handler/interceptor stack in our container is a
two-way street - i.e. a single interceptor is wrapped 'around' the
invocation and can execute code on the same stack before and after the
actual invocation e.g.

class Interceptor {
public void intercept(Invocation invocation) {
 try {
   // acquire and lock session into this node
   getNextInterceptor().intercept(invocation);
   } finally {
  // release session so that it may be acquired by other nodes
  }
 }
}

This means that our state can be held on the java stack, during the
invocation and that we can use useful constructs like try{} catch() {}
finally {} for our flow control.

If you try to separate the code wrapped around the invocation into
discrete 'before()' and 'after()' methods, you can no longer use
language flow control constructs and the java stack for state storage,
but have to do all this explicitly - which would be a real drag.

Does the Axis2 handler stack work 'around' the invocation with a single
handler, or do you have separate 'before' and 'after' handlers ? I'm
concerned that you mentioned 2 handlers: SessionHanlder and
EndOfRequestHandler - it seems to me that the EOR handler, should just
be code that is run in the second part of the 'around' body, rather than
another handler - maybe I am getting lost now :-)

>
> Also don't u have the same problem with the Web and EJB session?
> I assume the request comes in it's own thread and then u would still be
> using your own thread pool for contextualizer stack navigation?
> Did I miss something here?

I can only answer for web - no problem here - we insert WADI into a
FilterChain - this is effectively an interceptor stack for HttpReq/Res
processing. You have a stack of filters with a servlet at the bottom.
The servlet can just be thought of as a terminal filter, which returns
rather than passing flow-control onto another...

Gianny did the OpenEJB integration - I am pretty sure that they have
some form of Invocation and Interceptor stack - otherwise I would have
had this conversation with him already :-)

Does that help ?

Jules

>
> Regards,
>
> Rajith
>
> On 5/9/06, Jules Gosnell <jules@...> wrote:
>
>>
>> Gianny Damour wrote:
>>
>> > Jules Gosnell wrote
>> >
>> > <snip>
>> >
>> >> Now, I have a request for you :-)
>> >>
>> >> Gianny knows a bit about Axis2 and he assures me that you have some
>> >> form of Interceptor stack, down which your req/res progresses. He
>> >> also thinks that this stack is chained, with each interceptor holding
>> >> a reference to the next in line and deciding whether or not to call
>> >> it after it has done its own work.
>> >
>> >
>> > Let me comment further on that. In the Axis engine, when a
>> > MessageContext is received from a transport, a pipeline of Handler is
>> > built and each one of them is then invoked with the MessageContext.
>> > From this MessageContext it is possible to retrieve the Handler
>> > pipeline. A Handler being invoked does also know its index in this
>> > pipeline.
>> >
>> > As I am not sure of the Axis2 requirements, I may be completly wrong
>> > about the following.... I think that Axis2 could provide a clustering
>> > module, which could be engaged on request for an Axis archive. This
>> > module defines a Handler which integrates with WADI.
>>
>> thanks for the clarification, Gianny - much appreciated.
>>
>> >
>> > Rajith, does that make sense?
>>
>>
>> Rajith - I realise that this may not be exactly how you envisaged your
>> Session management API looking :-) - but there are very good reasons for
>> WADI working in this way. I suggest that we get it all working, then I
>> can explain exactly why we do it this way and we can work together on
>> how best to reconcile this stuff with your API.
>>
>> How does that sound ?
>>
>> Jules
>>
>> >
>> > Thanks,
>> > Gianny
>> >
>> >>
>> >> It would save us a lot of effort if if we could find a way to insert
>> >> a WADI Interceptor at the very front of this stack and pass control
>> >> to WADI at this point. I can then put the reference to the next
>> >> interceptor into my Axis2Invocation and pass that straight off
>> >> through WADI's interceptor stack, without having to do all the messy
>> >> Thread coordination. At the bottom of the stack, when the Session has
>> >> been found, WADI will pass control back to the Axis2 stack and
>> >> processing will continue as usual. When processing is finished, and
>> >> the response travels back up the stack the other way, WADI gets a
>> >> chance to release locks and other resources acquired on behalf of the
>> >> Invocation as it leaves the container.... This is how WADI is
>> >> intended to work and will yield a much cleaner, faster and simpler
>> >> integration....
>> >>
>> >> This is exactly the sort of thing for which an Interceptor stack is
>> >> designed, so there must be a way to achieve this simply.
>> >>
>> >> What do you think ? If you can get this going, and pass the request,
>> >> response, and next Interceptor into your API somewhere, then we are
>> >> really in business.
>> >>
>> >> cheers,
>> >>
>> >>
>> >> Jules
>> >>
>> >>>
>> >>> Thanks in advance,
>> >>>
>> >>> Rajith
>> >>>
>> >>> On 4/28/06, Jules Gosnell <jules@...> wrote:
>> >>>
>> >>>>
>> >>>> Rajith,
>> >>>>
>> >>>> Things are a little trickier than I expected - its a long time
>> since
>> I
>> >>>> wrote this code and I had forgotten how it worked :-( ...
>> >>>>
>> >>>> The fallout is that, in order for the solution that I am trying (I
>> >>>> think
>> >>>> this solution will be shortterm as it involves some hairy thread
>> >>>> coordination), I need you to call SessionManager.activateSession()
>> >>>> even
>> >>>> when you do not have a session - i.e. as an invocation with no
>> session
>> >>>> enters the container - unless you can prove to yourself that it
>> >>>> will not
>> >>>> try to create one (in which case you will never have to call
>> passivate
>> >>>> on the way out) .... So, in this case, I need you to call
>> >>>> 'SessionManager.activateSession(null)'. Is this OK - can you get
>> [a]
>> >>>> fresh jar[s] to me that do[es] this ?
>> >>>>
>> >>>> Cheers,
>> >>>>
>> >>>> Jules
>> >>>>
>> >>>>
>> >>>> Rajith Attapattu wrote:
>> >>>>
>> >>>> >Awesome, to be honest the discussions we had inside Geronimo,
>> >>>> offline and
>> >>>> >in WADI really helped me a lot to shape the current Session Mgt
>> >>>> API. So
>> >>>> >thanks jules for the support.
>> >>>> >
>> >>>> >Btw, I am going to look at the code you have done and slowly pick
>> >>>> up the
>> >>>> >stuff.
>> >>>> >
>> >>>> >Regards,
>> >>>> >
>> >>>> >Rajith
>> >>>> >
>> >>>> >On 4/27/06, Jules Gosnell <jules@...> wrote:
>> >>>> >
>> >>>> >
>> >>>> >>Rajith Attapattu wrote:
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>>Yep, thats to get rid of the session.
>> >>>> >>>
>> >>>> >>>Jules let me actually send a description of the methods so
>> that if
>> >>>> there
>> >>>> >>>
>> >>>> >>>
>> >>>> >>is
>> >>>> >>
>> >>>> >>
>> >>>> >>>any dobut it will clear it up.
>> >>>> >>>Sorry if the names confuse you.
>> >>>> >>>
>> >>>> >>>
>> >>>> >>>
>> >>>> >>>
>> >>>> >>I think that I have them all figured out now - we just use
>> slightly
>> >>>> >>different terminology :-) - so don't worry - we can review naming
>> if
>> >>>> >>necessary once it is all hooked up.
>> >>>> >>
>> >>>> >>I have been doing some refactoring in WADI to better
>> accomodate the
>> >>>> >>Axis2 stuff - I hope to get back to it shortly.
>> >>>> >>
>> >>>> >>Jules
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>>
>> >>>>
>> >>>> --
>> >>>> "Open Source is a self-assembling organism. You dangle a piece of
>> >>>> string into a super-saturated solution and a whole operating-system
>> >>>> crystallises out around it."
>> >>>>
>> >>>> /**********************************
>> >>>> * Jules Gosnell
>> >>>> * Partner
>> >>>> * Core Developers Network (Europe)
>> >>>> *
>> >>>> *    www.coredevelopers.net
>> >>>> *
>> >>>> * Open Source Training & Support.
>> >>>> **********************************/
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>> --
>> "Open Source is a self-assembling organism. You dangle a piece of
>> string into a super-saturated solution and a whole operating-system
>> crystallises out around it."
>>
>> /**********************************
>> * Jules Gosnell
>> * Partner
>> * Core Developers Network (Europe)
>> *
>> *    www.coredevelopers.net
>> *
>> * Open Source Training & Support.
>> **********************************/
>>
>>
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Jules Gosnell-4]

Jules Gosnell wrote:

> Rajith Attapattu wrote:
>
>> Jules and Gianny,
>>
>> Gianny is right, the message ctx passes through the pipeline of
>> handlers and
>> the session mgt is implemented as a handler that intercepts the
>> request at
>> the beginning and at the end. You can get the current handler index
>> of you
>> want to and thereby figuring out who is next.
>>
> good
>
>> However the beauty of a pipeline is not knowing (or not caring) who is
>> before or after you ;-)
>>
> agreed - however, WADI should ideally be as far forward as possible,
> because one of the things that it may (ultimately) do, is to
> 'relocate' an incoming req/res to the node that owns the relevant
> session. In this case, any work done by interceptors in front of it
> has been wasted. Furthermore, no interceptor in front of WADI will be
> able to access the relevant session, because WADI has not yet had a
> chance to find it and attach it to the invocation.
>
>> Since session mgt is a basic requirment it wasn't defined as a module
>> that
>> could be engaged dynamically (but there is discussion whether to do
>> this or
>> not). making it a module (or not) is a simple change as what a module
>> does
>> is also to introduce handlers to the chain in some predetermined
>> location.
>>
>> I have no problems inserting a WADI handler, however  I still need to
>> maintain the unified session API as that was requirement they gave me so
>> that we can add different approaches to session mgt. So how can I do
>> that
>> with that (WADI getting direct control) approach
>> Ex : Http cookie based, WS-A based or WS-Context based.
>
>
> I don't understand this question - can you elucidate ?
>
> If you want to reuse your API with another session manager, then most
> of it will look similar - i.e. you create, destroy and fetch sessions
> through a common API - the only difference between this and WADI is
> that with WADI these operations must only be used on a stack on which
> a WADI interceptor has already been called.
>
> Ah - I think I get it... - you are concerned that Axis2 should be in
> charge of stuff like actually marking the req/res with the session
> key, etc... - that's no problem - you can continue to do all that
> normally after calling e.g. createSession() .... If WADI needs any
> further fn-ality in this direction - e.g. removing the key when a
> session is destroyed, updating its time-to-live when a session is
> updated, or changing the value of the key for any reason, we will do
> it through an API on the Invocation which will delegate to your
> req/res... somehow. If they can do it, we can do it, if they can't, we
> can't etc.... - is that clearer ?
>
>>
>> Actually the SessionHanlder and the EndOfRequestHandler does exactly
>> what
>> you want.(with the exception of the thread problem which I assume is
>> common
>> for web and ejb)
>> (see below for the description)
>
>
> sounds good.
>
>>
>> What if I pause the request thread on my side and then hand you over the
>> control and wait for a reply from your side? I am more and more
>> convinced
>> that we need some sort of a bridge btw the 2 architectures to get around
>> things like this.
>>
> I don't see why we need to mess with threads - I should be able to do
> everything that I need to do on the request thread - shouldn't I ?
>
>> (What I am saying is that we should have a WADISessionManager on
>> Axis2 side
>> that does wadi specific things before handing over control to the
>> org.codehaus.wadi.AxisManager.
>>
>> SessionHandler
>> ------------------------
>> Extracts the session_id from the SOAP headers and call the session
>> managers
>> create (if no session_id is present) or activate if a session_id is
>> found.
>>
>> EndOfRequestHandler
>> ---------------------------------
>> Calls passivate on the session manager and inserts the session_id in
>> the out
>> out going soap message.
>>
> this is a step backwards, to what we have already - I want to take a
> step forwards and have you hand me the message context and the
> reference to the next handler/interceptor. I can then effectvel
> reroute the flow of control through WADI, acquire the session, attach
> it to the context (or let you do this), and then pass control back to
> Axis2 via the next handler/interceptor ref. When the message has been
> run and flow is passing back up the interceptor stack, I can intercept
> it, release the session and then pass control back up the stack to the
> interceptor above me, so that the response can return to the client.
>
> WADI makes an assumption (always dangerous) that, perhaps is holding
> us up here....
>
> We assume that the handler/interceptor stack in our container is a
> two-way street - i.e. a single interceptor is wrapped 'around' the
> invocation and can execute code on the same stack before and after the
> actual invocation e.g.
>
> class Interceptor {
> public void intercept(Invocation invocation) {
> try {
>   // acquire and lock session into this node
>   getNextInterceptor().intercept(invocation);
>   } finally {
>  // release session so that it may be acquired by other nodes
>  }
> }
> }
>
> This means that our state can be held on the java stack, during the
> invocation and that we can use useful constructs like try{} catch() {}
> finally {} for our flow control.
>
> If you try to separate the code wrapped around the invocation into
> discrete 'before()' and 'after()' methods, you can no longer use
> language flow control constructs and the java stack for state storage,
> but have to do all this explicitly - which would be a real drag.
>
> Does the Axis2 handler stack work 'around' the invocation with a
> single handler, or do you have separate 'before' and 'after' handlers
> ? I'm concerned that you mentioned 2 handlers: SessionHanlder and
> EndOfRequestHandler - it seems to me that the EOR handler, should just
> be code that is run in the second part of the 'around' body, rather
> than another handler - maybe I am getting lost now :-)
>
>>
>> Also don't u have the same problem with the Web and EJB session?
>> I assume the request comes in it's own thread and then u would still be
>> using your own thread pool for contextualizer stack navigation?
>> Did I miss something here?
>
>
> I can only answer for web - no problem here - we insert WADI into a
> FilterChain - this is effectively an interceptor stack for HttpReq/Res
> processing. You have a stack of filters with a servlet at the bottom.
> The servlet can just be thought of as a terminal filter, which returns
> rather than passing flow-control onto another...
>
> Gianny did the OpenEJB integration - I am pretty sure that they have
> some form of Invocation and Interceptor stack - otherwise I would have
> had this conversation with him already :-)
>
> Does that help ?

one further point that may help....

think of an interceptor as an aspect - they are pretty much the same thing.

all I am saying is that WADI is implemented much more simply as an
'around' aspect than separate 'before' and 'after' aspects - for the
reasons given above.

that sums it up nicely :-) - should've thought of that metaphor before
and saved myself a lot of typing !

Jules

>
> Jules
>
>>
>> Regards,
>>
>> Rajith
>>
>> On 5/9/06, Jules Gosnell <jules@...> wrote:
>>
>>>
>>> Gianny Damour wrote:
>>>
>>> > Jules Gosnell wrote
>>> >
>>> > <snip>
>>> >
>>> >> Now, I have a request for you :-)
>>> >>
>>> >> Gianny knows a bit about Axis2 and he assures me that you have some
>>> >> form of Interceptor stack, down which your req/res progresses. He
>>> >> also thinks that this stack is chained, with each interceptor
>>> holding
>>> >> a reference to the next in line and deciding whether or not to call
>>> >> it after it has done its own work.
>>> >
>>> >
>>> > Let me comment further on that. In the Axis engine, when a
>>> > MessageContext is received from a transport, a pipeline of Handler is
>>> > built and each one of them is then invoked with the MessageContext.
>>> > From this MessageContext it is possible to retrieve the Handler
>>> > pipeline. A Handler being invoked does also know its index in this
>>> > pipeline.
>>> >
>>> > As I am not sure of the Axis2 requirements, I may be completly wrong
>>> > about the following.... I think that Axis2 could provide a clustering
>>> > module, which could be engaged on request for an Axis archive. This
>>> > module defines a Handler which integrates with WADI.
>>>
>>> thanks for the clarification, Gianny - much appreciated.
>>>
>>> >
>>> > Rajith, does that make sense?
>>>
>>>
>>> Rajith - I realise that this may not be exactly how you envisaged your
>>> Session management API looking :-) - but there are very good reasons
>>> for
>>> WADI working in this way. I suggest that we get it all working, then I
>>> can explain exactly why we do it this way and we can work together on
>>> how best to reconcile this stuff with your API.
>>>
>>> How does that sound ?
>>>
>>> Jules
>>>
>>> >
>>> > Thanks,
>>> > Gianny
>>> >
>>> >>
>>> >> It would save us a lot of effort if if we could find a way to insert
>>> >> a WADI Interceptor at the very front of this stack and pass control
>>> >> to WADI at this point. I can then put the reference to the next
>>> >> interceptor into my Axis2Invocation and pass that straight off
>>> >> through WADI's interceptor stack, without having to do all the messy
>>> >> Thread coordination. At the bottom of the stack, when the Session
>>> has
>>> >> been found, WADI will pass control back to the Axis2 stack and
>>> >> processing will continue as usual. When processing is finished, and
>>> >> the response travels back up the stack the other way, WADI gets a
>>> >> chance to release locks and other resources acquired on behalf of
>>> the
>>> >> Invocation as it leaves the container.... This is how WADI is
>>> >> intended to work and will yield a much cleaner, faster and simpler
>>> >> integration....
>>> >>
>>> >> This is exactly the sort of thing for which an Interceptor stack is
>>> >> designed, so there must be a way to achieve this simply.
>>> >>
>>> >> What do you think ? If you can get this going, and pass the request,
>>> >> response, and next Interceptor into your API somewhere, then we are
>>> >> really in business.
>>> >>
>>> >> cheers,
>>> >>
>>> >>
>>> >> Jules
>>> >>
>>> >>>
>>> >>> Thanks in advance,
>>> >>>
>>> >>> Rajith
>>> >>>
>>> >>> On 4/28/06, Jules Gosnell <jules@...> wrote:
>>> >>>
>>> >>>>
>>> >>>> Rajith,
>>> >>>>
>>> >>>> Things are a little trickier than I expected - its a long time
>>> since
>>> I
>>> >>>> wrote this code and I had forgotten how it worked :-( ...
>>> >>>>
>>> >>>> The fallout is that, in order for the solution that I am trying (I
>>> >>>> think
>>> >>>> this solution will be shortterm as it involves some hairy thread
>>> >>>> coordination), I need you to call SessionManager.activateSession()
>>> >>>> even
>>> >>>> when you do not have a session - i.e. as an invocation with no
>>> session
>>> >>>> enters the container - unless you can prove to yourself that it
>>> >>>> will not
>>> >>>> try to create one (in which case you will never have to call
>>> passivate
>>> >>>> on the way out) .... So, in this case, I need you to call
>>> >>>> 'SessionManager.activateSession(null)'. Is this OK - can you
>>> get [a]
>>> >>>> fresh jar[s] to me that do[es] this ?
>>> >>>>
>>> >>>> Cheers,
>>> >>>>
>>> >>>> Jules
>>> >>>>
>>> >>>>
>>> >>>> Rajith Attapattu wrote:
>>> >>>>
>>> >>>> >Awesome, to be honest the discussions we had inside Geronimo,
>>> >>>> offline and
>>> >>>> >in WADI really helped me a lot to shape the current Session Mgt
>>> >>>> API. So
>>> >>>> >thanks jules for the support.
>>> >>>> >
>>> >>>> >Btw, I am going to look at the code you have done and slowly pick
>>> >>>> up the
>>> >>>> >stuff.
>>> >>>> >
>>> >>>> >Regards,
>>> >>>> >
>>> >>>> >Rajith
>>> >>>> >
>>> >>>> >On 4/27/06, Jules Gosnell <jules@...> wrote:
>>> >>>> >
>>> >>>> >
>>> >>>> >>Rajith Attapattu wrote:
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>>Yep, thats to get rid of the session.
>>> >>>> >>>
>>> >>>> >>>Jules let me actually send a description of the methods so
>>> that if
>>> >>>> there
>>> >>>> >>>
>>> >>>> >>>
>>> >>>> >>is
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>>any dobut it will clear it up.
>>> >>>> >>>Sorry if the names confuse you.
>>> >>>> >>>
>>> >>>> >>>
>>> >>>> >>>
>>> >>>> >>>
>>> >>>> >>I think that I have them all figured out now - we just use
>>> slightly
>>> >>>> >>different terminology :-) - so don't worry - we can review
>>> naming
>>> if
>>> >>>> >>necessary once it is all hooked up.
>>> >>>> >>
>>> >>>> >>I have been doing some refactoring in WADI to better
>>> accomodate the
>>> >>>> >>Axis2 stuff - I hope to get back to it shortly.
>>> >>>> >>
>>> >>>> >>Jules
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >
>>> >>>> >
>>> >>>> >
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> "Open Source is a self-assembling organism. You dangle a piece of
>>> >>>> string into a super-saturated solution and a whole
>>> operating-system
>>> >>>> crystallises out around it."
>>> >>>>
>>> >>>> /**********************************
>>> >>>> * Jules Gosnell
>>> >>>> * Partner
>>> >>>> * Core Developers Network (Europe)
>>> >>>> *
>>> >>>> *    www.coredevelopers.net
>>> >>>> *
>>> >>>> * Open Source Training & Support.
>>> >>>> **********************************/
>>> >>>>
>>> >>>>
>>> >>>
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>> --
>>> "Open Source is a self-assembling organism. You dangle a piece of
>>> string into a super-saturated solution and a whole operating-system
>>> crystallises out around it."
>>>
>>> /**********************************
>>> * Jules Gosnell
>>> * Partner
>>> * Core Developers Network (Europe)
>>> *
>>> *    www.coredevelopers.net
>>> *
>>> * Open Source Training & Support.
>>> **********************************/
>>>
>>>
>>
>
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/