I have a longer reply coming but a definite -1 to doing anything this drastic before 1.0.
I'll explain further when I write my detailed response .. apologies for the two-stage note :(. Sanjiva. On Sat, 2005-07-16 at 21:17 +0600, Srinath Perera wrote: > Hi Glen; > > I think the basic idea is to widen the scope of a componenet! and > replace service archive with a componenet archive. This allowed number > of services to share a same class loader. > > mm .. seems ok to me (may be need to think bit more before commit my self :) > ). > Thanks > Srinath > > On 7/16/05, Glen Daniels <[EMAIL PROTECTED]> wrote: > > > > Axis2'ers: > > > > I've been thinking recently about a couple of things with respect to > > Axis2. First of all, the idea that we might want to support some > > concept of "service groups" - a bunch of individual services which are > > related somehow (via state, implemented with the same code, etc). > > Second of all, I'm thinking of building a JBI implementation on top of > > Axis2, and JBI's notion of "components" are deployable units which can > > each provide multiple services. > > > > What about changing our model slightly to enable "components" to > > implement more than one Web Service? This would entail, I believe: > > > > * Change axis/services to axis/components (just for clarity) > > > > * Add a "ComponentContext" level to the context stack between > > ServiceContext and ConfigurationContext > > > > * Components would be "engage()"d just like services (although looking > > at the code I don't see this for services yet... need to dig around > > more) > > > > * component.xml (replacement for service.xml) would contain 1..N > > <service> elements each of which looks like the current service.xml, so > > the minimal one-service file would be > > <component><service>...</service></component>. We could allow > > optimizing this to just <service> at the top level too! > > > > Thoughts? > > > > Thanks, > > --Glen > > >
