hi,
here with I have attached an document which describes some of the problems
I see with the current axis2 architecture and a possible solution.
Please have a look and put your comments.
Amila.
--
Amila Suriarachchi,
WSO2 Inc.
Axis2 Architecture.odt
Description: application/vnd.oasis.opendoc
Hi Amila,
Here are some of the answers to your questions. I believe other will
chip in with whatever they can contribute (and ofcourse correct me if
I'm wrong :)) but I will try to answer as many of your questions as
possible.
1. AFAIR the primary reason why the operation client is implemented as
Hi Ajith
> Hi Amila,
> Here are some of the answers to your questions. I believe other will
> chip in with whatever they can contribute (and ofcourse correct me if
> I'm wrong :)) but I will try to answer as many of your questions as
> possible.
>
> 1. AFAIR the primary reason why the operation cl
Hi Amila,
I do agree with your new proposal , but the the issue is each and every
handler needs call the next handler in the chain. In that case control
is with the module author not with Axis2. In the current implementation
handler will process the message and let AxisEngine know whether to
co
On 5/29/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
Hi Amila,
I do agree with your new proposal ,
but the the issue is each and every
handler needs call the next handler in the chain. In that case control
is with the module author not with Axis2.
yes. Actually this is the beauty o
hi deepl,
I agree with you that we have already release the 1.2 and there is no way to
do any changes (even every one agrees as well).
this is a solution came to my mind which would adreess the two issues you
have
raise.
public void next(MessageContext messageContext) throws AxisFault {
Hi all,
Forgive me for the delayed answer - I was hoping to write a detailed
answer yesterday but other things kept me busy. I'm sure a voice
conversation would be much faster and comprehensive but all of us are
in different timezones that makes it quite difficult to find a
convenient time slot. A
hi ajith,
Once again thanks for your reply. Although we are now not in a position to
change the
architecture, I would like to add comments to your answer since this
discussion
actually helped me to learn a lot.
On 5/31/07, Ajith Ranabahu <[EMAIL PROTECTED]> wrote:
Hi all,
Forgive me for the de
Sanjiva Weerawarana wrote:
Deepal Jayasinghe wrote:
The main reason behind handler chain clone was to support dynamic
modification of the chain, that is some one can change the current
handler chain while he is processing the message. So we clone the
template handler chain and store that in the
Deepal Jayasinghe wrote:
The main reason behind handler chain clone was to support dynamic
modification of the chain, that is some one can change the current
handler chain while he is processing the message. So we clone the
template handler chain and store that in the message context.
This part
> Deepal Jayasinghe wrote:
>> The main reason behind handler chain clone was to support dynamic
>> modification of the chain, that is some one can change the current
>> handler chain while he is processing the message. So we clone the
>> template handler chain and store that in the message context
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Deepal Jayasinghe wrote:
> Yes when we discuss this at the One of the ApacheCon , I also did not
> agree initially but since Glen had strong arguments I had to agree .
:))
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Usin
OK so if there's no disagreement can we go ahead with this? This means the
set of handlers is determined at deployment time, unless the flag is set
and the user wants dynamic control over it.
Sanjiva.
Deepal Jayasinghe wrote:
Deepal Jayasinghe wrote:
The main reason behind handler chain clon
Amila, can you please summarize the discussion so far (hopefully in a
short, clear point-by-point email!) .. I've tried to follow the
discussions but there's been a lot of it and its not clear where there
appears to be consensus and where there isn't.
Thanks,
Sanjiva.
Amila Suriarachchi wrot
Hi,
I will write a summary of the discussion to the list later today (if
anyone else wants to go ahead please do - don't wait for me :)) but
let me just answer a few concerns first.
First of all I was mistaken about the handlers during the last
conversation. Now the handlers are stateful (i.e. w
> OK so if there's no disagreement can we go ahead with this? This means
> the set of handlers is determined at deployment time, unless the flag
> is set and the user wants dynamic control over it.
+1 to add that for 1.3 release.
(may be I can change and commit the changes :) )
Thanks
Deepal
-
hi ajith,
Please see some below comments.
On 6/4/07, Ajith Ranabahu <[EMAIL PROTECTED]> wrote:
Hi,
I will write a summary of the discussion to the list later today (if
anyone else wants to go ahead please do - don't wait for me :)) but
let me just answer a few concerns first.
First of all I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Amila, Ajith and all,
First Amila great work. You should be real smart to figure the
architecture, just looking at the code :)
1. There is a similarity between what you've proposed and the current
engine. Even though you have put TransportSender o
Hi,
5. Again, as Ajith mentioned also, we do not know the handler chain
before hand. IIRC, we have templates of handler chains and we clone from
it to get the fixed set of handlers. But after that we need to include
service and operation specific handlers. Ajith, yes we do have service
specific
Eran Chinthaka wrote:
6. About faults, yes I also agree with you for some extent. When Deepal
initially put that we had some discussions on that.
"Why there is a separate flow to handle the Faults?"
With my understanding, the handers to be invoked when there is a fault,
could be different fo
Samisa,
think of this situation, we need to add a rampart handler for
encrypting a response back to the client and we don't want to do any
encryption if there is a fault. currently if we just add a handler in
the out flow, we are all set. otherwise, we need to add additional
logic in the handler
Samisa Abeysinghe wrote:
Eran Chinthaka wrote:
6. About faults, yes I also agree with you for some extent. When Deepal
initially put that we had some discussions on that.
"Why there is a separate flow to handle the Faults?"
With my understanding, the handers to be invoked when there is a fau
Ajith Ranabahu wrote:
However we may be able to improve a bit of the code :) Since the
handlers are stateless replicating them would not mean anything
(shouldn't make a difference).
+1. I too agree.
Should we able to create a read-only
List implementation where only one of the handler instanc
Hi ajith and chinthaka and all,
I really appreciate your comments on this since this helps me (and lot of
new comers to Axis2 )
to learn about the Axis2 core and the reasons behind some design decisions.
Please have a look at what I thought about the things you have specified.
On 5/29/07, Eran C
Samisa Abeysinghe wrote:
> Ajith Ranabahu wrote:
>>
>> However we may be able to improve a bit of the code :) Since the
>> handlers are stateless replicating them would not mean anything
>> (shouldn't make a difference).
> +1. I too agree.
>> Should we able to create a read-only
>> List implemen
Samisa Abeysinghe wrote:
> Eran Chinthaka wrote:
>> 6. About faults, yes I also agree with you for some extent. When Deepal
>> initially put that we had some discussions on that.
>>
> "Why there is a separate flow to handle the Faults?"
> With my understanding, the handers to be invoked when t
hi all,
Let me present this in a different way.
In the current architecture we can say "Operation has a set of handlers".
So it is represented as inflow/outflow in the AxisOperation.
we can say the first statement again as "hadler has a set of operations"
If we represent this then, Handler have
Amila,
First of all I want to make sure I understand your idea properly. Based on
my understanding I have put down my comments.
Is this what u are proposing?I am putting them down in point form to make it
simple and easy to understand. Please shout if I have misunderstood you.
1. You want a sin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sanjiva Weerawarana wrote:
> It is necessary .. we already have scenarios where the security policy
> for faults is different from normal messages.
I agree. This is just question of where to put the if statement
if(envelope.getBody().hasFault()). If
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Now I can feel the real barriers of communication when we are far away :).
Since this is a revisit of the architecture, and all the replies are
very long, can we have an audio chat.
We used to have weekly IRC chats, but not anymore. So how about havin
While there are many challenges in this medium, the biggest advantage is
that the history is recorded. This is a good conversation to either
(re-)rationalize the current architecture or improve it. Given the
globally distributed nature of this community, its virtually impossible to
find a singl
hi Rajith.
Thanks for your reply.
Sorry for late replying. I tried to reply once but missed it and fogotten.
On 5/29/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
Amila,
First of all I want to make sure I understand your idea properly. Based
on my understanding I have put down my comments.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sanjiva Weerawarana wrote:
> While there are many challenges in this medium, the biggest advantage is
> that the history is recorded. This is a good conversation to either
> (re-)rationalize the current architecture or improve it. Given the
> globally
Am usually awake at that time...except when you need me of course :)
On 6/2/07, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sanjiva Weerawarana wrote:
> While there are many challenges in this medium, the biggest advantage is
> that the history is rec
It's an interesting discussion but I'm happy not to be involved (I'm
not expecting big changes to the axis2 architecture to happen, expect
some followup on the list if there is:-)
David
On 03/06/07, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sanjiva
35 matches
Mail list logo
