axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject Re: [axis2] More Modules and classpaths
Date Mon, 04 Jun 2007 18:49:09 GMT
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,

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:
For additional commands, e-mail:

View raw message