axis-java-dev mailing list archives

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

That was a different time- we were architecting a new Axis version and OF 
COURSE we need to create stuff. We're NOT doing that now. Our users need 
stability, not creativity from us, especially when no one has asked for it.

>  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.

Yes of course I know that. However, there's a time for everything. I'm 
happy to say we'll do this for a future version but I'm very concerned 
about taking on more changes at this stage given that we've made lots of 
changes already. So I'm taking a different view from David on that- just 
because we've made all these changes is hardly a reason to make more changes!

Every change needs to be rationalized by what problem it solves. With all 
due respect Glen you were checked out of Axis2 development for a long 
time. As you know "he who does the work makes the decisions" in open 
source and so we are where we are now. I have no objection to fixing 
what's broken. I have no problem with us dealing with the 400+ pending 
JIRAs *RAISED BY OUR USERS*. I do have a problem with changing things just 
because there's a different way to do it. I do have a problem with 
creating more grand solutions to problems that are not real problems of 
our users. If we didn't have 400+ pending JIRAs and a series of known real 
problems I'd feel differently about every new cool feature.

> 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?

No, not at all. We DO NOT allow hot deployment of modules and that means 
the chain cannot change at runtime. So the feature cannot be affected 
unless you have code that dynamically does it. Its possible but no one has 
done it yet: YAGNI. I'm not arguing to remove it; I just want a switch to 
say turn it off and leave it off by default. If someone wants it they can 
ask for it and voila they have it.

> 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.

I didn't suggest that; I suggested having mars for both of them but have 
them available in the axis2 core as that's what users want. Just observe 
the number of questions about "when will rampart be available for axis2 

>  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 

WHAT? Are you claiming you won't come up with cool new features in the 
future?? No way :). Of course we'll have to keep tweaking it .. people are 
still tweaking httpd right?

BTW are you contradicting yourself by saying this is a major rearch? Later 
you say "it's not that much code" ..

> 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.

It works now Glen. Let our *real users* (not the extensions we write; 
those that the users write) tell us they need a certain feature and we'll 
add it.

> 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.

Yes that last bit is a problem we need to deal with (and we've talked 
about it but never did it; its about protection of the system). I am not 
for making something that can be done now worse just because it would be 
cool to do it. Can you point me to threads on the user list (or a real 
customer case you were directly involved with) which has asked for modules 
to be deployed in a service? How many blogs have you read which said 
"Axis2 is great, but I really wish it was more flexible in blah"?

I feel the same way about service-specific handlers.

I wish the IBM guys were around (they seem to have checked out; they've 
gone radio silent and don't see the commits going either). I know one of 
the major concerns they had about Axis1 (and one of the reasons they left 
it) was exactly this reason: that it allowed arbitrary extensions to be 
deployed by users without having the app server have control over such 

> Oh, and 4) it's not that much code, and wouldn't break existing stuff.

Sorry, that's NEVER a good reason to do it for a system we're trying to 
make into a mature product. What known PROBLEM does it solve? We're 
wasting all this time because we're refusing to add *ONE MORE STRING* to 
axis2.xml. Paul, next time just add it and commit! (And call the phases 
A/B/C/D so that no one can complain.)

Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation;
Founder, Chairman & CEO; WSO2, Inc.;
Director; Open Source Initiative;
Member; Apache Software Foundation;
Visiting Lecturer; University of Moratuwa;

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message