> 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." Well, not everyone write module does not going to change axis2.xml , and I do not think that all of them will try to add a new phase to axis2.xml. Most of the time they can live with what we have in axis2.xml , not only that our phase rules are powerful enough to support what security is looking for. Even though they try to add a new phase to axis2.xml they can live without doing that. > > We should have had this since the beginning, and we should add it in > 1.4 as planned. No objection. However I would like to call for a vote in user list and developer list before we do major architectural changes , we need to listen to users who actually uses Axis2 and need to ask their opinion on those. > >> 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. As I said earlier , security people can live without it. So I do not see big issue with that. I do agree what you purpose is very cool and very useful. > >> 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. :)
We all need think , that Axis2 is not a toy anymore and we should not and can not change Axis2 codebase and architecture way we want. We need to think about the people who are using that as well. -Deepal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
