Sanjiva Weerawarana wrote:
+1. While dynamic self-configuring phases is a cool and all-powerful, it seems overkill for most of what we need. What we need is to make sure

I totally disagree. We've added phases for addressing, security, reliability... yes of course those are very common extensions, but they are EXTENSIONS. The whole point of the Module architecture was that builders of extensions, including (good lord, really?) people not even at Apache, should be able to create drop-in components that will work without as much painful configuration as we needed in Axis1. We obviously haven't achieved that with the current design, since this is now the third or fourth time post-release that we're saying "oh yeah let's change the base axis2.xml for everyone so that we can use this module we're writing."

We should have had this since the beginning, and we should add it in 1.4 as planned.

that Axis2 can do security out of the box- that's absolutely critical. CXF for example bundles security and RM with the core platform - if we make this thing so painful to make security to work people will simply walk. Let's not get carried away with abstraction and lose touch with reality.

I think you're making my point here. It's changing everyone's axis2.xml that is a pain (how many new Phases do you need to add in how many different places? - oh missed one!). The point of the model has always been "drop foo.mar into modules/ and it should pretty much work." Of course there will be complex issues that will sometimes require manual overrides to get arbitrary combinations of stuff working together. But for the core set of modules it should be just that easy.

Making dynamic phases work just for the axis2 base platform only is silly IMO. If outside users are asking for it let's do it- but we first have other high(er) priority items to finish IMO.

There is no question in my mind that we need to do it, unless we're going to stop talking about how easy it is to write and add Axis2 Modules and just admit that we're actually a monolithic platform that supports only a few well defined Modules.

--Glen

Sanjiva.

Deepal Jayasinghe wrote:
Deepal,
I disagree. It complicates the chain and our configuration files for
no benefit to a large number of users.
I do not agree with you in this , because just we have configurations in
axis2.xml people will not get confused and did not make the system
complicated.
If they do not want they can remove that.
The lack of dynamic phases also requires people to repetitively edit
axis2.xml files when adding something we haven't yet added a phase
for....
I agree that , but deploying module is not that frequent thing like
deploying services. So this is just one time cost.
it's really naff from a user perspective, especially given all
the huffing and puffing in articles about how great our module
architecture is.
Yes I agree with you in this , but there should be a limitation of the
flexibility we should give.
Can I ask if there's something specific you're worried about wrt
dynamic phases, or if it's just something you don't see a need for?
I dont see need for it , I know it is very cool and I really like to
have. However at the this point Axis2 is kind of stable and people are
using that for production so we should not break the backward
compatibility. Second as I said earlier mail as well none of the user
asked for this.

We have lot more to fix and improve in Axis2 (I mean high priority items
that users have requested) , so we need to focus on that. My general
rule is , if something working fine and no body complain about that ,
then we do not need to change that.  :)

-Deepal


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to