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 <deep...@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 <deep...@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 <deep...@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 <deep...@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
>
>

Reply via email to