Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 38954 invoked from network); 16 May 2009 04:09:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 16 May 2009 04:09:08 -0000 Received: (qmail 63373 invoked by uid 500); 16 May 2009 04:09:07 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 63262 invoked by uid 500); 16 May 2009 04:09:07 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 63253 invoked by uid 99); 16 May 2009 04:09:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 16 May 2009 04:09:07 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of amilasuriarachchi@gmail.com designates 209.85.221.131 as permitted sender) Received: from [209.85.221.131] (HELO mail-qy0-f131.google.com) (209.85.221.131) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 16 May 2009 04:08:55 +0000 Received: by qyk37 with SMTP id 37so4071930qyk.30 for ; Fri, 15 May 2009 21:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=itaUKF5t1o47beKezGjW/egBX6yUSLWwEwKxiU6pmeg=; b=kSETEIZz04zFtehgjbFAfUJiVW2H2Cs1lcx3RF9cC3fFs9aUq9u0BtXnusBw+li0eN 4Pf0GidvRD2VowKLW471XH6j6ZiwJK+l+6c+ZstHIiImLx7W/s+jGKvZR4lnhpCWQ8ZG Fh5OQqNOyBpZRliNc85MKnelbDmcIT20K7srw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=jiUcFn2qYInHxM0kEYbgwN6nbSAjJ73TlZnWmovAE/4ogdurppA6xg3XTcuCAWSFVM mVWwf5qaaxMnetLhWCetq14C1KK6ajGX1TNGyJF0Pa1FIsREaWdzGD+EEKgMP0whJd44 UXrJXu0lv+hAQwYY6F4PubcxiRZ9gf3uHV0O4= MIME-Version: 1.0 Received: by 10.229.100.13 with SMTP id w13mr2551577qcn.62.1242446914481; Fri, 15 May 2009 21:08:34 -0700 (PDT) In-Reply-To: References: <4A0ACB0F.9060902@gmail.com> <4A0B24BD.3040305@gmail.com> <4A0B2889.6090201@gmail.com> <4A0C230B.5030700@gmail.com> Date: Sat, 16 May 2009 09:38:33 +0530 Message-ID: <60708f4b0905152108y53d51bday8202d53ba72bd6bd@mail.gmail.com> Subject: Re: Improving Axis Observer behaviour From: Amila Suriarachchi To: axis-dev@ws.apache.org Content-Type: multipart/alternative; boundary=0016363b85cafd70230469ffb65a X-Virus-Checked: Checked by ClamAV on apache.org --0016363b85cafd70230469ffb65a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, May 15, 2009 at 3:21 AM, Andreas Veithen wrote: > Deepal, > > I think that simply adding a new method to AxisObserver is still a > valid alternative, especially because this would not break binary > compatibility. > > Another solution is to take the point of view that AxisObserver should > be strictly limited to lifecycle events (deploy, undeploy, start, > stop) of various AxisDescription implementations and that therefore > the proposed extension has no place there. One would then define a new > listener type and add methods to AxisConfiguration to > register/unregister these listeners. This has the additional advantage > that it would be much easier to document (which is an aspect not yet > fully taken into account in the current version of the patch). hi Andreas, Could you please attach a patch for you suggestion? Since anyway we have agreed to do some API changes to next Axis2 release it is better to do this change in a nice way in the expense of API changes. thanks, Amila. > > > Andreas > > On Thu, May 14, 2009 at 15:56, Deepal jayasinghe > wrote: > > I know :'( , do you have anything else in your mind ? > > > > Deepal > >> Looks quite ugly :-) > >> > >> Andreas > >> > >> On Wed, May 13, 2009 at 22:07, Deepal jayasinghe > wrote: > >> > >>> You are correct, how about the following (I know which is not 100% > correct) > >>> > >>> Let's change AxisEvent to hold the reference to an AxisDescription. We > >>> can set that only if the even type is engage of disengage, for example > >>> if we engage to a service then description would be an AxisService. > >>> > >>> What do you think? > >>> > >>> Deepal > >>> > >>>> Then you don't get the information about the service or operation on > >>>> which the module has been engaged... > >>>> > >>>> Andreas > >>>> > >>>> On Wed, May 13, 2009 at 21:51, Deepal jayasinghe > wrote: > >>>> > >>>> > >>>>> Andreas, > >>>>> > >>>>> Great you brought this, > >>>>> > >>>>> how about changing the AxisEvent to have moduleEngage and disEngage > >>>>> events, and then use the following existing method > >>>>> > >>>>> void moduleUpdate(AxisEvent event, AxisModule module); > >>>>> > >>>>> If you do so we have enough information, and no changes to API. > >>>>> > >>>>> Deepal > >>>>> > >>>>> > >>>>>> Deepal, > >>>>>> > >>>>>> The question is how to best implement this (see AXIS2-4347). There > are > >>>>>> two options: > >>>>>> > >>>>>> 1. Use an existing method of the AxisObserver interface and only > >>>>>> define a new event type. Disadvantage: We can only provide limited > >>>>>> information to the observer. Advantage: No modification of the API > >>>>>> required. > >>>>>> > >>>>>> 2. Define a new method in AxisObserver. Advantage: We can pass the > >>>>>> AxisModule and AxisDescription object to the method. Disadvantage: > >>>>>> This will break existing AxisObserver implementations (at build > time, > >>>>>> not at runtime). > >>>>>> > >>>>>> What is your opinion? > >>>>>> > >>>>>> I recently worked with AxisObserver in the context of the transports > >>>>>> and I think that anyway we should add an AbstractAxisObserver (with > >>>>>> empty default implementations for the methods defined in > AxisObserver) > >>>>>> and change the Javadoc of AxisObserver to recommend extending > >>>>>> AbstractAxisObserver instead of implementing AxisObserver directly. > >>>>>> This pattern makes sure that in the future we can add new methods to > >>>>>> AxisObserver without breaking anything. > >>>>>> > >>>>>> Andreas > >>>>>> > >>>>>> On Wed, May 13, 2009 at 15:28, Deepal jayasinghe > wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> go for it. > >>>>>>> > >>>>>>> Deepal > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> Hi , > >>>>>>>> > >>>>>>>> Currently AxisObserver does not get notified when a Module engaged > or > >>>>>>>> disengaged in the Runtime. > >>>>>>>> So to have that behaviour i would like purpose to add two Axis > events > >>>>>>>> Named MODULE_ENGAGED , MODULE_DISENGAGED > >>>>>>>> > >>>>>>>> and in the new behaviour when a module get engaged/disengaged to > a > >>>>>>>> Service or to an Operation AxisObserver will get notified with > >>>>>>>> above Events. > >>>>>>>> So if there is no issues regarding this improvement i would like > to > >>>>>>>> provide a patch to Axis2 trunk > >>>>>>>> > >>>>>>>> thank you, > >>>>>>>> > >>>>>>>> Charith Dhanushka Wickramarachchi > >>>>>>>> http://charithwiki.blogspot.com/ > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> -- > >>>>>>> Thank you! > >>>>>>> > >>>>>>> > >>>>>>> http://blogs.deepal.org > >>>>>>> http://deepal.org > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> -- > >>>>> Thank you! > >>>>> > >>>>> > >>>>> http://blogs.deepal.org > >>>>> http://deepal.org > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>> -- > >>> Thank you! > >>> > >>> > >>> http://blogs.deepal.org > >>> http://deepal.org > >>> > >>> > >>> > >> > >> > > > > > > -- > > Thank you! > > > > > > http://blogs.deepal.org > > http://deepal.org > > > > > -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ --0016363b85cafd70230469ffb65a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, May 15, 2009 at 3:21 AM, Andreas= Veithen <andreas.veithen@gmail.com> wrote:
Deepal,

