You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by dudae <du...@gmail.com> on 2014/11/11 14:17:12 UTC
[Proposal] WS-Transfer/WS-Fragment implementation
Hi,
I study at Masaryk university in Czech republic and I am working on diploma
thesis guided by Rostislav Svoboda from Red Hat. Theme of the work is
"Implement missing WS specification for Apache CXF framework". I have chosen
the WS-Transfer specification. The implementation is located on url
https://github.com/dudaerich/cxf/tree/master/rt/ws/transfer I have also
written a document, where I discuss implementation details of the extension
(https://developer.jboss.org/docs/DOC-52941?uniqueTitle=false). For testing
purpose I have created sample application, which demonstrates using of the
WS-Transfer (https://github.com/dudaerich/WS-TransferExample). On base of it
I have also created systest in cxf project, which tests various scenarios of
using the WS-Transfer
(https://github.com/dudaerich/cxf/tree/master/systests/ws-transfer).
After finishing the main part of WS-Transfer implementation, I have started
to implement the WS-Fragment specification, because in the specification of
the WS-Transfer it is written that the WS-Fragment must be supported. During
the implementation I encountered with problems, which I discuss in document
https://developer.jboss.org/docs/DOC-52941?uniqueTitle=false Except in a few
special cases, which must be discussed, the implementation is complete. In
tests I cover examples given in the specification, which proves correctness
of the implementation for these cases.
I would like to contribute my work to cxf project and in this way to get
feedback from you. The code is rebased with the latest cxf and it is
prepared for pull request.
Erich Duda
--
View this message in context: http://cxf.547215.n5.nabble.com/Proposal-WS-Transfer-WS-Fragment-implementation-tp5750975.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: [Proposal] WS-Transfer/WS-Fragment implementation
Posted by Erich Duda <du...@gmail.com>.
Hi,
do you have any more comments in this thing?
I would like to ask you if you know someone who participates in
WS-Fragment working group. I asked them for review the document
https://developer.jboss.org/docs/DOC-52941?uniqueTitle=false , in which
I discuss uncertainties in the specification of WS-Fragment. However
nobody responded to my email
(http://lists.w3.org/Archives/Public/public-ws-resource-access-comments/2015Feb/0000.html).
Could you push the email someone, who will know answer the questions,
which I ask in the document?
Thank you.
Erich
Dňa 19.02.2015 o 20:37 Erich Duda napísal(a):
> In SOAP headers it should be an element with name uuid, which has an
> attribute wsa:isReferenceParameter. This attribute declares that it is
> the ReferenceParameter. Do you see it there?
>
> Dňa 19.02.2015 o 20:10 Daniel Kulp [via CXF] napísal(a):
>>
>> > On Feb 18, 2015, at 1:12 PM, Erich Duda <[hidden email]
>> </user/SendEmail.jtp?type=node&node=5754490&i=0>> wrote:
>> >
>> > Hi,
>> > thank you for your comments. I fixed mentioned issues, see comments
>> bellow.
>> >
>> > Dňa 13.02.2015 o 21:23 Daniel Kulp napísal(a):
>> >>> On Feb 12, 2015, at 3:03 PM, dudae<[hidden email]
>> </user/SendEmail.jtp?type=node&node=5754490&i=1>> wrote:
>> >>> Do you check the implementation? Could you give me some feedback
>> please?
>> >>> Thank you.
>> >> Just took a quick look at this… I completely forgot about this.
>> >>
>> >> There are a couple of obvious things that “jump out” that are very
>> quick/easy to fix. Mostly removing the @author tags (highly
>> discouraged at Apache) and there are a few files that need the Apache
>> header added (the XML files). There are also several warnings when
>> pulled into Eclipse, but those aren’t big deals at all. The other
>> issue would be the use of the System.out for all the messages during
>> the tests causing a lot of output on the console. Again, easy fix
>> and I understand why it’s there during development.
>> >
>> > Should I fixed all PMD warnings? For example, "A method should have
>> only one exit point, and that should be the last statement in the
>> method". I think that more exit points (return statements) do some
>> methods more readable.
>>
>> No. The PMD that is run when you type “mvn” on the command line is
>> the important one. Ideally, they’d both be the same but the current
>> eclipse plugin has a bunch of issues. I have a few pull requests
>> open with the PMD folks that should get the eclipse pmd plugin to be
>> more usable for CXF.
>>
>>
>> >
>> >> The main thing that jumps out at me as being problematic is the
>> use of the JAX-WS handlers
>> (org.apache.cxf.ws.transfer.shared.handlers). Those cause problems
>> as we have to completely break streaming to build the SOAPMessage
>> that is passed into those. I’d very strongly encourage flipping
>> those to normal CXF SOAP interceptors. They seem to only operate on
>> SOAP headers so they can call the getHeaders method on the
>> SOAPMessage passed into the interceptor and pretty much allow the
>> body to remain as is. (likely streaming) That said, I’m not sure
>> those are even needed. CXF’s MAPCodec.java already gathers the
>> headers that have the ReferenceParameter attribute and adds them to
>> the “To” EndpointReference. You may need to experiment a bit more
>> to see if they are really getting through (and if not, figure out
>> why). Likewise, on the client, you could directly add them to the
>> client RequestContext via the normal way of adding headers:
>> >>
>> >>
>> http://cxf.apache.org/faq.html#FAQ-HowcanIaddsoapheaderstotherequest/response?
>>
>> >>
>> >> and avoid the JAX-WS handler/interceptor entirely.
>> >
>> > The ReferenceParameter is possible to send through the request
>> context. When I tried to send it through the standard headers, it
>> isn't getting through because MAPCodec removes all WS-Addressing
>> headers (see discardMAPs method).
>>
>> The discardMAPs method only discards headers that are in the
>> WS-Addressing namespace. It shouldn’t discard the elements that are
>> not in the ws-addressing namespace. If I add a
>> factory.getFeatures().add(new LoggingFeature()) to your code (or use
>> wireshark), I’m not seeing the reference params being written out at
>> all with the new code. That kind of bothers me as I believe they
>> should. Hmm…. Can you double check that the soap headers you are
>> expecting to be there are really there?
>>
>>
>> > Few more CXF things:
>> >> In XLSTResourceTransformer and TransferTools and a few other
>> places, you are creating DocumentBuilderFactory/DocumentBuilder and a
>> Transformer and such. You really should use the utility methods we
>> have in StaxUtils, XMLUtils, and XSLTUtils for much of that. We
>> try to make sure all the XML parsing and processing goes through
>> those utilities so that we can control various aspects to prevent
>> various attacks (like entity expansion attacks).
>> >
>> > I removed TransferTools. I use for
>> > - parsing, serializing XML - StaxUtils
>> > - creating elements - DOMUtils.createDocument().createElement
>> > - transforming - XSLTUtils
>> > - xpath - XPathUtils
>> >
>> > However in FragmentDialectLanguageXPath10 I don't use the
>> XPathUtils, because I need to recognize, when the XPath throw the
>> exception and when not. See https://www.java.net/node/681793
>>
>> OK. That works. Looks much better.
>>
>> I think if we just double check the reference params things, we’re
>> likely good to go with it.
>>
>> --
>> Daniel Kulp
>> [hidden email] </user/SendEmail.jtp?type=node&node=5754490&i=2> -
>> http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>>
>> ------------------------------------------------------------------------
>> If you reply to this email, your message will be added to the
>> discussion below:
>> http://cxf.547215.n5.nabble.com/Proposal-WS-Transfer-WS-Fragment-implementation-tp5750975p5754490.html
>>
>> To unsubscribe from [Proposal] WS-Transfer/WS-Fragment
>> implementation, click here
>> <http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5750975&code=ZHVkYWVyaWNoQGdtYWlsLmNvbXw1NzUwOTc1fC0xOTc5NzM2MTA0>.
>> NAML
>> <http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
> Erich
Re: [Proposal] WS-Transfer/WS-Fragment implementation
Posted by Erich Duda <du...@gmail.com>.
In SOAP headers it should be an element with name uuid, which has an
attribute wsa:isReferenceParameter. This attribute declares that it is
the ReferenceParameter. Do you see it there?
Dňa 19.02.2015 o 20:10 Daniel Kulp [via CXF] napísal(a):
>
> > On Feb 18, 2015, at 1:12 PM, Erich Duda <[hidden email]
> </user/SendEmail.jtp?type=node&node=5754490&i=0>> wrote:
> >
> > Hi,
> > thank you for your comments. I fixed mentioned issues, see comments
> bellow.
> >
> > Dňa 13.02.2015 o 21:23 Daniel Kulp napísal(a):
> >>> On Feb 12, 2015, at 3:03 PM, dudae<[hidden email]
> </user/SendEmail.jtp?type=node&node=5754490&i=1>> wrote:
> >>> Do you check the implementation? Could you give me some feedback
> please?
> >>> Thank you.
> >> Just took a quick look at this… I completely forgot about this.
> >>
> >> There are a couple of obvious things that “jump out” that are very
> quick/easy to fix. Mostly removing the @author tags (highly
> discouraged at Apache) and there are a few files that need the Apache
> header added (the XML files). There are also several warnings when
> pulled into Eclipse, but those aren’t big deals at all. The other
> issue would be the use of the System.out for all the messages during
> the tests causing a lot of output on the console. Again, easy fix
> and I understand why it’s there during development.
> >
> > Should I fixed all PMD warnings? For example, "A method should have
> only one exit point, and that should be the last statement in the
> method". I think that more exit points (return statements) do some
> methods more readable.
>
> No. The PMD that is run when you type “mvn” on the command line is
> the important one. Ideally, they’d both be the same but the current
> eclipse plugin has a bunch of issues. I have a few pull requests open
> with the PMD folks that should get the eclipse pmd plugin to be more
> usable for CXF.
>
>
> >
> >> The main thing that jumps out at me as being problematic is the use
> of the JAX-WS handlers (org.apache.cxf.ws.transfer.shared.handlers).
> Those cause problems as we have to completely break streaming to build
> the SOAPMessage that is passed into those. I’d very strongly
> encourage flipping those to normal CXF SOAP interceptors. They seem
> to only operate on SOAP headers so they can call the getHeaders method
> on the SOAPMessage passed into the interceptor and pretty much allow
> the body to remain as is. (likely streaming) That said, I’m not
> sure those are even needed. CXF’s MAPCodec.java already gathers the
> headers that have the ReferenceParameter attribute and adds them to
> the “To” EndpointReference. You may need to experiment a bit more to
> see if they are really getting through (and if not, figure out why).
> Likewise, on the client, you could directly add them to the client
> RequestContext via the normal way of adding headers:
> >>
> >>
> http://cxf.apache.org/faq.html#FAQ-HowcanIaddsoapheaderstotherequest/response?
>
> >>
> >> and avoid the JAX-WS handler/interceptor entirely.
> >
> > The ReferenceParameter is possible to send through the request
> context. When I tried to send it through the standard headers, it
> isn't getting through because MAPCodec removes all WS-Addressing
> headers (see discardMAPs method).
>
> The discardMAPs method only discards headers that are in the
> WS-Addressing namespace. It shouldn’t discard the elements that are
> not in the ws-addressing namespace. If I add a
> factory.getFeatures().add(new LoggingFeature()) to your code (or use
> wireshark), I’m not seeing the reference params being written out at
> all with the new code. That kind of bothers me as I believe they
> should. Hmm…. Can you double check that the soap headers you are
> expecting to be there are really there?
>
>
> > Few more CXF things:
> >> In XLSTResourceTransformer and TransferTools and a few other
> places, you are creating DocumentBuilderFactory/DocumentBuilder and a
> Transformer and such. You really should use the utility methods we
> have in StaxUtils, XMLUtils, and XSLTUtils for much of that. We try
> to make sure all the XML parsing and processing goes through those
> utilities so that we can control various aspects to prevent various
> attacks (like entity expansion attacks).
> >
> > I removed TransferTools. I use for
> > - parsing, serializing XML - StaxUtils
> > - creating elements - DOMUtils.createDocument().createElement
> > - transforming - XSLTUtils
> > - xpath - XPathUtils
> >
> > However in FragmentDialectLanguageXPath10 I don't use the
> XPathUtils, because I need to recognize, when the XPath throw the
> exception and when not. See https://www.java.net/node/681793
>
> OK. That works. Looks much better.
>
> I think if we just double check the reference params things, we’re
> likely good to go with it.
>
> --
> Daniel Kulp
> [hidden email] </user/SendEmail.jtp?type=node&node=5754490&i=2> -
> http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the
> discussion below:
> http://cxf.547215.n5.nabble.com/Proposal-WS-Transfer-WS-Fragment-implementation-tp5750975p5754490.html
>
> To unsubscribe from [Proposal] WS-Transfer/WS-Fragment implementation,
> click here
> <http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5750975&code=ZHVkYWVyaWNoQGdtYWlsLmNvbXw1NzUwOTc1fC0xOTc5NzM2MTA0>.
> NAML
> <http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
Erich
Re: [Proposal] WS-Transfer/WS-Fragment implementation
Posted by Daniel Kulp <dk...@apache.org>.
> On Feb 18, 2015, at 1:12 PM, Erich Duda <du...@gmail.com> wrote:
>
> Hi,
> thank you for your comments. I fixed mentioned issues, see comments bellow.
>
> Dňa 13.02.2015 o 21:23 Daniel Kulp napísal(a):
>>> On Feb 12, 2015, at 3:03 PM, dudae<du...@gmail.com> wrote:
>>> Do you check the implementation? Could you give me some feedback please?
>>> Thank you.
>> Just took a quick look at this… I completely forgot about this.
>>
>> There are a couple of obvious things that “jump out” that are very quick/easy to fix. Mostly removing the @author tags (highly discouraged at Apache) and there are a few files that need the Apache header added (the XML files). There are also several warnings when pulled into Eclipse, but those aren’t big deals at all. The other issue would be the use of the System.out for all the messages during the tests causing a lot of output on the console. Again, easy fix and I understand why it’s there during development.
>
> Should I fixed all PMD warnings? For example, "A method should have only one exit point, and that should be the last statement in the method". I think that more exit points (return statements) do some methods more readable.
No. The PMD that is run when you type “mvn” on the command line is the important one. Ideally, they’d both be the same but the current eclipse plugin has a bunch of issues. I have a few pull requests open with the PMD folks that should get the eclipse pmd plugin to be more usable for CXF.
>
>> The main thing that jumps out at me as being problematic is the use of the JAX-WS handlers (org.apache.cxf.ws.transfer.shared.handlers). Those cause problems as we have to completely break streaming to build the SOAPMessage that is passed into those. I’d very strongly encourage flipping those to normal CXF SOAP interceptors. They seem to only operate on SOAP headers so they can call the getHeaders method on the SOAPMessage passed into the interceptor and pretty much allow the body to remain as is. (likely streaming) That said, I’m not sure those are even needed. CXF’s MAPCodec.java already gathers the headers that have the ReferenceParameter attribute and adds them to the “To” EndpointReference. You may need to experiment a bit more to see if they are really getting through (and if not, figure out why). Likewise, on the client, you could directly add them to the client RequestContext via the normal way of adding headers:
>>
>> http://cxf.apache.org/faq.html#FAQ-HowcanIaddsoapheaderstotherequest/response?
>>
>> and avoid the JAX-WS handler/interceptor entirely.
>
> The ReferenceParameter is possible to send through the request context. When I tried to send it through the standard headers, it isn't getting through because MAPCodec removes all WS-Addressing headers (see discardMAPs method).
The discardMAPs method only discards headers that are in the WS-Addressing namespace. It shouldn’t discard the elements that are not in the ws-addressing namespace. If I add a factory.getFeatures().add(new LoggingFeature()) to your code (or use wireshark), I’m not seeing the reference params being written out at all with the new code. That kind of bothers me as I believe they should. Hmm…. Can you double check that the soap headers you are expecting to be there are really there?
> Few more CXF things:
>> In XLSTResourceTransformer and TransferTools and a few other places, you are creating DocumentBuilderFactory/DocumentBuilder and a Transformer and such. You really should use the utility methods we have in StaxUtils, XMLUtils, and XSLTUtils for much of that. We try to make sure all the XML parsing and processing goes through those utilities so that we can control various aspects to prevent various attacks (like entity expansion attacks).
>
> I removed TransferTools. I use for
> - parsing, serializing XML - StaxUtils
> - creating elements - DOMUtils.createDocument().createElement
> - transforming - XSLTUtils
> - xpath - XPathUtils
>
> However in FragmentDialectLanguageXPath10 I don't use the XPathUtils, because I need to recognize, when the XPath throw the exception and when not. See https://www.java.net/node/681793
OK. That works. Looks much better.
I think if we just double check the reference params things, we’re likely good to go with it.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [Proposal] WS-Transfer/WS-Fragment implementation
Posted by Erich Duda <du...@gmail.com>.
Hi,
thank you for your comments. I fixed mentioned issues, see comments bellow.
Dňa 13.02.2015 o 21:23 Daniel Kulp napísal(a):
>> On Feb 12, 2015, at 3:03 PM, dudae<du...@gmail.com> wrote:
>> Do you check the implementation? Could you give me some feedback please?
>> Thank you.
> Just took a quick look at this… I completely forgot about this.
>
> There are a couple of obvious things that “jump out” that are very quick/easy to fix. Mostly removing the @author tags (highly discouraged at Apache) and there are a few files that need the Apache header added (the XML files). There are also several warnings when pulled into Eclipse, but those aren’t big deals at all. The other issue would be the use of the System.out for all the messages during the tests causing a lot of output on the console. Again, easy fix and I understand why it’s there during development.
Should I fixed all PMD warnings? For example, "A method should have only
one exit point, and that should be the last statement in the method". I
think that more exit points (return statements) do some methods more
readable.
> The main thing that jumps out at me as being problematic is the use of the JAX-WS handlers (org.apache.cxf.ws.transfer.shared.handlers). Those cause problems as we have to completely break streaming to build the SOAPMessage that is passed into those. I’d very strongly encourage flipping those to normal CXF SOAP interceptors. They seem to only operate on SOAP headers so they can call the getHeaders method on the SOAPMessage passed into the interceptor and pretty much allow the body to remain as is. (likely streaming) That said, I’m not sure those are even needed. CXF’s MAPCodec.java already gathers the headers that have the ReferenceParameter attribute and adds them to the “To” EndpointReference. You may need to experiment a bit more to see if they are really getting through (and if not, figure out why). Likewise, on the client, you could directly add them to the client RequestContext via the normal way of adding headers:
>
> http://cxf.apache.org/faq.html#FAQ-HowcanIaddsoapheaderstotherequest/response?
>
> and avoid the JAX-WS handler/interceptor entirely.
The ReferenceParameter is possible to send through the request context.
When I tried to send it through the standard headers, it isn't getting
through because MAPCodec removes all WS-Addressing headers (see
discardMAPs method).
Solution. Client side:
AddressingProperties addrProps = new AddressingProperties();
EndpointReferenceType endpoint = new EndpointReferenceType();
endpoint.setReferenceParameters(refParams);
endpoint.setAddress(ContextUtils.getAttributedURI(RESOURCE_ADDRESS));
addrProps.setTo(endpoint);
((BindingProvider)
proxy).getRequestContext().put(JAXWSAConstants.CLIENT_ADDRESSING_PROPERTIES,
addrProps);
Server side:
AddressingProperties addrProps = (AddressingProperties)
((WrappedMessageContext) context
.getMessageContext()).getWrappedMessage()
.getContextualProperty(JAXWSAConstants.ADDRESSING_PROPERTIES_INBOUND);
ReferenceParametersType refParams =
addrProps.getToEndpointReference().getReferenceParameters();
> Few more CXF things:
> In XLSTResourceTransformer and TransferTools and a few other places, you are creating DocumentBuilderFactory/DocumentBuilder and a Transformer and such. You really should use the utility methods we have in StaxUtils, XMLUtils, and XSLTUtils for much of that. We try to make sure all the XML parsing and processing goes through those utilities so that we can control various aspects to prevent various attacks (like entity expansion attacks).
I removed TransferTools. I use for
- parsing, serializing XML - StaxUtils
- creating elements - DOMUtils.createDocument().createElement
- transforming - XSLTUtils
- xpath - XPathUtils
However in FragmentDialectLanguageXPath10 I don't use the XPathUtils,
because I need to recognize, when the XPath throw the exception and when
not. See https://www.java.net/node/681793
> Other than that, it looks fairly good. I hope the above gives you some stuff to think about.
>
Erich
Re: [Proposal] WS-Transfer/WS-Fragment implementation
Posted by Daniel Kulp <dk...@apache.org>.
> On Feb 12, 2015, at 3:03 PM, dudae <du...@gmail.com> wrote:
> Do you check the implementation? Could you give me some feedback please?
> Thank you.
Just took a quick look at this… I completely forgot about this.
There are a couple of obvious things that “jump out” that are very quick/easy to fix. Mostly removing the @author tags (highly discouraged at Apache) and there are a few files that need the Apache header added (the XML files). There are also several warnings when pulled into Eclipse, but those aren’t big deals at all. The other issue would be the use of the System.out for all the messages during the tests causing a lot of output on the console. Again, easy fix and I understand why it’s there during development.
The main thing that jumps out at me as being problematic is the use of the JAX-WS handlers (org.apache.cxf.ws.transfer.shared.handlers). Those cause problems as we have to completely break streaming to build the SOAPMessage that is passed into those. I’d very strongly encourage flipping those to normal CXF SOAP interceptors. They seem to only operate on SOAP headers so they can call the getHeaders method on the SOAPMessage passed into the interceptor and pretty much allow the body to remain as is. (likely streaming) That said, I’m not sure those are even needed. CXF’s MAPCodec.java already gathers the headers that have the ReferenceParameter attribute and adds them to the “To” EndpointReference. You may need to experiment a bit more to see if they are really getting through (and if not, figure out why). Likewise, on the client, you could directly add them to the client RequestContext via the normal way of adding headers:
http://cxf.apache.org/faq.html#FAQ-HowcanIaddsoapheaderstotherequest/response?
and avoid the JAX-WS handler/interceptor entirely.
Few more CXF things:
In XLSTResourceTransformer and TransferTools and a few other places, you are creating DocumentBuilderFactory/DocumentBuilder and a Transformer and such. You really should use the utility methods we have in StaxUtils, XMLUtils, and XSLTUtils for much of that. We try to make sure all the XML parsing and processing goes through those utilities so that we can control various aspects to prevent various attacks (like entity expansion attacks).
Other than that, it looks fairly good. I hope the above gives you some stuff to think about.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [Proposal] WS-Transfer/WS-Fragment implementation
Posted by dudae <du...@gmail.com>.
Do you check the implementation? Could you give me some feedback please?
Thank you.
Erich Duda
--
View this message in context: http://cxf.547215.n5.nabble.com/Proposal-WS-Transfer-WS-Fragment-implementation-tp5750975p5754317.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: [Proposal] WS-Transfer/WS-Fragment implementation
Posted by dudae <du...@gmail.com>.
FIX: Document about implementation details is here
https://developer.jboss.org/docs/DOC-52429?uniqueTitle=false
--
View this message in context: http://cxf.547215.n5.nabble.com/Proposal-WS-Transfer-WS-Fragment-implementation-tp5750975p5751577.html
Sent from the cxf-dev mailing list archive at Nabble.com.