Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 34559 invoked from network); 8 Sep 2006 06:35:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 8 Sep 2006 06:35:01 -0000 Received: (qmail 68608 invoked by uid 500); 8 Sep 2006 06:34:57 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 68575 invoked by uid 500); 8 Sep 2006 06:34:57 -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 68559 invoked by uid 99); 8 Sep 2006 06:34:57 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Sep 2006 23:34:57 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Sep 2006 23:34:56 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id BCA8241000B for ; Fri, 8 Sep 2006 06:31:22 +0000 (GMT) Message-ID: <31469660.1157697082755.JavaMail.jira@brutus> Date: Thu, 7 Sep 2006 23:31:22 -0700 (PDT) From: "Deepal Jayasinghe (JIRA)" To: axis-dev@ws.apache.org Subject: [jira] Commented: (AXIS2-1120) Phases concept is too confusing - please change for v1.1 In-Reply-To: <9482302.1157638163735.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/AXIS2-1120?page=comments#action_12433341 ] Deepal Jayasinghe commented on AXIS2-1120: ------------------------------------------ Well , your first option was there in Axis2 in the initial stage , and when service specific module try to put handlers into global phase Axis2 was throwing exception. But we had to change that when it come to real module like security and RM , they wanted not to throw that exception. And final conclusion was to implement the module or write the handler keeping where it is belong in mind. For example if you engage a module called "foo" to service called "bar" and it put handler into global phases , then as a handle write you have to check whether you are engaged to message coming in and do the processing, using message context you can check whether you are engage or not. I also more reluctant to change the Axis2 initial design , I mean allowing service specific module to put handler into global phases , but finally I have to agree to the community design. Any way at this moment I dont think we can go ahead and change that , only option we have is to write proper document explaining how it works and how should you write handler. > 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: axis-dev-unsubscribe@ws.apache.org For additional commands, e-mail: axis-dev-help@ws.apache.org