You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Deepal Jayasinghe <de...@opensource.lk> on 2005/04/07 05:00:35 UTC
[Axis2] Purpose Deployment changes
Hi all;
At the axis2 face to face we did number of changes to axis2 architecture, had to get rid of EngineRegistry and introduce new set of contexts ( www.apache.org/~deepal/axis2f2f/axiscontext.jpg ) considering all those I will have to do some changes to the deployment module too. This mail describes purpose changes to that, so please read that carefully and feels free to give your comments and any suggestions.
Pre-dispatch phase:
This is a system inbuilt phase and which is not going to specify in the server.xml as available phase , and all the handlers in this phase run for each service, i.e they act as global handlers. The main rationality behind introducing phase like this is to provide a way to add global handlers by modules if they want.
How deployment work in new architecture (after face to face summit).
a.. Firstly it loads server.xml and using that creates EngineConfiguration (EC) object which is more like EngineRegistry in old architecture.
b.. Then if there are any module to be deploy then load them one by one
a.. Using its module.xml find the module name and then retrieve corresponding "Module Context" form EC. If this is the first time server gets started up, EC gives an empty Module Context else it gives the previously saved (when server shutdown) Module context corresponding to the module.
b.. While processing the module.xml if there are any handlers with the phase property as "Pre-dispatch" phase then those handlers will be added to the Pre-dispatch phase by DeploymentEngine.
c.. Then using the above Module context and EC, it calls the init() method of module implementation class , from that we give more flexibly for module developers to change the order of handlers in Pre-dispatch phase , add new handlers to that chain, if the module need to deploy a new service to do that and etc..
d.. Next add that module to the EC.
e.. Apply the same procedure for all the module.
c.. Next check to see whether there are any module references in srever.xml if so
a.. Gets the corresponding module (s) form EC and gets handlers of those modules.
b.. And add those handlers to the Post-dispatch phase , (those handlers are not going to be ordered at the deployment time)
d.. Next if there are any service have been deployed (drop in to /service directory) then load them one by one
a.. Read it service.xml and using service name retrieve the corresponding "Service Context" and while processing the xml file fill the Service context.
b.. Next check to see whether there are any module references if so gets handlers corresponds to those.
c.. Next using above handler come from
1.. modules (module references)
2.. service specific handlers (defined in service.xml)
3.. all the handlers in the Post-dispatch phase
Creates three kind of flows (or three kind of execution chains) called
1. In-Flow
2. Out-Flow
3. Fault-Flow
(Let's call those flows as serviceChain and those are also called pre compute handler chains)
a.. Next using above service context invokes init method of the service implementation class.
b.. Finally it will be added the created service to the EC.
ยท At the run time for each message arrive, it invokes engage(serviceChain , EngineContext) method of each and every module , then the depending on the WS-police module will decide what to do to the serviceChain , 99% of the time it will do nothing. But if we consider about 1% their module developer can use either Phase rule or any other mechanism to change the handler chain.
Thanks
Deepal
Re: [Axis2] Purpose Deployment changes
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Dammit, missed one. :)
> EngineContext ->
> SessionContext ->
ServiceContext ->
> MEPContext (OperationContext) ->
> MessageContext
--Glen
Re: [Axis2] Purpose Deployment changes
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Venkat Reddy wrote:
> I'm just trying to understand the diagram in axiscontext.jpg. Can you
> please add a little documentation also, as to what the arrows mean,
> and why we have the same boxes at multiple places etc. Is the Context
> Bag the root of all the contexts? I think the hierarchy that we
> discussed was a little different. Global Context -> Engine Context ->
> Service Context -> MEP Context -> Session Context -> Message Context,
> where each "->" stands for "is parent of" or "contains".
IIRC, EngineContext was the top level, and SessionContext was between
that and ServiceContext (since a session might encompass a number of
different service invocations/interactions).
EngineContext ->
SessionContext ->
MEPContext (OperationContext) ->
MessageContext
We also have EngineContext->ModuleContext, separately.
And I think the idea was that the stack will be extensible so that you
could, for instance, insert different kinds of long-running conversation
context in between EngineContext and SessionContext.
--Glen
Re: [Axis2] Purpose Deployment changes
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Glen
> Hi Deepal:
>
>> Its like this , Context Bag is NOT the root of all the context , and
>> which is the one passes around all the handlers in a chain. That is
>> Context bag is a bag which contains all the required contexts to invoke
>> the handlers and finally the service.
>
> Why do you need this "Context Bag" at all? Shouldn't the MessageContext
> just have pointers upwards to the rest of the context stack?
>
[Deepal]
If we keep upwards pointers we are going to have a trouble when we going to
serialize because it try to make cyclic relationship, so my idea is not to
keep upward relationship and only to keep downward pointer ( -:) ) , this
matter arises if we use JAVA serializer.
>> As you have mentioned there are same boxes in different locations ,
>> actually what that implies is
>> 1. direct arrow from Context bag => Keep references to those contexts in
>> Context bag so that if handler want to access any context it can ask
>> those contexts from Context Bag.
>> 2. As you can see there are some arrows from EngineContext and Mep
>> context => that implies those them selves keep references to those
>> contexts. As an example if the MEP is IN-OUT then MEPconnext need to keep
>> references to both IN message context and Out Message context.
>
> OperationContext == MEPContext, right? They are the same thing?
Yup , here MEPContext is the Operationcontext ( OperationContext ==
MEPContext) .
>
> Why does MessageContext have a pointer to "Transport Config"?
>
> Why does EngineContext have a pointer to MessageContext?
>
>> Note that : Only the parent keep its child references and child are not
>> going to keep any references to its parent.
>
> Then how do you do the property scoping we were talking about?? I should
> be able to do:
>
> serviceContext.setProperty("foo", "value")
>
> and then later in a handler (once we've dispatched to the service) do:
>
> messageContext.getProperty("foo")
>
> ...and get "value".
>
> It seems to me like you've got it mostly backwards - the children keep
> pointers to the parents, and only in certain cases do the parents even
> need to keep pointers to the children.
>
>> And one thing if I am not mistaken we do not have context called global
>> context which is equivalent to EngineConetxt so the root of context is
>> EngineContext .
>
> Correct.
>
>> I am also confused the word EngineContext I rather like if we can change
>> it to Global Context
>
> I like EngineContext better myself, since it's clear what it means -
> scoped to an AxisEngine. If you use "Global" you have to ask "how
> Global"? (which in fact we did :))
>
[Deepal]
Glen : I agree with you , but my problem is where are we going to store
global values , are those in the EngineConfiguration
Deepal
> --Glen
>
Re: [Axis2] Purpose Deployment changes
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Deepal:
> Its like this , Context Bag is NOT the root of all the context , and
> which is the one passes around all the handlers in a chain. That is
> Context bag is a bag which contains all the required contexts to invoke
> the handlers and finally the service.
Why do you need this "Context Bag" at all? Shouldn't the MessageContext
just have pointers upwards to the rest of the context stack?
> As you have mentioned there are same boxes in different locations ,
> actually what that implies is
> 1. direct arrow from Context bag => Keep references to those contexts in
> Context bag so that if handler want to access any context it can ask
> those contexts from Context Bag.
> 2. As you can see there are some arrows from EngineContext and Mep
> context => that implies those them selves keep references to those
> contexts. As an example if the MEP is IN-OUT then MEPconnext need to
> keep references to both IN message context and Out Message context.
OperationContext == MEPContext, right? They are the same thing?
Why does MessageContext have a pointer to "Transport Config"?
Why does EngineContext have a pointer to MessageContext?
> Note that : Only the parent keep its child references and child are not
> going to keep any references to its parent.
Then how do you do the property scoping we were talking about?? I
should be able to do:
serviceContext.setProperty("foo", "value")
and then later in a handler (once we've dispatched to the service) do:
messageContext.getProperty("foo")
...and get "value".
It seems to me like you've got it mostly backwards - the children keep
pointers to the parents, and only in certain cases do the parents even
need to keep pointers to the children.
> And one thing if I am not mistaken we do not have context called global
> context which is equivalent to EngineConetxt so the root of context is
> EngineContext .
Correct.
> I am also confused the word EngineContext I rather like if we can change
> it to Global Context
I like EngineContext better myself, since it's clear what it means -
scoped to an AxisEngine. If you use "Global" you have to ask "how
Global"? (which in fact we did :))
--Glen
Re: [Axis2] Purpose Deployment changes
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Ajith Ranabahu wrote:
> Hi Alek,all,
>
> java serialization supports any graphs including cycles
>
>
> Ah, My fault. I should have investigated the java serialization
> mechanism more. It indeed allows circular references.
> So in a sense this solves most of our problems!
actually you need to be very careful as java serialization tends to
serialize more than you need - if you have any references to actual
implementation classes it may try to serialize whole engine state ...
>
> if it is hierarchical why not make it so there is XML
> serialization - it
> would be much more robust and able to survive internal changes in Java
> classes if there is well defined format for XML describing
> *context state.
>
>
> Yep, if we stick to the oneway hierarchy we can have an XML
> serialization as well.
just generating XML is easy but specify what XML should be used to
describe context state is more useful as it could allow for long term
checkpointing of engine state.
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] Purpose Deployment changes
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Alek,all,
java serialization supports any graphs including cycles
Ah, My fault. I should have investigated the java serialization mechanism
more. It indeed allows circular references.
So in a sense this solves most of our problems!
if it is hierarchical why not make it so there is XML serialization - it
> would be much more robust and able to survive internal changes in Java
> classes if there is well defined format for XML describing *context state.
Yep, if we stick to the oneway hierarchy we can have an XML serialization as
well.
--
Ajith Ranabahu
Re: [Axis2] Purpose Deployment changes
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Ajith Ranabahu wrote:
> Hi all,
> Sorry that I did not answer this mail earlier. I guess Ishould mention
> the trail of thoughts that led to the introduction of this "context bag".
>
> The first and foremost requirement is the ability of the set of
> contexts to be serialized. The goal is to use the java serializer and
> hence we can't have cyclic references.
java serialization supports any graphs including cycles
> So the hierarchy is supposed to be one way (no backward references).
> We decided that the best thing to do is to keep the original hierarchy
> and introduce a "context bag" which has the references to all the
> contexts in need.
if it is hierarchical why not make it so there is XML serialization - it
would be much more robust and able to survive internal changes in Java
classes if there is well defined format for XML describing *context state.
alek
> This effectively allows the context tree to be serializable and let
> the handlers access the context bag instead of the message context.
> In my mind, Operation context <> MEPContext!
> Operation context is a axis-server-lifetime object and MEP context
> only lasts until a the MEP is complete. In essence there can be
> multiple MEP contexts inside one particular Operation context. Simply,
> operation context is a container for the MEP contexts.
> This is how I see the context hierarchy.
>
> Engine Context (better called Global :))
> |
> ---- Service Context
> |
> ---- Operation Context
> |
> ------ MEP context
> |
> ----- Message Context
>
> Thoughts ?
>
> Ajith
>
> On Apr 7, 2005 9:38 PM, *Deepal Jayasinghe* <deepal@opensource.lk
> <ma...@opensource.lk>> wrote:
>
> Hi Venkat.
>
> Its like this , Context Bag is NOT the root of all the context ,
> and which
> is the one passes around all the handlers in a chain. That is
> Context bag is
> a bag which contains all the required contexts to invoke the
> handlers and
> finally the service.
>
> As you have mentioned there are same boxes in different locations
> , actually
> what that implies is
> 1. direct arrow from Context bag => Keep references to those
> contexts in
> Context bag so that if handler want to access any context it
> can ask
> those contexts from Context Bag.
> 2. As you can see there are some arrows from EngineContext and Mep
> context
> => that implies those them selves keep references to those
> contexts. As an
> example if the MEP is IN-OUT then MEPconnext need to keep
> references to both
> IN message context and Out Message context.
>
> Note that : Only the parent keep its child references and child
> are not
> going to keep any references to its parent.
>
> And one thing if I am not mistaken we do not have context called
> global
> context which is equivalent to EngineConetxt so the root of context is
> EngineContext .
>
> I am also confused the word EngineContext I rather like if we can
> change it
> to Global Context
>
> Comments .....
>
>
> Deepal
>
>
> > hi Deepal,
> >
> > I'm just trying to understand the diagram in axiscontext.jpg.
> Can you
> > please add a little documentation also, as to what the arrows mean,
> > and why we have the same boxes at multiple places etc. Is the
> Context
> > Bag the root of all the contexts? I think the hierarchy that we
> > discussed was a little different. Global Context -> Engine
> Context ->
> > Service Context -> MEP Context -> Session Context -> Message
> Context,
> > where each "->" stands for "is parent of" or "contains".
> >
> > confused myself :-)
> > Venkat
> >
> > On Apr 7, 2005 9:17 AM, Deepal Jayasinghe <deepal@opensource.lk
> <ma...@opensource.lk>> wrote:
> >> hi
> >>
> >> sorry I forgot to upload the image , now its working pls try again.
> >>
> >>
> >> Deepal
> >>
> >>
> >> ----- Original Message -----
> >> From: "Aleksander Slominski" <aslom@cs.indiana.edu
> <ma...@cs.indiana.edu>>
> >> To: <axis-dev@ws.apache.org <ma...@ws.apache.org>>
> >> Sent: Thursday, April 07, 2005 9:42 AM
> >> Subject: Re: [Axis2] Purpose Deployment changes
> >>
> >> > Deepal Jayasinghe wrote:
> >> >
> >> >> Hi all;
> >> >>
> >> >>
> >> >> At the axis2 face to face we did number of changes to axis2
> >> >> architecture, had to get rid of EngineRegistry and introduce
> new set
> >> >> of contexts (
> www.apache.org/~deepal/axis2f2f/axiscontext.jpg
> <http://www.apache.org/%7Edeepal/axis2f2f/axiscontext.jpg>
> >> >> <http://www.apache.org/%7Edeepal/axis2f2f/axiscontext.jpg> )
> >> >>
> >> > this links does not work.
> >> >
> >> > should it be
> http://people.apache.org/~deepal/axis2f2f/newarchi.JPG
> <http://people.apache.org/%7Edeepal/axis2f2f/newarchi.JPG> ?
> >> >
> >> > alek
> >> >
> >> > --
> >> > The best way to predict the future is to invent it - Alan Kay
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
>
>
>
>
> --
> Ajith Ranabahu
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] Purpose Deployment changes
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi all,
Sorry that I did not answer this mail earlier. I guess Ishould mention the
trail of thoughts that led to the introduction of this "context bag".
The first and foremost requirement is the ability of the set of contexts to
be serialized. The goal is to use the java serializer and hence we can't
have cyclic references. So the hierarchy is supposed to be one way (no
backward references). We decided that the best thing to do is to keep the
original hierarchy and introduce a "context bag" which has the references to
all the contexts in need.
This effectively allows the context tree to be serializable and let the
handlers access the context bag instead of the message context.
In my mind, Operation context <> MEPContext!
Operation context is a axis-server-lifetime object and MEP context only
lasts until a the MEP is complete. In essence there can be multiple MEP
contexts inside one particular Operation context. Simply, operation context
is a container for the MEP contexts.
This is how I see the context hierarchy.
Engine Context (better called Global :))
|
---- Service Context
|
---- Operation Context
|
------ MEP context
|
----- Message Context
Thoughts ?
Ajith
On Apr 7, 2005 9:38 PM, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
> Hi Venkat.
>
> Its like this , Context Bag is NOT the root of all the context , and which
> is the one passes around all the handlers in a chain. That is Context bag
> is
> a bag which contains all the required contexts to invoke the handlers and
> finally the service.
>
> As you have mentioned there are same boxes in different locations ,
> actually
> what that implies is
> 1. direct arrow from Context bag => Keep references to those contexts in
> Context bag so that if handler want to access any context it can ask
> those contexts from Context Bag.
> 2. As you can see there are some arrows from EngineContext and Mep context
> => that implies those them selves keep references to those contexts. As an
> example if the MEP is IN-OUT then MEPconnext need to keep references to
> both
> IN message context and Out Message context.
>
> Note that : Only the parent keep its child references and child are not
> going to keep any references to its parent.
>
> And one thing if I am not mistaken we do not have context called global
> context which is equivalent to EngineConetxt so the root of context is
> EngineContext .
>
> I am also confused the word EngineContext I rather like if we can change
> it
> to Global Context
>
> Comments .....
>
>
> Deepal
>
>
> > hi Deepal,
> >
> > I'm just trying to understand the diagram in axiscontext.jpg. Can you
> > please add a little documentation also, as to what the arrows mean,
> > and why we have the same boxes at multiple places etc. Is the Context
> > Bag the root of all the contexts? I think the hierarchy that we
> > discussed was a little different. Global Context -> Engine Context ->
> > Service Context -> MEP Context -> Session Context -> Message Context,
> > where each "->" stands for "is parent of" or "contains".
> >
> > confused myself :-)
> > Venkat
> >
> > On Apr 7, 2005 9:17 AM, Deepal Jayasinghe <de...@opensource.lk> wrote:
> >> hi
> >>
> >> sorry I forgot to upload the image , now its working pls try again.
> >>
> >>
> >> Deepal
> >>
> >>
> >> ----- Original Message -----
> >> From: "Aleksander Slominski" <as...@cs.indiana.edu>
> >> To: <ax...@ws.apache.org>
> >> Sent: Thursday, April 07, 2005 9:42 AM
> >> Subject: Re: [Axis2] Purpose Deployment changes
> >>
> >> > Deepal Jayasinghe wrote:
> >> >
> >> >> Hi all;
> >> >>
> >> >>
> >> >> At the axis2 face to face we did number of changes to axis2
> >> >> architecture, had to get rid of EngineRegistry and introduce new set
> >> >> of contexts ( www.apache.org/~deepal/axis2f2f/axiscontext.jpg<http://www.apache.org/%7Edeepal/axis2f2f/axiscontext.jpg>
> >> >> <http://www.apache.org/%7Edeepal/axis2f2f/axiscontext.jpg> )
> >> >>
> >> > this links does not work.
> >> >
> >> > should it be http://people.apache.org/~deepal/axis2f2f/newarchi.JPG<http://people.apache.org/%7Edeepal/axis2f2f/newarchi.JPG>?
> >> >
> >> > alek
> >> >
> >> > --
> >> > The best way to predict the future is to invent it - Alan Kay
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
>
>
--
Ajith Ranabahu
Re: [Axis2] Purpose Deployment changes
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Venkat.
Its like this , Context Bag is NOT the root of all the context , and which
is the one passes around all the handlers in a chain. That is Context bag is
a bag which contains all the required contexts to invoke the handlers and
finally the service.
As you have mentioned there are same boxes in different locations , actually
what that implies is
1. direct arrow from Context bag => Keep references to those contexts in
Context bag so that if handler want to access any context it can ask
those contexts from Context Bag.
2. As you can see there are some arrows from EngineContext and Mep context
=> that implies those them selves keep references to those contexts. As an
example if the MEP is IN-OUT then MEPconnext need to keep references to both
IN message context and Out Message context.
Note that : Only the parent keep its child references and child are not
going to keep any references to its parent.
And one thing if I am not mistaken we do not have context called global
context which is equivalent to EngineConetxt so the root of context is
EngineContext .
I am also confused the word EngineContext I rather like if we can change it
to Global Context
Comments .....
Deepal
> hi Deepal,
>
> I'm just trying to understand the diagram in axiscontext.jpg. Can you
> please add a little documentation also, as to what the arrows mean,
> and why we have the same boxes at multiple places etc. Is the Context
> Bag the root of all the contexts? I think the hierarchy that we
> discussed was a little different. Global Context -> Engine Context ->
> Service Context -> MEP Context -> Session Context -> Message Context,
> where each "->" stands for "is parent of" or "contains".
>
> confused myself :-)
> Venkat
>
> On Apr 7, 2005 9:17 AM, Deepal Jayasinghe <de...@opensource.lk> wrote:
>> hi
>>
>> sorry I forgot to upload the image , now its working pls try again.
>>
>>
>> Deepal
>>
>>
>> ----- Original Message -----
>> From: "Aleksander Slominski" <as...@cs.indiana.edu>
>> To: <ax...@ws.apache.org>
>> Sent: Thursday, April 07, 2005 9:42 AM
>> Subject: Re: [Axis2] Purpose Deployment changes
>>
>> > Deepal Jayasinghe wrote:
>> >
>> >> Hi all;
>> >>
>> >>
>> >> At the axis2 face to face we did number of changes to axis2
>> >> architecture, had to get rid of EngineRegistry and introduce new set
>> >> of contexts ( www.apache.org/~deepal/axis2f2f/axiscontext.jpg
>> >> <http://www.apache.org/%7Edeepal/axis2f2f/axiscontext.jpg> )
>> >>
>> > this links does not work.
>> >
>> > should it be http://people.apache.org/~deepal/axis2f2f/newarchi.JPG ?
>> >
>> > alek
>> >
>> > --
>> > The best way to predict the future is to invent it - Alan Kay
>> >
>> >
>> >
>>
>>
>
>
Re: [Axis2] Purpose Deployment changes
Posted by Venkat Reddy <vr...@gmail.com>.
hi Deepal,
I'm just trying to understand the diagram in axiscontext.jpg. Can you
please add a little documentation also, as to what the arrows mean,
and why we have the same boxes at multiple places etc. Is the Context
Bag the root of all the contexts? I think the hierarchy that we
discussed was a little different. Global Context -> Engine Context ->
Service Context -> MEP Context -> Session Context -> Message Context,
where each "->" stands for "is parent of" or "contains".
confused myself :-)
Venkat
On Apr 7, 2005 9:17 AM, Deepal Jayasinghe <de...@opensource.lk> wrote:
> hi
>
> sorry I forgot to upload the image , now its working pls try again.
>
>
> Deepal
>
>
> ----- Original Message -----
> From: "Aleksander Slominski" <as...@cs.indiana.edu>
> To: <ax...@ws.apache.org>
> Sent: Thursday, April 07, 2005 9:42 AM
> Subject: Re: [Axis2] Purpose Deployment changes
>
> > Deepal Jayasinghe wrote:
> >
> >> Hi all;
> >>
> >>
> >> At the axis2 face to face we did number of changes to axis2
> >> architecture, had to get rid of EngineRegistry and introduce new set
> >> of contexts ( www.apache.org/~deepal/axis2f2f/axiscontext.jpg
> >> <http://www.apache.org/%7Edeepal/axis2f2f/axiscontext.jpg> )
> >>
> > this links does not work.
> >
> > should it be http://people.apache.org/~deepal/axis2f2f/newarchi.JPG ?
> >
> > alek
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
> >
> >
> >
>
>
Re: [Axis2] Purpose Deployment changes
Posted by Deepal Jayasinghe <de...@opensource.lk>.
hi
sorry I forgot to upload the image , now its working pls try again.
Deepal
----- Original Message -----
From: "Aleksander Slominski" <as...@cs.indiana.edu>
To: <ax...@ws.apache.org>
Sent: Thursday, April 07, 2005 9:42 AM
Subject: Re: [Axis2] Purpose Deployment changes
> Deepal Jayasinghe wrote:
>
>> Hi all;
>>
>>
>> At the axis2 face to face we did number of changes to axis2
>> architecture, had to get rid of EngineRegistry and introduce new set
>> of contexts ( www.apache.org/~deepal/axis2f2f/axiscontext.jpg
>> <http://www.apache.org/%7Edeepal/axis2f2f/axiscontext.jpg> )
>>
> this links does not work.
>
> should it be http://people.apache.org/~deepal/axis2f2f/newarchi.JPG ?
>
> alek
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
>
Re: [Axis2] Purpose Deployment changes
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Deepal Jayasinghe wrote:
> Hi all;
>
>
> At the axis2 face to face we did number of changes to axis2
> architecture, had to get rid of EngineRegistry and introduce new set
> of contexts ( www.apache.org/~deepal/axis2f2f/axiscontext.jpg
> <http://www.apache.org/%7Edeepal/axis2f2f/axiscontext.jpg> )
>
this links does not work.
should it be http://people.apache.org/~deepal/axis2f2f/newarchi.JPG ?
alek
--
The best way to predict the future is to invent it - Alan Kay