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]
