[ 
http://issues.apache.org/jira/browse/AXIS2-1120?page=comments#action_12433689 ] 
            
Thilo Frotscher commented on AXIS2-1120:
----------------------------------------


I think I have to clarify my request for improvement. By no means I wanted to 
suggest to completely remove the concept of phases. I think it's generally a 
great idea. It's just one single behaviour of modules and phases that I think 
is too confusing. That is, as described before: engaging a module with a single 
service can result in engaging the module with all services...without any 
warning.

What do you think about the following suggestions? They should be easy to 
implement:

1) if a module is engaged with a single service or operation, and the module 
contains handlers that belong to a global phase, then Axis2 reports a warning
    - in the log file of the servlet container
    - in the web administration frontend (if the engagement was done using the 
frontend)
   This warning says: "You engaged module FOO with service/operation BAR, but 
because the module contains global handlers, these will be invoked for ALL 
messages, no only for messages to service/operation BAR"

2) Deepal wrote that developers of handlers should check in the MessageContext 
whether the handler was engaged to the incoming message or not. Well, if this 
information is stored in the MessageContext, why invoke the handler at all? 
Wouldn't it be better if AxisEngine could do this check and invoke only those 
handlers that were engaged? This is basically the same like my second 
suggestion in my initial posting.

I clearly prefer option 2) and still think that this small change is absolutely 
necessary. It would make the phases concept perfect. Without a change, it's 
just too complicated to figure out which services a module is engaged with. I 
am happy to discuss this further and to tell you about feedback from 
participant's of my Axis2 training courses about this issue. 


> Phases concept is too confusing - please change for v1.1
> --------------------------------------------------------
>
>                 Key: AXIS2-1120
>                 URL: http://issues.apache.org/jira/browse/AXIS2-1120
>             Project: Apache Axis 2.0 (Axis2)
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.0
>            Reporter: Thilo Frotscher
>            Priority: Blocker
>
> With Axis2 1.0 it can easily happen that you engage a module with services 
> without realizing it! 
> This is because even if explicitly engaging a module with a *single* service 
> or a *single* operation, its handlers will automatically be invoked for *all* 
> services if they belong to a global phase. There's no warning messages or 
> anything that prevent's you from doing this. IMHO this bevaviour is very 
> confusing, especially for beginners.
> I think there are two possible solutions to this:
> - disallow engagement with single services or operations for all modules that 
> contain handlers in global phases
>   (at the very least, display a warning message that the module will actually 
> be invoked for *all* services)
> - or make sure that handlers in global phases are *available*  to all 
> services, but will only be invoked for services that they were *explicitly* 
> engaged with
> Either way, the release of Axis2 1.1 is a very good opportunity to change 
> this behaviour. The later you do this, the more backwards compatibility might 
> have to be sacrificed.
> I am sure that many users will vote for this change once the use of Axis2 in 
> general and modules in particular is more widespread.
> There was a discussion about this on the mailing list, but somehow it died 
> out: http://marc.theaimsgroup.com/?l=axis-dev&m=115394666310204&w=2
> Please consider making this change for v1.1
> Thanks!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to