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
1.2?".
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
things.
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.
--
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]
