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 Charith Wickramarachchi <ch...@gmail.com> on 2009/05/13 06:32:30 UTC
Improving Axis Observer behaviour
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/
Re: Improving Axis Observer behaviour
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, May 15, 2009 at 3:21 AM, Andreas Veithen
<an...@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 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 <de...@gmail.com>
> 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 <de...@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 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 <de...@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 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 <de...@gmail.com>
> 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/
Re: Improving Axis Observer behaviour
Posted by Andreas Veithen <an...@gmail.com>.
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).
Andreas
On Thu, May 14, 2009 at 15:56, Deepal jayasinghe <de...@gmail.com> 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 <de...@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 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 <de...@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 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 <de...@gmail.com> 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
>
>
Re: Improving Axis Observer behaviour
Posted by Deepal jayasinghe <de...@gmail.com>.
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 <de...@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 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 <de...@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 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 <de...@gmail.com> 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
Re: Improving Axis Observer behaviour
Posted by Charith Wickramarachchi <ch...@gmail.com>.
I have updated the issue with a new patch done according to the way
suggested by Deepal
while doing this change i had to change the notifyObservers() in
AxisConfiguration to accept
an AxisEvent
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: Improving Axis Observer behaviour
Posted by Andreas Veithen <an...@gmail.com>.
Looks quite ugly :-)
Andreas
On Wed, May 13, 2009 at 22:07, Deepal jayasinghe <de...@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 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 <de...@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 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 <de...@gmail.com> 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
>
>
Re: Improving Axis Observer behaviour
Posted by Charith Wickramarachchi <ch...@gmail.com>.
+1
and if we go for the Deepals idea we can avoid changing in the current Axis
Observer Implementations
and i'll be easily change the patch to act in a more generic way.
the pattern Andreas purposing seems good to me.The reason i use the
existing service update for a
Module engage is to avoid that API change. which will be solved using the
above pattern. But we need
to change the current AxisObservers
>
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: Improving Axis Observer behaviour
Posted by Deepal jayasinghe <de...@gmail.com>.
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 <de...@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 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 <de...@gmail.com> 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
Re: Improving Axis Observer behaviour
Posted by Andreas Veithen <an...@gmail.com>.
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 <de...@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 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 <de...@gmail.com> 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
>
>
Re: Improving Axis Observer behaviour
Posted by Deepal jayasinghe <de...@gmail.com>.
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 <de...@gmail.com> 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
Re: Improving Axis Observer behaviour
Posted by Andreas Veithen <an...@gmail.com>.
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 <de...@gmail.com> 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
>
>
Re: Improving Axis Observer behaviour
Posted by Deepal jayasinghe <de...@gmail.com>.
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