Working on classpath stuff right now, but a few quick responses to
points you raise here:
1) The idea for Modules, for instance, did not come from our users - I
should know, because (IIRC) I was the first one to mention it back in
2002! :) There is a longer conversation here but I most definitely do
NOT agree (esp in terms of infrastructure software like Axis) that we
shouldn't do useful stuff because users haven't asked for it
specifically. Do you think IDEA would have all the cool refactoring
that it does today if they'd only implemented stuff that was
specifically asked for? As the experts in a particular area (Java infra
development, WS, etc) the developers of a given project are often the
source of the best ideas for making their software easier and more
effective to use. It's a balance.
As for cloning the handler chain, if I'm interpreting you correctly we
absolutely did need to do that to support consistent processing
semantics in the face of potential hot-deployments while messages are
flowing, no?
2) If you want to end up with a monolithic JAR which does RM and
Security and Addressing and that's it, then fine we can just stop now.
But I thought we were building a world-class WS-focused processing
framework that scales from embeddable up through enterprise. If so, we
need to make it sufficiently robust that it will not need major
rearchitecting in the future. Also, I personally want it to be dead
simple to engage transactions, or to allow someone's WS-CAF extensions
to work, or some company-internal extension using headers. New stuff is
NOT going to stop coming down the pipe. Our stuff will either be
sufficiently easy to evolve, or it won't.
3) Any time you deploy a *service* you're already allowing user code to
extend the system runtime. Come to mention it, I could just build my
own handler framework inside my service implementation, couldn't I?
Wouldn't that be the same thing? Also, services have access to the
AxisConfiguration and can muck with it as much as they want.
Oh, and 4) it's not that much code, and wouldn't break existing stuff.
More later,
--Glen
Sanjiva Weerawarana 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
