On Tue, Jan 18, 2011 at 5:28 PM, Andreas Veithen <andreas.veit...@gmail.com>wrote:
> Yes, I think what Azeez proposes is to make the code that processes > services.xml reusable. Yes, that is what I was suggesting. Probably the relevant deployer can decide whether to call that code or not. > That is a good thing (even if we choose A), but > it is not enough to implement solution A, i.e. we will not get the > behavior we had in previous Axis2 versions (where deploying JAX-WS > services as AAR files worked). Instead these services would be > deployed by a JAX-WS specific deployer. > Isn't it sufficient to just be able to include a services.xml file within the JAXWS jar file, and deploy it in the servicejars directory? What is the purpose or advantage of deploying JAXWS services as AAR files? > > Andreas > > On Tue, Jan 18, 2011 at 12:43, Isuru Suriarachchi <isur...@gmail.com> > wrote: > > Hi Andreas, > > > > I think what Azeez proposes is different from B as well. Because, it > won't > > be a JAX-WS specific thing. If we want to support a services.xml for any > of > > the service types, we should be able to use the same API to do that after > > the AxisService object is created. That code will basically read the > > services.xml and use the parameters to change the behaviour of the > already > > created service. > > > > Thanks, > > ~Isuru > > > > On Tue, Jan 18, 2011 at 4:18 PM, Andreas Veithen < > andreas.veit...@gmail.com> > > wrote: > >> > >> Before selecting the implementation approach, I think we need to > >> choose between the following two options to define what we want to > >> achieve: > >> > >> A) Allow deployment of JAX-WS by the standard service deployer. Of > >> course this means that a new API needs to be introduced so that JAX-WS > >> can plug itself into the service deployer. > >> > >> B) Introduce a separate deployer specifically for JAX-WS services > >> bundled with a services.xml file. > >> > >> Option A has a couple of advantages [1] and the solution originally > >> proposed by me was based on that option (although my PoC uses option > >> B). I think that what Azeez proposes necessarily implies option B. I > >> don't now much about WSO2 Data Services, but I guess that they are not > >> just AAR files and require their own deployer anyway. Therefore, what > >> is a good option for Data Services is not necessarily the right option > >> for JAX-WS services. > >> > >> Andreas > >> > >> [1] http://markmail.org/message/jz5bpoybvylbzb6q > >> > >> On Tue, Jan 18, 2011 at 06:25, Isuru Suriarachchi <isur...@gmail.com> > >> wrote: > >> > +1. I'll investigate on this and try to come up with a proper > solution. > >> > > >> > Thanks, > >> > ~Isuru > >> > > >> > On Tue, Jan 18, 2011 at 10:24 AM, Afkham Azeez <afk...@gmail.com> > wrote: > >> >> > >> >> Isuru, > >> >> I think we need a generic way of associating services.xml file with > any > >> >> service type. What I;ve been thinking is, we can have a post Axis > >> >> service > >> >> creation in the deployment phase, where the AxisService object > created > >> >> by > >> >> the deployer is updated based on an associated services.xml file. > Else, > >> >> we > >> >> can give this option to the Deployer author, whereby, the author will > >> >> call > >> >> this Util, and pass in the AxisService, and optionally the > services.xml > >> >> File, and then this util will update the AxisService. > >> >> In WSO2 Data Services, the Data service deployer has its own way of > >> >> getting stuff from the services.xml file. So, it is better to have a > >> >> unified > >> >> way of doing this instead of implementing it for each and every > >> >> deployer > >> >> separately. > >> >> Azeez > >> >> > >> >> On Mon, Jan 17, 2011 at 10:52 PM, Isuru Suriarachchi > >> >> <isur...@gmail.com> > >> >> wrote: > >> >>> > >> >>> Hi all, > >> >>> > >> >>> Andreas has provided a very good explanation on why we need to > support > >> >>> services.xml file for JAX-WS services in [1]. I think we can support > >> >>> it as > >> >>> an optional feature. If someone wants stuff like session management, > >> >>> he can > >> >>> insert a services.xml. And also, as Azeez has proposed, we can > provide > >> >>> a > >> >>> generic API using which a services.xml can be supported for any type > >> >>> of > >> >>> service. > >> >>> > >> >>> WDYT?? > >> >>> > >> >>> Thanks, > >> >>> ~Isuru > >> >>> > >> >>> [1] https://issues.apache.org/jira/browse/AXIS2-4611 > >> >>> > >> >>> -- > >> >>> Technical Lead, > >> >>> WSO2 Inc. http://wso2.org/ > >> >>> Blog : http://isurues.wordpress.com/ > >> >> > >> >> > >> >> > >> >> -- > >> >> Afkham Azeez > >> >> Senior Software Architect & Senior Manager; WSO2, > >> >> Inc.; http://wso2.com, > >> >> > >> >> Member; Apache Software Foundation; http://www.apache.org/ > >> >> email: az...@wso2.com cell: +94 77 3320919 > >> >> blog: http://blog.afkham.org > >> >> twitter: http://twitter.com/afkham_azeez > >> >> linked-in: http://lk.linkedin.com/in/afkhamazeez > >> >> > >> >> Lean . Enterprise . Middleware > >> >> > >> > > >> > > >> > > >> > -- > >> > Technical Lead, > >> > WSO2 Inc. http://wso2.org/ > >> > Blog : http://isurues.wordpress.com/ > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org > >> For additional commands, e-mail: java-dev-h...@axis.apache.org > >> > > > > > > > > -- > > Technical Lead, > > WSO2 Inc. http://wso2.org/ > > Blog : http://isurues.wordpress.com/ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org > For additional commands, e-mail: java-dev-h...@axis.apache.org > > -- *Afkham Azeez* Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com, * * *Member; Apache Software Foundation; **http://www.apache.org/*<http://www.apache.org/> * email: **az...@wso2.com* <az...@wso2.com>* cell: +94 77 3320919 blog: **http://blog.afkham.org* <http://blog.afkham.org>* twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> * linked-in: **http://lk.linkedin.com/in/afkhamazeez* * * *Lean . Enterprise . Middleware* * *
