I'm the idiot who suggested fixing the RM problem :-)
Given the choice between re-architecting modules to insert their own phases - or just adding the RMPhase to the standard phases you can guess which is my proposal. I vote for the really really simple option. [In fact I we don't even need that. We already have OperationInPhase (for example) where the RM handlers could go. But it would be clearer or nicer to add the RMPhases into the default XML] However, as a solution to a general problem, I don't think we need the ability for modules to insert phases. There is already plenty of scope for any module writer to add their handlers into the right places using the existing phases that are hard-coded plus the capabilities to do partial ordering of handlers that exist today. I'm -1 on doing a lot of coding to change the handler/phase/module architecture when the solution to this problem is using a text editor to add <phase name="RMPhase"/> in about 4 places. Paul On 6/4/07, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
Glen Daniels wrote: > > Hm. While the current system technically works, the old Axis1 > Phase-less way of deploying ordered Handlers worked too, as long as you > were sufficiently careful and correct. :) > > Modules right now aren't really pluggable components. To use a Module > which uses non-standard phases in your service, you need to a) read the > Module documentation and understand WHICH phases you need to add to the > global configuration, AND in what order (this seems like EXACTLY the > kind of stuff we were trying to move from documentation to config/code > for Axis2), b) change axis2.xml accordingly, and c) deploy the module > globally. That's a pain, and I think it's kind of ironic that it's > exactly this kind of configuration we were avoiding for Handlers. The problem I have with this proposal is that we're trying to come up with an automatic solution to a *problem we have*. That is, security and RM are really core parts of what we're trying to do. If we had *users* saying that our phase insertion architecture is too limited I'd be fully convinced but here we have essentially core bits of the WS-* stack folks requiring that we insert another string into axis2.xml and the proposed solution is a major feature improvement. I'm not convinced by such arguments - features need to be coming from users .. not from us. This is like the argument for cloning the handler chain; we did it and we don't need it at all .. YAGNI. So, I'm with Deepal in opposing this approach. Also, I'd even like to reconsider the decision to make Rampart into a separate project. As we noticed with the 1.2 release, users need Rampart to be available *with* the axis2 releases. Same goes for Sandesha. So if those projects are ok I think its best to move them back in as maven modules of axis2. Yes I know this is a big change of heart for me but I've learnt from the experience that we made a mistake. As a major proponent of the split into multiple projects, I admit I was wrong! > It's like we've gone halfway, and I would really like to go the rest of > the way so that Modules can just work together without the intervention > of skilled human technicians modifying global configuration files. IMHO > the only times you should be REQUIRED to touch config files as an > "assembler" of prebuilt components should be to resolve a conflict. Again, this is a theoretical argument. If there were *users* beating down our door saying "dudes, this stuff is so cool but you are killing me with this lack of recursiveness for phases" then I'd be convinced. When we're trying to do this as a solution to the problem of "can we add the RM phase to axis2.xml" I don't accept it. > (While we're on the subject I also continue to think that we should > allow packaging Modules in Service archives - i.e. > services/MyService/modules/foo.mar. It's a very analogous situation.) ARGH! A major -1 for this! This is COMPLETELY YAGNI and further brings into Axis2 a feature of Axis1 which I personally fought to keep out: allowing user code to extend the system runtime. Modules are not some random bit of code to run- they are system extensions. As such, user services have no business extending the system! I opposed adding handlers in services.xml for the same reason. I lost that argument but AFAICT we don't have a single *user* usecase for that yet. Making that even more functional is not the thing we should be putting our time and effort into at this stage. In any case, we have the ability to have a module and have only one service engage it. All our approach forces is that the service runtime admin be aware of what modules they're running. That's goodness, not a limitation. Axis2 is *full* of cool features. What Axis2 needs is stability, consistency and completion of those features. We don't need more features right now (which will likely end up as YAGNI) - let's get what we have to work exactly right, wait for users to demand more features and *then* add them. >> May be we can add that for Axis3 (if we are planing to do so :) ) > > Deepal, I would be kind of bummed if we had to do an Axis3. It would > mean we didn't get it right in Axis2. I agree. We've now built pretty much the entire WS-* core platform for Axis2 and the architecture is holding up just fine. So I see no reason to think we'll need an Axis3. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ Director; Open Source Initiative; http://www.opensource.org/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Paul Fremantle Co-Founder and VP of Technical Sales, WSO2 OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