I think that simply adding a new method to AxisObserver is still a
valid alternative, especially because this would not break binary
compatibility.

Another solution is to take the point of view that AxisObserver should
be strictly limited to lifecycle events (deploy, undeploy, start,
stop) of various AxisDescription implementations and that therefore
the proposed extension has no place there. One would then define a new
listener type and add methods to AxisConfiguration to
register/unregister these listeners. This has the additional advantage
that it would be much easier to document (which is an aspect not yet
fully taken into account in the current version of the patch).
=

hi Andreas,

Could you please attach a patch for you suggest= ion?
Since anyway we have agreed to do some API changes to next Axis2 re= lease it is better to
do this change in a nice way in the expense of API changes.

thanks,<= br>Amila.

Andreas

On Thu, May 14, 2009 at 15:56, Deepal jayasinghe <deepalk@gmail.com> wrote:
> I know =A0:'( , do you have anything else in your mind ?
>
> Deepal
>> Looks quite ugly :-)
>>
>> Andreas
>>
>> On Wed, May 13, 2009 at 22:07, Deepal jayasinghe <deepalk@gmail.com> wrote:
>>
>>> You are correct, how about the following (I know which is not = 100% correct)
>>>
>>> Let's change AxisEvent to hold the reference to an AxisDes= cription. We
>>> can set that only if the even type is engage of disengage, for= example
>>> if we engage to a service then description would be an AxisSer= vice.
>>>
>>> What do you think?
>>>
>>> Deepal
>>>
>>>> Then you don't get the information about the service o= r operation on
>>>> which the module has been engaged...
>>>>
>>>> Andreas
>>>>
>>>> On Wed, May 13, 2009 at 21:51, Deepal jayasinghe <deepalk@gmail.com> wrote:
>>>>
>>>>
>>>>> Andreas,
>>>>>
>>>>> Great you brought this,
>>>>>
>>>>> how about changing the AxisEvent to have moduleEngage = and disEngage
>>>>> events, and then use the following existing method
>>>>>
>>>>> void moduleUpdate(AxisEvent event, AxisModule module);=
>>>>>
>>>>> If you do so we have enough information, and no change= s to API.
>>>>>
>>>>> Deepal
>>>>>
>>>>>
>>>>>> Deepal,
>>>>>>
>>>>>> The question is how to best implement this (see AX= IS2-4347). There are
>>>>>> two options:
>>>>>>
>>>>>> 1. Use an existing method of the AxisObserver inte= rface and only
>>>>>> define a new event type. Disadvantage: We can only= provide limited
>>>>>> information to the observer. Advantage: No modific= ation of the API
>>>>>> required.
>>>>>>
>>>>>> 2. Define a new method in AxisObserver. Advantage:= We can pass the
>>>>>> AxisModule and AxisDescription object to the metho= d. Disadvantage:
>>>>>> This will break existing AxisObserver implementati= ons (at build time,
>>>>>> not at runtime).
>>>>>>
>>>>>> What is your opinion?
>>>>>>
>>>>>> I recently worked with AxisObserver in the context= of the transports
>>>>>> and I think that anyway we should add an AbstractA= xisObserver (with
>>>>>> empty default implementations for the methods defi= ned in AxisObserver)
>>>>>> and change the Javadoc of AxisObserver to recommen= d extending
>>>>>> AbstractAxisObserver instead of implementing AxisO= bserver directly.
>>>>>> This pattern makes sure that in the future we can = add new methods to
>>>>>> AxisObserver without breaking anything.
>>>>>>
>>>>>> Andreas
>>>>>>
>>>>>> On Wed, May 13, 2009 at 15:28, Deepal jayasinghe &= lt;deepalk@gmail.com> wrote: >>>>>>
>>>>>>
>>>>>>
>>>>>>> go for it.
>>>>>>>
>>>>>>> Deepal
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi ,
>>>>>>>>
>>>>>>>> Currently AxisObserver does not get notifi= ed when a Module engaged or
>>>>>>>> disengaged in the Runtime.
>>>>>>>> So to have that behaviour i would like pur= pose to add =A0two Axis events
>>>>>>>> Named MODULE_ENGAGED , MODULE_DISENGAGED >>>>>>>>
>>>>>>>> and in the new behaviour =A0when a module = get engaged/disengaged to a
>>>>>>>> Service or to an Operation AxisObserver wi= ll get notified with
>>>>>>>> above Events.
>>>>>>>> So if there is no issues regarding this im= provement i would like to
>>>>>>>> provide a patch to Axis2 trunk
>>>>>>>>
>>>>>>>> thank you,
>>>>>>>>
>>>>>>>> Charith Dhanushka Wickramarachchi
>>>>>>>> http://charithwiki.blogspot.com/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Thank you!
>>>>>>>
>>>>>>>
>>>>>>> http://blogs.deepal.org
>>>>>>> http://deepal.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Thank you!
>>>>>
>>>>>
>>>>> = http://blogs.deepal.org
>>>>> http:/= /deepal.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>> Thank you!
>>>
>>>
>>> http://b= logs.deepal.org
>>> http://deepal.= org
>>>
>>>
>>>
>>
>>
>
>
> --
> Thank you!
>
>
> http://blogs.dee= pal.org
> http://deepal.org<= br> >
>



--
Amila Suria= rachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
--0016363b85cafd70230469ffb65a--