Return-Path: Delivered-To: apmail-axis-java-dev-archive@www.apache.org Received: (qmail 62138 invoked from network); 18 Jan 2011 18:15:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 18 Jan 2011 18:15:28 -0000 Received: (qmail 8376 invoked by uid 500); 18 Jan 2011 18:15:28 -0000 Delivered-To: apmail-axis-java-dev-archive@axis.apache.org Received: (qmail 7639 invoked by uid 500); 18 Jan 2011 18:15:25 -0000 Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@axis.apache.org Delivered-To: mailing list java-dev@axis.apache.org Received: (qmail 7622 invoked by uid 99); 18 Jan 2011 18:15:24 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Jan 2011 18:15:24 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of afkham@gmail.com designates 209.85.214.173 as permitted sender) Received: from [209.85.214.173] (HELO mail-iw0-f173.google.com) (209.85.214.173) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Jan 2011 18:15:14 +0000 Received: by iwn40 with SMTP id 40so6749650iwn.32 for ; Tue, 18 Jan 2011 10:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=T9BPJxJiyo186Dro0VbouDFsUQVxLo+C4hU0YO6VtXw=; b=vgOPPyQQ6iWCaiFbbrFB09Ugb4L3ScBjCPuzOh5IF2NmCBzodgd2tn3fsfd21EKw8u QYNDHLPygOZEw22uXQ7hMuAwRSwouFiC329P0RVGUeY+Y88+cDogMnPKv4vvGVlGA7PZ QbSOslDU1OIO2HAAMEuLaUWLm6F6xtk9eCjEM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=S86d2kfYXgkAqxP3L7ox7Jvb2BZZ5r6QWYDIuX8BFZw+ppZt1/VsAn+49Y6vu0QBuc +A8YIFv8nSm90Y42UTTRpGRf+ocWp9Z+U54B9Y5x+Y+WeEZMYAxX48j/eisQz4vxdDWL T1qVbNt/Vf5teIt9AMjwxApqsCQpCVuh5fVmM= Received: by 10.231.12.131 with SMTP id x3mr6417100ibx.76.1295374492696; Tue, 18 Jan 2011 10:14:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.16.133 with HTTP; Tue, 18 Jan 2011 10:14:32 -0800 (PST) In-Reply-To: References: From: Afkham Azeez Date: Tue, 18 Jan 2011 23:44:32 +0530 Message-ID: Subject: Re: Supporting a services.xml for JAX-WS services To: java-dev@axis.apache.org Content-Type: multipart/alternative; boundary=000325574f267d076d049a22e050 X-Virus-Checked: Checked by ClamAV on apache.org --000325574f267d076d049a22e050 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 18, 2011 at 5:28 PM, Andreas Veithen 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 > 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.veithen@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 > >> 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 > 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 > >> >> > >> >> 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: azeez@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-unsubscribe@axis.apache.org > >> For additional commands, e-mail: java-dev-help@axis.apache.org > >> > > > > > > > > -- > > Technical Lead, > > WSO2 Inc. http://wso2.org/ > > Blog : http://isurues.wordpress.com/ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org > For additional commands, e-mail: java-dev-help@axis.apache.org > > -- *Afkham Azeez* Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com, * * *Member; Apache Software Foundation; **http://www.apache.org/* * email: **azeez@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* * * --000325574f267d076d049a22e050 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jan 18, 2011 at 5:28 PM, Andreas= Veithen <andreas.veithen@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.
=A0
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 wit= hin the JAXWS jar file, and deploy it in the servicejars directory? What is= the purpose or advantage of deploying JAXWS services as AAR files?
=A0

Andreas

On Tue, Jan 18, 2011 at 12:43, Isuru Suriarachchi <isurues@gmail.com> wrote:
> Hi Andreas,
>
> I think what Azeez proposes is different from B as well. Because, it w= on't
> be a JAX-WS specific thing. If we want to support a services.xml for a= ny of
> the service types, we should be able to use the same API to do that af= ter
> the AxisService object is created. That code will basically read the > services.xml and use the parameters to change the behaviour of the alr= eady
> created service.
>
> Thanks,
> ~Isuru
>
> On Tue, Jan 18, 2011 at 4:18 PM, Andreas Veithen <andreas.veithen@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 JA= X-WS
>> can plug itself into the service deployer.
>>
>> B) Introduce a separate deployer specifically for JAX-WS services<= br> >> bundled with a services.xml file.
>>
>> Option A has a couple of advantages [1] and the solution originall= y
>> proposed by me was based on that option (although my PoC uses opti= on
>> 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, w= hat
>> is a good option for Data Services is not necessarily the right op= tion
>> for JAX-WS services.
>>
>> Andreas
>>
>> [1] http://markmail.org/message/jz5bpoybvylbzb6q
>>
>> On Tue, Jan 18, 2011 at 06:25, Isuru Suriarachchi <isurues@gmail.com>
>> wrote:
>> > +1. I'll investigate on this and try to come up with a pr= oper solution.
>> >
>> > Thanks,
>> > ~Isuru
>> >
>> > On Tue, Jan 18, 2011 at 10:24 AM, Afkham Azeez <afkham@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 p= ost Axis
>> >> service
>> >> creation in the deployment phase, where the AxisService o= bject created
>> >> by
>> >> the deployer is updated based on an associated services.x= ml 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 th= e 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 bette= r to have a
>> >> unified
>> >> way of=A0doing=A0this instead of implementing it for each= and every
>> >> deployer
>> >> separately.
>> >> Azeez
>> >>
>> >> On Mon, Jan 17, 2011 at 10:52 PM, Isuru Suriarachchi
>> >> <isurues@gmail.co= m>
>> >> wrote:
>> >>>
>> >>> Hi all,
>> >>>
>> >>> Andreas has provided a very good explanation on why w= e 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 sess= ion management,
>> >>> he can
>> >>> insert a services.xml. And also, as Azeez has propose= d, we can provide
>> >>> a
>> >>> generic API using which a services.xml can be support= ed for any type
>> >>> of
>> >>> service.
>> >>>
>> >>> WDYT??
>> >>>
>> >>> Thanks,
>> >>> ~Isuru
>> >>>
>> >>> [1] https://issues.apache.org/jira/browse/AXIS2-4= 611
>> >>>
>> >>> --
>> >>> Technical Lead,
>> >>> WSO2 Inc. http://wso2.org/
>> >>> Blog : http://isurues.wordpress.com/
>> >>
>> >>
>> >>
>> >> --
>> >> Afkham Azeez
>> >> Senior Software Architect & Senior Manager;=A0WSO2, >> >> Inc.;=A0htt= p://wso2.com,
>> >>
>> >> Member; Apache Software Foundation;=A0http://www.apache.org/
>> >> email:=A0azeez@wso2.com= =A0cell: +94 77 3320919
>> >> blog:=A0http://blog.afkham.org
>> >> twitter:=A0http://twitter.com/afkham_azeez
>> >> linked-in:=A0http://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-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Technical Lead,
> WSO2 Inc. http://wso2.o= rg/
> Blog : htt= p://isurues.wordpress.com/
>

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




--
Afkham A= zeez
Senior Software Architect & Senior Manager;=A0WSO2, Inc.;=A0http://wso2.com,=A0


--000325574f267d076d049a22e050--