axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: Supporting a services.xml for JAX-WS services
Date Sun, 23 Jan 2011 15:01:08 GMT
On Tue, Jan 18, 2011 at 19:14, Afkham Azeez <afkham@gmail.com> wrote:
>
>
> 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.
>
>>
>> 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?

In the following post, I identified a couple of advantages:

http://markmail.org/message/jz5bpoybvylbzb6q

Since supporting JAX-WS services in AAR files implies more work,
probably the "return on investment" is roughly the same. I would say
that if we have a volunteer to implement option B, but nobody willing
to do the additional work for option A, then I see no objection to go
for B, unless someone comes up with additional arguments that show
that option A is the only viable one.

>>
>> 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
>> > 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 <isurues@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 <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 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
>> >> >> <isurues@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: 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
>
>

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


Mime
View raw message