axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert lazarski" <robertlazar...@gmail.com>
Subject Re: [Axis2] *PLEASE* discuss before committing (Re: svn commit: r439555 - in /webservices/axis2/trunk/java/modules: kernel/src/org/apache/axis2/ kernel/src/org/apache/axis2/deployment/util/ kernel/src/org/apache/axis2/receivers/ kernel/src/org/apache
Date Mon, 11 Sep 2006 18:06:02 GMT
Since the build issues got resolved I was able to test the Spring in
the AAR concept again - the thing that everyone who uses Spring with
axis2 seems to want. And it looks like the interface doesn't break
anything and is visible when loading the ServiceObjectSupplier and
Spring with the Service classloader - inside the aar - from the
AbstractMessageReceiver. So at this point I'm +0 as while it doesn't
stop anything that has been accomplished so far, I've yet to really
see a compelling use case leading to an implementation that shows how
the deployment engine can take advantage of the interface beyond what
the Service interface can already do.

Robert

On 9/7/06, robert lazarski <robertlazarski@gmail.com> wrote:
> Hi all,
>
> I think I now get what Saminda is trying to do. He's trying to improve
> the spring support and that may help in other frameworks as well.
> That's pretty cool. Its then a matter of implementation.  See my
> comments inline.
>
> On 9/6/06, Saminda Abeyruwan <samindaa@gmail.com> wrote:
> > Hi Deepal,
> >
> >
> > >
> > >
> > > The best practice is to put the wsdl file into service archive file .
> >
> >
> > 100% correct. Wouldn't it be cool to generate ?wsdl/?xsd if MR is
> > *RPCMessageReceiver, when the service object supplier is
> > "ServiceObjectSupplier"
>
> This is what I wondering ... these changes are to fix jira axis2-1102
> , right ? RPC generation of the wsdl is one of the areas that took a
> long time to get right and was the source of a lot jiras. Is the one
> of the choices we have, ie, is it worth adding an interface to solve
> this issue ? I know there are other issues and I address them below,
> but this may need to stand on its own merit.
>
> >
> > > >
> > > > Current Axis-spring module has
> > SpringAppContextAwareObjectSupplier and
> > > > SpringServletContextObjectSupplier would has it own
> > scope and imho we
> > > > have to write a applicationContex.xml according to them and it's
> > > > pretty restrictive. Thus, naturally i want to write my own supplier
> > > > with it's own helper parameters.
> > >
> > > What do you mean by it has its own scope , is it different from our four
> > > session scope ?
> >
> >
> > Oh no. I didn't mean that. Sorry. For Ex;
> > SpringServletContextObjectSupplier specialized in embedded
> > version (war). Here, it expect to have spring.xml from web.xml. Now if some
> > one wants to deploy a another spring related service to a running axis2.war
> > instance with a completely different applicationContext.xml, is hot
> > deployment really happen ?. These is what i meant by scope, Its limitations.
>
> Hot deployment most certainly can happen via Service.startUp() , with
> the axis2-spring*.jar and the springframeworks jar inside the aar .
> That way there is complete isolation between aar's , and hot
> deployment does happen the right way. I responded to a users question
> a couple weeks ago about this but I haven't documented it yet. It took
> a long time to get the classloader issues and load-on-startup issues
> working right, and at that point I liked what we had. I have to think
> thru and test whether the interface Saminda is proposing from the TCCL
> will affect what was working, ie complete service isolation and hot
> deployment on startUp . .
>
> Keep in mind the spring applicationContext.xml is just one of many
> ways you can configure spring, and I purposely tried to avoid axis2
> getting too involved here. The list is long and OT.
>
> >
> > > >
> > > Saminda , with your change any one how write spring need to implement
> > > the new interface ?
> >
> >
> > Oh no.  They  can  simply use the available  Supplier classes. Users really
> > don't have to worry about it.
>
> Agreed.
>
> >
> > But if any user want to plug another framework to Axis2 to supply service
> > objects, the service object supplier has to implement the proposed
> > interface, otherwise the deployment engine wouldn't recognize it as a
> > service object suppler and ignores it. Wouldn't that be fair enough ?
>
> Saminda, are you aware you can configure Spring in each aar seperately
> and do hot deployment? Are you still restricted doing it that way ?
> Have you tested whether the interface you propose affects that
> scenario ?
>
> Still, I want to make sure I'm addressing your concern. What can the
> deployment engine do with the interface that startUp() cannot do at
> deployment time ?
>
> Also, the spring support and ServiceObjectSupplier came about trying
> to solve a particular problem. I'm not sure planning for other
> frameworks without a particular one in mind is the right approach.
>
> I want to clarify that you've brought up issues I haven't thought
> about, and since there are a lot of ways to use spring and axis2 I
> appreciate the thought provoking ideas you have.
>
> Regards,
> Robert
>
>
> >
> > Saminda
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message