module handlers are invoked for service even when module is not engaged for the serivce

Details

Type: Bug

Status:Closed

Priority: Blocker

Resolution:
Fixed

Affects Version/s:
None

Fix Version/s:
None

Component/s:
None

Labels:

None

Description

I can see that even when a module is not engaged to a service(globally or service wise) handlers of that module is invoked
for that service. This happens both for in and out path.
This must be due to a change done to the engine very recently. I can cleary remember this was working correctly when I was testing sandesha2/C for release 0.90

Activity

I think if the handler is added to a global phase this is a correct behaviour. Inside the handler there should be a logic to prevent message processing if that particular module is not engaged to the intended service.

Manjula Peiris
added a comment - 25/Jun/07 04:32 I think if the handler is added to a global phase this is a correct behaviour. Inside the handler there should be a logic to prevent message processing if that particular module is not engaged to the intended service.

Manjula,
As you said if the handler is added to a global phase I agree that the handler developer should manage to
handle requests that are not intended for the module.
But in this case the module is not engaged globally. Say there are two services X and Y. Say module M is engaged to service X only(by adding a reference in services.xml). Also assume that a module handler H is added to module M specific phase(by editing module.xml). Then if the module handler H is invoked
for a request targeted for Y, it is absolutely wrong. This is exactly the problem I was trying explain.

Damitha Kumarage
added a comment - 25/Jun/07 11:21 Manjula,
As you said if the handler is added to a global phase I agree that the handler developer should manage to
handle requests that are not intended for the module.
But in this case the module is not engaged globally. Say there are two services X and Y. Say module M is engaged to service X only(by adding a reference in services.xml). Also assume that a module handler H is added to module M specific phase(by editing module.xml). Then if the module handler H is invoked
for a request targeted for Y, it is absolutely wrong. This is exactly the problem I was trying explain.

The problem is that phases are shared between operations and owner of phase is phases_info.
So if I refer to the example I mentioned in my previous comment when service X is loaded if handler H is added to the Module M specifc phase, then when service Y is loaded since the same phase is used the the previously added H handler is also availble for this service operation too.
To avoid this I make the operation the owner of the phases and avoid reusing the phases.
This is done by following change

Damitha Kumarage
added a comment - 30/Jul/07 06:54 The problem is that phases are shared between operations and owner of phase is phases_info.
So if I refer to the example I mentioned in my previous comment when service X is loaded if handler H is added to the Module M specifc phase, then when service Y is loaded since the same phase is used the the previously added H handler is also availble for this service operation too.
To avoid this I make the operation the owner of the phases and avoid reusing the phases.
This is done by following change
Before
phase = axutil_hash_get(phases_info->op_in_phases, phase_name,
AXIS2_HASH_KEY_STRING);
if(!phase)
{
phase = axis2_phase_create(env, phase_name);
axutil_hash_set(phases_info->op_in_phases, phase_name,
AXIS2_HASH_KEY_STRING, phase);
}
status = axutil_array_list_add(op_in_phases, env, phase);
Now
phase = axis2_phase_create(env, phase_name);
status = axutil_array_list_add(op_in_phases, env, phase);
I'll commit this code if no side effects are reported