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. > What I realized is adding an extension point to ServiceDeployer will enable to use other existing deployers together with JAX-WS. AFAIK JAX-WS is a programing model and each vendor provides own deployment approach - e.g. -[1] , I think we should not couple JAX -WS into any specific deployer. +1 for adding extension point to ServiceDeployer so that it will inject JAX-WS meta data regardless of deployment strategy. Also I think this is a good point to define clear API for ServiceDeployer extension. [1] - http://metro.java.net/guide/Deploying_Metro_endpoint.html Thanks ! > 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 > > -- Sagara Gunathunga Blog - http://ssagara.blogspot.com Web - http://people.apache.org/~sagara/
