You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Deepal jayasinghe <de...@gmail.com> on 2008/05/27 13:12:24 UTC
[Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Hi All,
As I know jaxws is not considered as a core component , so I can not
understand why we have added that to axis2.xml in the kernel module.
With this change we can not start axis2 without having jaxws around. So
I think we need to remove that from the kernel axis2.xml.
Thank you!
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by Jeff Barrett <ba...@us.ibm.com>.
Hi All,
I've got a couple of questions about this approach.
1) Are there any semantic differences between an Axis2 handler plugged
into specific phases at specific points and a MAR? For example, the
current JAXWS dispatchers have to plug in so that all the operation
resolution has been attempted but before the Dispatch checkPostConditions
so that a spec-compliant exception is thrown. Can that sort of behavior
be accomplished with a MAR?
2) JAXWS requires the JAXWSMessageReciever class. Can a MAR provide a
MessageReciever? If not, then at least some of the JAXWS classes can't be
dealt with as a MAR.
Thanks,
Jeff
IBM Software Group - WebSphere Web Services Development
Phone: 512-838-4587 or Tie Line 678-4587
Internet e-mail and Sametime ID: barrettj@us.ibm.com
From:
Deepal Jayasinghe <de...@opensource.lk>
To:
axis-dev@ws.apache.org
Date:
05/28/2008 11:33 PM
Subject:
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
> Paul,
> I still think we could use the JAXWSDeployer to automatically deploy a
> jax-ws module (an in-memory constructed one rather than needing a
> separate .mar) when JAX-WS services are found.
Yes , I also think that as the right approach
Thank you!
Deepal
---------------------------------------------------------------------
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
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by Deepal Jayasinghe <de...@opensource.lk>.
> Paul,
> I still think we could use the JAXWSDeployer to automatically deploy a
> jax-ws module (an in-memory constructed one rather than needing a
> separate .mar) when JAX-WS services are found.
Yes , I also think that as the right approach
Thank you!
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by Paul Fremantle <pz...@gmail.com>.
David,
I agree 100%. I think thats a great solution. Maybe I misunderstood
Deepal's proposal. I simply want to ensure:
1) we can pass the TCK
2) Its dead simple to use JAXWS.
Paul
On Wed, May 28, 2008 at 6:44 PM, David Illsley <da...@gmail.com> wrote:
> Paul,
> I still think we could use the JAXWSDeployer to automatically deploy a
> jax-ws module (an in-memory constructed one rather than needing a
> separate .mar) when JAX-WS services are found. Unfortunately I don't
> have time to work on it right now.... anyone else? If this is a good
> approach I could raise a JIRA so we pick it up before the next
> release?
>
> David
>
> On Wed, May 28, 2008 at 4:41 PM, Paul Fremantle <pz...@gmail.com> wrote:
>> Deepal
>>
>> I don't think your scenario with a JAXWS module solves the TCK
>> problem. The TCK clearly states (as Dims pointed out) that the code
>> must work "out of the box" with no additional configuration. I also
>> want this, irrespective of the TCK rules. The fact is that we are
>> making it complex to use JAXWS when all the alternative toolkits make
>> it as easy as possible.
>>
>> I don't really understand your motivation here.
>>
>> Paul
>>
>> On Wed, May 28, 2008 at 5:21 AM, Deepal Jayasinghe <de...@opensource.lk> wrote:
>>>
>>>> Hi Deepal, Paul:
>>>>
>>>> Deepal Jayasinghe wrote:
>>>>>>
>>>>>> Is there a way of making it more dynamic? If its there it works, if
>>>>>> not then its still ok?
>>>>>>
>>>>>
>>>>> But now we get Class not found exception , if we try to use Axis2
>>>>> without having jaxws around :)
>>>>
>>>> Paul was asking if there's a way *around* that kind of problem, Deepal...
>>>> and I think there is.
>>>>
>>>> For much of our configuration, components (handlers in particular) are
>>>> non-optional - failing to find a configured class means a fatal error. We
>>>> could pretty easily change that to allow for optional components in several
>>>> ways:
>>>>
>>>> * We could leave everything as-is and create an "OptionalDispatcher" which
>>>> uses reflection to load a target class. It's a noop if it can't find the
>>>> target class, and it delegates if it can.
>>>
>>> I can not agree here. then we are making some assumptions on unwanted thing.
>>>>
>>>> <handler name="GenericProviderDispatcher"
>>>> class="org.apache.axis2.dispatchers.Optional">
>>>> <parameter name="targetClass">
>>>> [...]dispatchers.GenericProviderDispatcher
>>>> </parameter>
>>>> </handler>
>>>>
>>>> * We could add an "optional" flag to our handler configuration which would
>>>> allow trapping ClassNotFoundExceptions and simply skipping the handler if
>>>> one is thrown.
>>>
>>> Well , what we are discussing here is some major changes. But we can easily
>>> solve this problem by having jaxws module with those handlers (I mean a mar
>>> file). If we do so we can remove those handlers from axis2.xml and move
>>> them to jaxws.mar so if someone want jaxws support then what he has to do is
>>> - first drop all the jaxws related jar into class path
>>> - second engage jaxws module.
>>>
>>> Thank you!
>>> Deepal
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Paul Fremantle
>> Co-Founder and CTO, WSO2
>> Apache Synapse PMC Chair
>> OASIS WS-RX TC Co-chair
>>
>> blog: http://pzf.fremantle.org
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by David Illsley <da...@gmail.com>.
Paul,
I still think we could use the JAXWSDeployer to automatically deploy a
jax-ws module (an in-memory constructed one rather than needing a
separate .mar) when JAX-WS services are found. Unfortunately I don't
have time to work on it right now.... anyone else? If this is a good
approach I could raise a JIRA so we pick it up before the next
release?
David
On Wed, May 28, 2008 at 4:41 PM, Paul Fremantle <pz...@gmail.com> wrote:
> Deepal
>
> I don't think your scenario with a JAXWS module solves the TCK
> problem. The TCK clearly states (as Dims pointed out) that the code
> must work "out of the box" with no additional configuration. I also
> want this, irrespective of the TCK rules. The fact is that we are
> making it complex to use JAXWS when all the alternative toolkits make
> it as easy as possible.
>
> I don't really understand your motivation here.
>
> Paul
>
> On Wed, May 28, 2008 at 5:21 AM, Deepal Jayasinghe <de...@opensource.lk> wrote:
>>
>>> Hi Deepal, Paul:
>>>
>>> Deepal Jayasinghe wrote:
>>>>>
>>>>> Is there a way of making it more dynamic? If its there it works, if
>>>>> not then its still ok?
>>>>>
>>>>
>>>> But now we get Class not found exception , if we try to use Axis2
>>>> without having jaxws around :)
>>>
>>> Paul was asking if there's a way *around* that kind of problem, Deepal...
>>> and I think there is.
>>>
>>> For much of our configuration, components (handlers in particular) are
>>> non-optional - failing to find a configured class means a fatal error. We
>>> could pretty easily change that to allow for optional components in several
>>> ways:
>>>
>>> * We could leave everything as-is and create an "OptionalDispatcher" which
>>> uses reflection to load a target class. It's a noop if it can't find the
>>> target class, and it delegates if it can.
>>
>> I can not agree here. then we are making some assumptions on unwanted thing.
>>>
>>> <handler name="GenericProviderDispatcher"
>>> class="org.apache.axis2.dispatchers.Optional">
>>> <parameter name="targetClass">
>>> [...]dispatchers.GenericProviderDispatcher
>>> </parameter>
>>> </handler>
>>>
>>> * We could add an "optional" flag to our handler configuration which would
>>> allow trapping ClassNotFoundExceptions and simply skipping the handler if
>>> one is thrown.
>>
>> Well , what we are discussing here is some major changes. But we can easily
>> solve this problem by having jaxws module with those handlers (I mean a mar
>> file). If we do so we can remove those handlers from axis2.xml and move
>> them to jaxws.mar so if someone want jaxws support then what he has to do is
>> - first drop all the jaxws related jar into class path
>> - second engage jaxws module.
>>
>> Thank you!
>> Deepal
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> 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
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by Paul Fremantle <pz...@gmail.com>.
Deepal
I don't think your scenario with a JAXWS module solves the TCK
problem. The TCK clearly states (as Dims pointed out) that the code
must work "out of the box" with no additional configuration. I also
want this, irrespective of the TCK rules. The fact is that we are
making it complex to use JAXWS when all the alternative toolkits make
it as easy as possible.
I don't really understand your motivation here.
Paul
On Wed, May 28, 2008 at 5:21 AM, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
>> Hi Deepal, Paul:
>>
>> Deepal Jayasinghe wrote:
>>>>
>>>> Is there a way of making it more dynamic? If its there it works, if
>>>> not then its still ok?
>>>>
>>>
>>> But now we get Class not found exception , if we try to use Axis2
>>> without having jaxws around :)
>>
>> Paul was asking if there's a way *around* that kind of problem, Deepal...
>> and I think there is.
>>
>> For much of our configuration, components (handlers in particular) are
>> non-optional - failing to find a configured class means a fatal error. We
>> could pretty easily change that to allow for optional components in several
>> ways:
>>
>> * We could leave everything as-is and create an "OptionalDispatcher" which
>> uses reflection to load a target class. It's a noop if it can't find the
>> target class, and it delegates if it can.
>
> I can not agree here. then we are making some assumptions on unwanted thing.
>>
>> <handler name="GenericProviderDispatcher"
>> class="org.apache.axis2.dispatchers.Optional">
>> <parameter name="targetClass">
>> [...]dispatchers.GenericProviderDispatcher
>> </parameter>
>> </handler>
>>
>> * We could add an "optional" flag to our handler configuration which would
>> allow trapping ClassNotFoundExceptions and simply skipping the handler if
>> one is thrown.
>
> Well , what we are discussing here is some major changes. But we can easily
> solve this problem by having jaxws module with those handlers (I mean a mar
> file). If we do so we can remove those handlers from axis2.xml and move
> them to jaxws.mar so if someone want jaxws support then what he has to do is
> - first drop all the jaxws related jar into class path
> - second engage jaxws module.
>
> Thank you!
> Deepal
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by Deepal Jayasinghe <de...@opensource.lk>.
> Hi Deepal, Paul:
>
> Deepal Jayasinghe wrote:
>>> Is there a way of making it more dynamic? If its there it works, if
>>> not then its still ok?
>>>
>> But now we get Class not found exception , if we try to use Axis2
>> without having jaxws around :)
>
> Paul was asking if there's a way *around* that kind of problem,
> Deepal... and I think there is.
>
> For much of our configuration, components (handlers in particular) are
> non-optional - failing to find a configured class means a fatal error.
> We could pretty easily change that to allow for optional components in
> several ways:
>
> * We could leave everything as-is and create an "OptionalDispatcher"
> which uses reflection to load a target class. It's a noop if it can't
> find the target class, and it delegates if it can.
I can not agree here. then we are making some assumptions on unwanted
thing.
> <handler name="GenericProviderDispatcher"
> class="org.apache.axis2.dispatchers.Optional">
> <parameter name="targetClass">
> [...]dispatchers.GenericProviderDispatcher
> </parameter>
> </handler>
>
> * We could add an "optional" flag to our handler configuration which
> would allow trapping ClassNotFoundExceptions and simply skipping the
> handler if one is thrown.
Well , what we are discussing here is some major changes. But we can
easily solve this problem by having jaxws module with those handlers (I
mean a mar file). If we do so we can remove those handlers from
axis2.xml and move them to jaxws.mar so if someone want jaxws support
then what he has to do is
- first drop all the jaxws related jar into class path
- second engage jaxws module.
Thank you!
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by Glen Daniels <gl...@thoughtcraft.com>.
David Illsley wrote:
> Could we get the JAXWSDeployer to engage a 'by-default-unengaged'
> module if JAX-WS services are found?
Yep - the deployer has access to the AxisConfiguration, so that should
work fine. Be good to test it out though, of course.
--Glen
> David
>
> On Tue, May 27, 2008 at 3:45 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>> Hi Deepal, Paul:
>>
>> Deepal Jayasinghe wrote:
>>>> Is there a way of making it more dynamic? If its there it works, if
>>>> not then its still ok?
>>>>
>>> But now we get Class not found exception , if we try to use Axis2 without
>>> having jaxws around :)
>> Paul was asking if there's a way *around* that kind of problem, Deepal...
>> and I think there is.
>>
>> For much of our configuration, components (handlers in particular) are
>> non-optional - failing to find a configured class means a fatal error. We
>> could pretty easily change that to allow for optional components in several
>> ways:
>>
>> * We could leave everything as-is and create an "OptionalDispatcher" which
>> uses reflection to load a target class. It's a noop if it can't find the
>> target class, and it delegates if it can.
>> <handler name="GenericProviderDispatcher"
>> class="org.apache.axis2.dispatchers.Optional">
>> <parameter name="targetClass">
>> [...]dispatchers.GenericProviderDispatcher
>> </parameter>
>> </handler>
>>
>> * We could add an "optional" flag to our handler configuration which would
>> allow trapping ClassNotFoundExceptions and simply skipping the handler if
>> one is thrown.
>>
>> * We could put the JAXWS dispatchers into a "jaxws.mar" and have that
>> available on the default classpath. Then you run into the same issue with
>> optional module engagement, but I think that's a good thing to solve too...
>> <module ref="jaxws" optional="true"/>
>>
>> Thoughts?
>>
>> --Glen
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by David Illsley <da...@gmail.com>.
Could we get the JAXWSDeployer to engage a 'by-default-unengaged'
module if JAX-WS services are found?
David
On Tue, May 27, 2008 at 3:45 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Deepal, Paul:
>
> Deepal Jayasinghe wrote:
>>>
>>> Is there a way of making it more dynamic? If its there it works, if
>>> not then its still ok?
>>>
>>
>> But now we get Class not found exception , if we try to use Axis2 without
>> having jaxws around :)
>
> Paul was asking if there's a way *around* that kind of problem, Deepal...
> and I think there is.
>
> For much of our configuration, components (handlers in particular) are
> non-optional - failing to find a configured class means a fatal error. We
> could pretty easily change that to allow for optional components in several
> ways:
>
> * We could leave everything as-is and create an "OptionalDispatcher" which
> uses reflection to load a target class. It's a noop if it can't find the
> target class, and it delegates if it can.
> <handler name="GenericProviderDispatcher"
> class="org.apache.axis2.dispatchers.Optional">
> <parameter name="targetClass">
> [...]dispatchers.GenericProviderDispatcher
> </parameter>
> </handler>
>
> * We could add an "optional" flag to our handler configuration which would
> allow trapping ClassNotFoundExceptions and simply skipping the handler if
> one is thrown.
>
> * We could put the JAXWS dispatchers into a "jaxws.mar" and have that
> available on the default classpath. Then you run into the same issue with
> optional module engagement, but I think that's a good thing to solve too...
> <module ref="jaxws" optional="true"/>
>
> Thoughts?
>
> --Glen
>
> ---------------------------------------------------------------------
> 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
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Deepal, Paul:
Deepal Jayasinghe wrote:
>> Is there a way of making it more dynamic? If its there it works, if
>> not then its still ok?
>>
> But now we get Class not found exception , if we try to use Axis2
> without having jaxws around :)
Paul was asking if there's a way *around* that kind of problem,
Deepal... and I think there is.
For much of our configuration, components (handlers in particular) are
non-optional - failing to find a configured class means a fatal error.
We could pretty easily change that to allow for optional components in
several ways:
* We could leave everything as-is and create an "OptionalDispatcher"
which uses reflection to load a target class. It's a noop if it can't
find the target class, and it delegates if it can.
<handler name="GenericProviderDispatcher"
class="org.apache.axis2.dispatchers.Optional">
<parameter name="targetClass">
[...]dispatchers.GenericProviderDispatcher
</parameter>
</handler>
* We could add an "optional" flag to our handler configuration which
would allow trapping ClassNotFoundExceptions and simply skipping the
handler if one is thrown.
* We could put the JAXWS dispatchers into a "jaxws.mar" and have that
available on the default classpath. Then you run into the same issue
with optional module engagement, but I think that's a good thing to
solve too...
<module ref="jaxws" optional="true"/>
Thoughts?
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by Deepal Jayasinghe <de...@opensource.lk>.
> Is there a way of making it more dynamic? If its there it works, if
> not then its still ok?
>
But now we get Class not found exception , if we try to use Axis2
without having jaxws around :)
-Deepal
> Paul
>
> On Tue, May 27, 2008 at 12:19 PM, Deepal Jayasinghe
> <de...@opensource.lk> wrote:
>
>>> Deepal
>>>
>>> If we make the change you propose, does this mean that a user *has* to
>>> edit axis2.xml in order to enable JAXWS support?
>>>
>>>
>> Yes, but that is good rather than having a dependency to jaxws (even for
>> very small thing). As one solution we can have some other axis2.xml in the
>> jaxws module.
>>
>> Thank you!
>> Deepal
>>
>>> Paul
>>>
>>> On Tue, May 27, 2008 at 12:12 PM, Deepal jayasinghe <de...@gmail.com>
>>> wrote:
>>>
>>>
>>>> Hi All,
>>>>
>>>> As I know jaxws is not considered as a core component , so I can not
>>>> understand why we have added that to axis2.xml in the kernel module. With
>>>> this change we can not start axis2 without having jaxws around. So I
>>>> think
>>>> we need to remove that from the kernel axis2.xml.
>>>>
>>>> Thank you!
>>>> Deepal
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by Paul Fremantle <pz...@gmail.com>.
Is there a way of making it more dynamic? If its there it works, if
not then its still ok?
Paul
On Tue, May 27, 2008 at 12:19 PM, Deepal Jayasinghe
<de...@opensource.lk> wrote:
>
>> Deepal
>>
>> If we make the change you propose, does this mean that a user *has* to
>> edit axis2.xml in order to enable JAXWS support?
>>
>
> Yes, but that is good rather than having a dependency to jaxws (even for
> very small thing). As one solution we can have some other axis2.xml in the
> jaxws module.
>
> Thank you!
> Deepal
>>
>> Paul
>>
>> On Tue, May 27, 2008 at 12:12 PM, Deepal jayasinghe <de...@gmail.com>
>> wrote:
>>
>>>
>>> Hi All,
>>>
>>> As I know jaxws is not considered as a core component , so I can not
>>> understand why we have added that to axis2.xml in the kernel module. With
>>> this change we can not start axis2 without having jaxws around. So I
>>> think
>>> we need to remove that from the kernel axis2.xml.
>>>
>>> Thank you!
>>> Deepal
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by Deepal Jayasinghe <de...@opensource.lk>.
> Deepal
>
> If we make the change you propose, does this mean that a user *has* to
> edit axis2.xml in order to enable JAXWS support?
>
Yes, but that is good rather than having a dependency to jaxws (even for
very small thing). As one solution we can have some other axis2.xml in
the jaxws module.
Thank you!
Deepal
> Paul
>
> On Tue, May 27, 2008 at 12:12 PM, Deepal jayasinghe <de...@gmail.com> wrote:
>
>> Hi All,
>>
>> As I know jaxws is not considered as a core component , so I can not
>> understand why we have added that to axis2.xml in the kernel module. With
>> this change we can not start axis2 without having jaxws around. So I think
>> we need to remove that from the kernel axis2.xml.
>>
>> Thank you!
>> Deepal
>>
>> ---------------------------------------------------------------------
>> 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
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by Paul Fremantle <pz...@gmail.com>.
Deepal
If we make the change you propose, does this mean that a user *has* to
edit axis2.xml in order to enable JAXWS support?
Paul
On Tue, May 27, 2008 at 12:12 PM, Deepal jayasinghe <de...@gmail.com> wrote:
> Hi All,
>
> As I know jaxws is not considered as a core component , so I can not
> understand why we have added that to axis2.xml in the kernel module. With
> this change we can not start axis2 without having jaxws around. So I think
> we need to remove that from the kernel axis2.xml.
>
> Thank you!
> Deepal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by Davanum Srinivas <da...@gmail.com>.
Short-Term: Let's fix the code to log a warning as we have done for
the rest of the components.
Long-Term: Do we want Axis2 users to use the axis2 war as-is and
deploy their JAXWS code? (Please put yourselves in their shoes).
thanks,
dims
On Tue, May 27, 2008 at 8:16 AM, Jeff Barrett <ba...@us.ibm.com> wrote:
> I believe both those are needed to pass JAXWS CTS. At one time in order
> to claim CTS compliance the TCK had to be run against the system with no
> further configuration (other than installing the applications). I don't
> know if that is still a requirement or a concern for Axis2.
>
> Thanks,
> Jeff
>
> IBM Software Group - WebSphere Web Services Development
> Phone: 512-838-4587 or Tie Line 678-4587
> Internet e-mail and Sametime ID: barrettj@us.ibm.com
>
>
>
> From:
> Deepal Jayasinghe <de...@opensource.lk>
> To:
> axis-dev@ws.apache.org
> Date:
> 05/27/2008 06:18 AM
> Subject:
> Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
>
>
>
> I forgot to mentioned the two in the kernel axis2.xml , do we really
> need to have them here ?
>
> <handler name="GenericProviderDispatcher"
>
> class="org.apache.axis2.jaxws.dispatchers.GenericProviderDispatcher"/>
> <handler name="MustUnderstandValidationDispatcher"
>
> class="org.apache.axis2.jaxws.dispatchers.MustUnderstandValidationDispatcher"/>
>
> Thank you!
> Deepal
>> Hi All,
>>
>> As I know jaxws is not considered as a core component , so I can not
>> understand why we have added that to axis2.xml in the kernel module.
>> With this change we can not start axis2 without having jaxws around.
>> So I think we need to remove that from the kernel axis2.xml.
>>
>> Thank you!
>> Deepal
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>>
>
> --
> Thanks,
> Deepal
> ................................................................
> "The highest tower is built one brick at a time"
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by Jeff Barrett <ba...@us.ibm.com>.
I believe both those are needed to pass JAXWS CTS. At one time in order
to claim CTS compliance the TCK had to be run against the system with no
further configuration (other than installing the applications). I don't
know if that is still a requirement or a concern for Axis2.
Thanks,
Jeff
IBM Software Group - WebSphere Web Services Development
Phone: 512-838-4587 or Tie Line 678-4587
Internet e-mail and Sametime ID: barrettj@us.ibm.com
From:
Deepal Jayasinghe <de...@opensource.lk>
To:
axis-dev@ws.apache.org
Date:
05/27/2008 06:18 AM
Subject:
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
I forgot to mentioned the two in the kernel axis2.xml , do we really
need to have them here ?
<handler name="GenericProviderDispatcher"
class="org.apache.axis2.jaxws.dispatchers.GenericProviderDispatcher"/>
<handler name="MustUnderstandValidationDispatcher"
class="org.apache.axis2.jaxws.dispatchers.MustUnderstandValidationDispatcher"/>
Thank you!
Deepal
> Hi All,
>
> As I know jaxws is not considered as a core component , so I can not
> understand why we have added that to axis2.xml in the kernel module.
> With this change we can not start axis2 without having jaxws around.
> So I think we need to remove that from the kernel axis2.xml.
>
> Thank you!
> Deepal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
--
Thanks,
Deepal
................................................................
"The highest tower is built one brick at a time"
---------------------------------------------------------------------
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
Re: [Axis2] why GenericProviderDispatcher in the kernel axis2.xml
Posted by Deepal Jayasinghe <de...@opensource.lk>.
I forgot to mentioned the two in the kernel axis2.xml , do we really
need to have them here ?
<handler name="GenericProviderDispatcher"
class="org.apache.axis2.jaxws.dispatchers.GenericProviderDispatcher"/>
<handler name="MustUnderstandValidationDispatcher"
class="org.apache.axis2.jaxws.dispatchers.MustUnderstandValidationDispatcher"/>
Thank you!
Deepal
> Hi All,
>
> As I know jaxws is not considered as a core component , so I can not
> understand why we have added that to axis2.xml in the kernel module.
> With this change we can not start axis2 without having jaxws around.
> So I think we need to remove that from the kernel axis2.xml.
>
> Thank you!
> Deepal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
--
Thanks,
Deepal
................................................................
"The highest tower is built one brick at a time"
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org