cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@gmail.com>
Subject Re: Usage of WS-RM 1.1 in the client configuration
Date Fri, 01 Mar 2013 09:45:16 GMT
2013/2/28 John Li <john@mycubes.nl>:
> Hi Aki,
>
> I understand your point and agree that things didn't get simpler. But I
> suppose that's often the case .
>
> Currently I am working on a governmental standard where reliable messaging
> is an important subject that we need to address within the webservice
> domain. The general idea is that WS-RM is now mature/widely supported
> enough to be taken in the standard. To support this we are working on a
> pilot project where we use the CXF implementation. If the standard is
> accepted, the webservices implementation that require reliability will
> follow this standard using different products/frameworks. That's why
> interoperability it a very important topic.
>
> I will report issues on wsrm when I find them and will definitely try to
> work on a patch for it. It will be the first time that I participate in
> supplying patches so I probably will need some help to do it on the right
> way.
>
> With uploading your code, you mean it will be available in maven as
> snapshot-2.8.0? or do need to get the code somewhere else?
> Thanks!

Hi John,
the code is in the trunk (corresponding to 2.8.0-SNAPSHOT) since
yesterday. But jenkins seems to have some issue since yesterday
afternoon and it hasn't built the trunk. So you have to wait or sync
the trunk repo (see the cxf home page on "building") and built it
locally.

i also created a jira CXF-4863 to track this TSR handling issue. I'll
add the rev-number to the ticket manually (usually the ticket is
automatically updated with the relevant svn commits, but this is not
happening for some weeks.)

regards, aki
>
> Regards, John
>
>
>
>
>
> On Thu, Feb 28, 2013 at 1:47 PM, Aki Yoshida <elakito@gmail.com> wrote:
>
>> 2013/2/28 John Li <john@mycubes.nl>:
>> > Hi Aki,
>> >
>> > Thanks for your response!
>> > Great to hear that you have a fix for this issue. It would be great if
>> you
>> > can upload it so I can maybe help with testing it?
>> > Currently we are working with a client/server implementation of both CXF
>> so
>> > there is no direct problem with the missing terminate response. But since
>> > WS-RM is getting more attention now and RSP 1.0 has been out for a while,
>> > it would be great that an important framework as CXF can support at least
>> > the WSRM part of this profile to 'ensure' interoperability. On difference
>> > of 1.0 and 1.1 we have found a list on the net that might help maybe? (
>> >
>> http://metro.java.net/nonav/1.2/guide/Using_WS_ReliableMessaging_v1_1.html
>> )
>> >
>> > If could also share your thoughts on the usage of this EP element in
>> offer
>> > that would be of great help for me as well!
>> > Many thanks in advance
>>
>> Hi John,
>> there are some useful things in 1.1 which fix some limitations of 1.0.
>> On the other hand, 1.0 was already complex and 1.1 didn't make the
>> protocol simpler. That's kind of its own limitation and reflected in
>> the usage.
>>
>> Which system will you be integrating with using WS-RM?
>>
>> In any case, if you find some issues, please report them and if you
>> can work on a patch, that would be also great.
>>
>> I'll upload the 1.1 terminate sequence stuff today. If you can verify
>> it, that would be great.
>>
>> regards, aki
>>
>> >
>> > Regards,
>> > John
>> >
>> >
>> >
>> >
>> > On Thu, Feb 28, 2013 at 11:37 AM, Aki Yoshida <elakito@gmail.com> wrote:
>> >
>> >> 2013/2/21 John Li <john@mycubes.nl>:
>> >> > Hi Dennis & others,
>> >> >
>> >> > How is the progress on the WSRM 1.2 implementation? Currently I
>> working
>> >> > with a client on a pilot where we use the WSRM implementation of
>> Apache
>> >> > CXF. Though functionaly it works fine with the new namespace, we do
>> have
>> >> > seen inconsistencies with the WSRM 1.1/1.2 specification. For example
>> we
>> >> > see in the createSequence offer element that the endpoint element is
>> >> > missing, while it is defined as required in the 1.1/1.2 specification.
>> >> Also
>> >> > we just saw that the TerminateSequenceResponse is not sent when the
>> >> server
>> >> > receives the terminate sequence call from the client. As we compare
>> the
>> >> 1.0
>> >> > and the 1.1/1.2 specification also this response was not defined in
>> 1.0.
>> >> As
>> >> > I also didn't see any specific Jira issues on this, I was wondering
if
>> >> the
>> >> > new 1.2 implemetation already includes the missing elements.
>> >> >
>> >> > Besides the above I do have a specific question regarding the usage
of
>> >> the
>> >> > offer/endpoint that is more related to the specification in general.
I
>> >> hope
>> >> > you can help me on this. Since the createSequence already has a acksTo
>> >> > where WSRM lifecycle management calls are sent to, what is the exact
>> >> usage
>> >> > of the offer/endpoint element? According the specs it should be:
>> >> >
>> >> > An RM Source MUST include this element, of type
>> >> wsa:EndpointReferenceType (as
>> >> > specified by WS-Addressing). This element specifies the endpoint
>> >> reference
>> >> > to which Sequence Lifecycle Messages, Acknowledgement Requests, and
>> fault
>> >> > messages related to the offered Sequence are to be sent.
>> >> >
>> >> > But if we are providing an WS-addressing anonymous url as acksTo,
>> apache
>> >> > CXF is only using the back channel to response (according spec). So
is
>> >> the
>> >> > offer/endpoint element used for lifecycle response messages that is
>> >> > initiated from the RMS?
>> >>
>> >> Hi John,
>> >> I don;t know about 1.2, but for the terminateSeqeunceResponse for 1.1,
>> >> I have a fix and I can upload it. The missing ep element stuff that
>> >> you mentioned, I have to look at it. don't know.
>> >>
>> >> regards, aki
>> >>
>> >> >
>> >> > Any comment/help is appreciated.
>> >> >
>> >> >
>> >> > With kind regards,
>> >> >
>> >> > John
>> >> >
>> >> >
>> >> > On Wed, Jan 30, 2013 at 2:51 AM, <dms@sosnoski.com> wrote:
>> >> >
>> >> >> Thanks, John, I'll keep you posted.
>> >> >>
>> >> >> The big problem I had with the WS-RMP changes is that I couldn't
see
>> any
>> >> >> way of doing them incrementally. I had to pretty much tear out
the
>> >> existing
>> >> >> RM policy handling and change over to a new approach, which meant
>> >> working
>> >> >> locally until everything was fixed - and with ongoing changes to
the
>> >> base
>> >> >> code it was hard to keep up. I think I can probably rework what
I'd
>> done
>> >> >> before to allow piece-by-piece replacement, which should be much
>> >> smoother.
>> >> >>
>> >> >>   - Dennis
>> >> >>
>> >> >> John Li wrote ..
>> >> >> > Hi Dennis,
>> >> >> >
>> >> >> > Great! I have managed to get my server and client working
with the
>> 1.2
>> >> >> > policies added to the wsdl. It seems the assertions are now
>> ignored by
>> >> >> > wsrm
>> >> >> > module. In the jaxws features I have disabled the policies
and then
>> >> >> > manually added required wsrm features that I needed. Now when
the
>> wsdl
>> >> >> > is
>> >> >> > requested, the right policies are shown while internally the
wsrm
>> >> >> behaviour
>> >> >> > is configured by the bean configuration.
>> >> >> >
>> >> >> > Initially I thought that the client was working fine with
the
>> policies
>> >> >> > but
>> >> >> > it appears when I have changed the WSRM version like how Aki
>> suggested
>> >> >> > in
>> >> >> > the previous mail without adding the features manually in
the xml
>> >> >> > configuration, the createSequence is sent by WSRM with the
right
>> >> >> namespace
>> >> >> > but the soap headers are missing.
>> >> >> >
>> >> >> > I don't know where I can help you with anything but if you
see
>> >> something
>> >> >> > that I can help with. Let me know. I will be glad to help
>> >> >> >
>> >> >> > With kind regards,
>> >> >> > John
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > *John Li*
>> >> >> >
>> >> >> > Mobiel: +31621513273
>> >> >> > Email: john@mycubes.nl
>> >> >> > *My Cubes B.V.*
>> >> >> > Boeingavenue 215
>> >> >> > 1119 PD, Schiphol-Rijk
>> >> >> > Nederland
>> >> >> >
>> >> >> >
>> >> >> > De inhoud van dit bericht is alleen bestemd voor de geadresseerde
>> en
>> >> kan
>> >> >> > vertrouwelijke of persoonlijke informatie bevatten. Als u
dit
>> bericht
>> >> >> > onbedoeld heeft ontvangen verzoeken wij u het te vernietigen
en de
>> >> >> afzender
>> >> >> > te informeren. Het is niet toegestaan om een bericht dat niet
voor
>> u
>> >> >> > bestemd is te vermenigvuldigen dan wel te verspreiden. Aan
dit
>> bericht
>> >> >> > inclusief de bijlagen kunnen geen rechten ontleend worden,
tenzij
>> >> >> > schriftelijk anders wordt overeengekomen. My Cubes B.V.  aanvaardt
>> >> geen
>> >> >> > enkele aansprakelijkheid voor schade en/of kosten die voortvloeien
>> uit
>> >> >> > onvolledige en/of foutieve informatie in e-mailberichten.
>> >> >> >
>> >> >> > This message is intended for the exclusive use of the person(s)
>> >> mentioned
>> >> >> > as recipient(s) and may contain personal and/or confidential
>> >> information.
>> >> >> > If you have received this message in error, please notify
the
>> sender
>> >> and
>> >> >> > delete this message from your system immediately. Directly
or
>> >> indirectly
>> >> >> > copying, disclosing, distributing, printing, publicising and/or
in
>> any
>> >> >> > way
>> >> >> > using this message or any part thereof by any means is strictly
>> >> >> prohibited
>> >> >> > if you are not the intended recipient(s). This message and
any
>> >> associated
>> >> >> > attachments cannot be deemed as legally binding under any
>> >> circumstances
>> >> >> > without the express written consent from My Cubes B.V.. My
Cubes
>> B.V.
>> >> is
>> >> >> > not responsible for any loss and/or damages arising from any
errors
>> >> >> and/or
>> >> >> > omissions in its e-mail messages.
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Jan 29, 2013 at 7:38 PM, Dennis Sosnoski <dms@sosnoski.com
>> >
>> >> >> wrote:
>> >> >> >
>> >> >> > > Hi John,
>> >> >> > >
>> >> >> > > I did most of the work required for WS-RMP support last
year,
>> when I
>> >> >> > > opened https://issues.apache.org/**jira/browse/CXF-4139<
>> >> >> https://issues.apache.org/jira/browse/CXF-4139>.
>> >> >> > > But I got distracted by other projects, and my work-in-progress
>> was
>> >> >> > > outdated by other changes. It's coming up on the one
year
>> >> anniversary,
>> >> >> > so
>> >> >> > > probably time to give this another try. I'll look into
putting
>> the
>> >> >> pieces
>> >> >> > > back together next week.
>> >> >> > >
>> >> >> > > Regards,
>> >> >> > >
>> >> >> > >   - Dennis
>> >> >> > >
>> >> >> > >
>> >> >> > >
>> >> >> > > On 01/22/2013 09:24 PM, John Li wrote:
>> >> >> > >
>> >> >> > >> Hello Aki,
>> >> >> > >>
>> >> >> > >> Thanks for your help. The settings work as expected.
>> >> >> > >> I wil contact Dennis about the latest status on this
issue and
>> >> >> pointers
>> >> >> > to
>> >> >> > >> where I could possibly start with contributing to
this.
>> Meanwhile I
>> >> >> > setup
>> >> >> > >> the environment and get all the unit tests up and
running so I
>> can
>> >> >> start
>> >> >> > >> directly when I have some more information.
>> >> >> > >>
>> >> >> > >> With kind regards,
>> >> >> > >> John
>> >> >> > >>
>> >> >> > >>
>> >> >> > >> On Fri, Jan 18, 2013 at 11:00 AM, Aki Yoshida<elakito@gmail.com
>> >
>> >> >>  wrote:
>> >> >> > >>
>> >> >> > >>  Hi John,
>> >> >> > >>> if you are using the sample Client from samples/ws_rm,
you can
>> set
>> >> >> > the
>> >> >> > >>> protocol as
>> >> >> > >>>
>> >> >> > >>> import org.apache.cxf.endpoint.**Client;
>> >> >> > >>> import org.apache.cxf.frontend.**ClientProxy;
>> >> >> > >>> ...
>> >> >> > >>>          Client client = ClientProxy.getClient(port);
>> >> >> > >>>
>> >>  client.getRequestContext().**put(RMManager.WSRM_VERSION_**
>> >> >> > >>> PROPERTY,
>> >> >> > >>> RM11Constants.NAMESPACE_URI);
>> >> >> > >>>          client.getRequestContext().**put(RMManager.WSRM_WSA_**
>> >> >> > >>> VERSION_PROPERTY,
>> >> >> > >>> Names.WSA_NAMESPACE_NAME);
>> >> >> > >>>
>> >> >> > >>> Regarding CXF-4139, as RMP 1.1 assertions are
instantiated but
>> >> >> > >>> currently not used, as CXF's WS-RM uses 1.0 assertions
>> internally
>> >> to
>> >> >> > >>> read the configuration values like retransmission
time etc. I
>> >> added
>> >> >> > >>> some additional configuration properties in the
manager schema
>> >> >> > >>> sometime ago to expose the options that are not
defined in
>> neither
>> >> >> > >>> policy versions or not in 1.1. Dennis mentioned
me of this
>> policy
>> >> >> > >>> unification ticket at that time. You can ping
him and ask him
>> if
>> >> he
>> >> >> > >>> has some update. If you can look into it and
contribute, that
>> >> sounds
>> >> >> > >>> great.
>> >> >> > >>>
>> >> >> > >>> thanks.
>> >> >> > >>> regards, aki
>> >> >> > >>>
>> >> >> > >>> 2013/1/17 John Li<john@mycubes.nl>:
>> >> >> > >>>
>> >> >> > >>>> Hello Aki
>> >> >> > >>>>
>> >> >> > >>>> Thanks for your quick response!
>> >> >> > >>>> I am looking into your suggestion and I wanted
to try this
>> >> approach
>> >> >> > >>>>
>> >> >> > >>> before
>> >> >> > >>>
>> >> >> > >>>> I set set the bean property through Spring.
But I saw in the
>> >> >> > >>>> org.apache.cxf.ws.rm.Proxy file that the
client is always
>> >> >> instanciated
>> >> >> > >>>> in
>> >> >> > >>>> the 'invoke' method. So I am not sure how
I can change this
>> >> runtime
>> >> >> > >>>>
>> >> >> > >>> setting
>> >> >> > >>>
>> >> >> > >>>> without overriding the createClient method
in the Proxy class.
>> >> But
>> >> >> > I
>> >> >> > >>>> figured that shouldn't be the way to go so
I went for the
>> >> property
>> >> >> > >>>> configuration solution. Can you maybe point
me to the place
>> where
>> >> >> > I can
>> >> >> > >>>> access the client in the correct way? Thanks!
>> >> >> > >>>>
>> >> >> > >>>> Also having seen issue
>> >> >> > >>>> CXF-4139<https://issues.**apache.org/jira/browse/CXF-**4139<
>> >> >> https://issues.apache.org/jira/browse/CXF-4139>>
>> >> >> > >>>>  it
>> >> >> > >>>> looks like this task has been defined for
quite a while. Is
>> there
>> >> >> > >>>> already
>> >> >> > >>>> some activity on this? Since I will be working
on wsrm for a
>> >> couple
>> >> >> > of
>> >> >> > >>>> months (at least), maybe I can help/contribute
with anything
>> on
>> >> this
>> >> >> > >>>>
>> >> >> > >>> part?
>> >> >> > >>>
>> >> >> > >>>> Many thanks in advance!
>> >> >> > >>>>
>> >> >> > >>>> With kind regards,
>> >> >> > >>>> John
>> >> >> > >>>>
>> >> >> > >>>>
>> >> >> > >>>>
>> >> >> > >>>>
>> >> >> > >>>> On Thu, Jan 17, 2013 at 3:52 PM, Aki Yoshida<
>> elakito@gmail.com>
>> >> >>  wrote:
>> >> >> > >>>>
>> >> >> > >>>>  Hi John,
>> >> >> > >>>>> That generic property setting option
was marked deprecated
>> many
>> >> >> years
>> >> >> > >>>>> go, so it's not good to use it. The explicit
WSA namespace
>> >> setting
>> >> >> > in
>> >> >> > >>>>> the bean configuration was added when
WS-RM 1.1 was added.
>> But I
>> >> >> > think
>> >> >> > >>>>> it is confusing to set these namespace
properties in the RM
>> >> >> > >>>>> feature/manager level, as the server
side endpoint can accept
>> >> both
>> >> >> > >>>>> versions. Maybe that is why Dennis who
worked on RM1.1
>> >> >> implementation
>> >> >> > >>>>> didn't add the RM namespace setting property
to the bean
>> >> >> > >>>>> configuration.
>> >> >> > >>>>>
>> >> >> > >>>>> So how can you tell the client which
WSRM version to use? You
>> >> can
>> >> >> > >>>>> switch it by setting the appropriate
runtime context
>> properties.
>> >> >> > For
>> >> >> > >>>>> example, to use the standard WSRM11 and
WSA combination, you
>> can
>> >> >> > >>>>> write:
>> >> >> > >>>>>
>> >> >> > >>>>>
>> >>  client.getRequestContext().**put(RMManager.WSRM_VERSION_**
>> >> >> > >>>>> PROPERTY,
>> >> >> > >>>>> RM11Constants.NAMESPACE_URI);
>> >> >> > >>>>>
>> >> >> > >>>>>  client.getRequestContext().**put(RMManager.WSRM_WSA_**
>> >> >> > >>> VERSION_PROPERTY,
>> >> >> > >>>
>> >> >> > >>>> Names.WSA_NAMESPACE_NAME);
>> >> >> > >>>>>
>> >> >> > >>>>> For the server side, both versions 1.0
and 1.1 are
>> automatically
>> >> >> > >>>>> accepted. So you don't need to configure
anything special.
>> >> >> > >>>>>
>> >> >> > >>>>> regards, aki
>> >> >> > >>>>>
>> >> >> > >>>>> 2013/1/17 John Li<john@mycubes.nl>:
>> >> >> > >>>>>
>> >> >> > >>>>>> Hello all,
>> >> >> > >>>>>>
>> >> >> > >>>>>> I am currently working on an assignment
to implement a pilot
>> >> >> showing
>> >> >> > >>>>>>
>> >> >> > >>>>> the
>> >> >> > >>>
>> >> >> > >>>> interoperability of WSRM between different
technologies. For
>> the
>> >> >> > >>>>>>
>> >> >> > >>>>> reference
>> >> >> > >>>>>
>> >> >> > >>>>>> implementation I will be using Apache
CXF to provide both a
>> >> server
>> >> >> > for
>> >> >> > >>>>>> other clients to connect to and to
provide a sample client
>> >> >> > >>>>>>
>> >> >> > >>>>> implementation
>> >> >> > >>>
>> >> >> > >>>> in Apache CXF.
>> >> >> > >>>>>>
>> >> >> > >>>>>> After downloading and getting the
wsrm sample application up
>> >> and
>> >> >> > >>>>>>
>> >> >> > >>>>> running
>> >> >> > >>>
>> >> >> > >>>> I
>> >> >> > >>>>>
>> >> >> > >>>>>> have seen in the SOAP messages that
WSRM 1.0 is the default
>> >> >> protocol
>> >> >> > >>>>>>
>> >> >> > >>>>> since
>> >> >> > >>>>>
>> >> >> > >>>>>> the namespace is still '
>> >> >> http://schemas.xmlsoap.org/**ws/2005/02/rm<
>> >> >> http://schemas.xmlsoap.org/ws/2005/02/rm>
>> >> >> > >>>>>> '.
>> >> >> > >>>>>>
>> >> >> > >>>>>> Actually the CXF website is not mentioning
anything about
>> the
>> >> >> > >>>>>> implementation of wsrm 1.1. After
some research I found that
>> >> from
>> >> >> > >>>>>>
>> >> >> > >>>>> version
>> >> >> > >>>
>> >> >> > >>>> 2.5.1 the wsrm 1.1/1.2 has been added to
the release. My
>> problem
>> >> is
>> >> >> > >>>>>>
>> >> >> > >>>>> that
>> >> >> > >>>
>> >> >> > >>>> I
>> >> >> > >>>>>
>> >> >> > >>>>>> could not find how to activate the
1.1 protocol.
>> Specifically I
>> >> >> > need
>> >> >> > >>>>>>
>> >> >> > >>>>> the
>> >> >> > >>>
>> >> >> > >>>> RMS to send out wsrm 1.1 messages out instead
of 1.0 messages.
>> >> The
>> >> >> > >>>>>>
>> >> >> > >>>>> RMD I
>> >> >> > >>>
>> >> >> > >>>> can see it will react based on the message
that comes in so
>> that
>> >> >> will
>> >> >> > >>>>>> automatically select the right protocol
version.
>> >> >> > >>>>>>
>> >> >> > >>>>>> After looking through the source
code of the WSRM
>> >> implementation
>> >> >> > I
>> >> >> > >>>>>>
>> >> >> > >>>>> found
>> >> >> > >>>
>> >> >> > >>>> the required settings in the RMManager but
based on the
>> >> >> > >>>>>> current reliableMessaging configurations
the rmNamespace is
>> not
>> >> >> > a
>> >> >> > >>>>>> configuration option. Although I
can see in the
>> >> wsrm-manager.xsd
>> >> >> > the
>> >> >> > >>>>>> following statement:
>> >> >> > >>>>>>
>> >> >> > >>>>>> <xs:any namespace="http://www.**
>> >> >> springframework.org/schema/**beans<
>> >> >> http://www.springframework.org/schema/beans>
>> >> >> > >>>>>> "
>> >> >> > >>>>>> processContents="lax" minOccurs="0"
maxOccurs="unbounded">
>> >> >> > >>>>>> <xs:annotation><xs:**documentation>
>> >> >> > >>>>>> Deprecated.  To support the older
spring:property element
>> that
>> >> is
>> >> >> > no
>> >> >> > >>>>>>
>> >> >> > >>>>> longer
>> >> >> > >>>>>
>> >> >> > >>>>>> used
>> >> >> > >>>>>> </xs:documentation></xs:**annotation>
>> >> >> > >>>>>> </xs:any>
>> >> >> > >>>>>>
>> >> >> > >>>>>> I could only change this configuration
by using the spring
>> >> >> property
>> >> >> > >>>>>> element. So to make my client implementation
sending out
>> wsrm
>> >> 1.1
>> >> >> > >>>>>>
>> >> >> > >>>>> messages,
>> >> >> > >>>>>
>> >> >> > >>>>>> I have used the following two statements
in the
>> >> reliableMessaging
>> >> >> > >>>>>> configuration:
>> >> >> > >>>>>>
>> >> >> > >>>>>> <wsrm-mgr:**RM10AddressingNamespace
uri="
>> >> >> > >>>>>>
>> >> >> > >>>>> http://www.w3.org/2005/08/**addressing<
>> >> >> http://www.w3.org/2005/08/addressing>
>> >> >> > >>>>> "
>> >> >> > >>>>>
>> >> >> > >>>>>> />
>> >> >> > >>>>>> <property name="RMNamespace" value="
>> >> >> > >>>>>> http://docs.oasis-open.org/ws-**rx/wsrm/200702<
>> >> >> http://docs.oasis-open.org/ws-rx/wsrm/200702>
>> >> >> > >>>>>> "/>
>> >> >> > >>>>>>
>> >> >> > >>>>>> Though now it seems to work, the
property element is
>> deprecated
>> >> >> > so I
>> >> >> > >>>>>>
>> >> >> > >>>>> am
>> >> >> > >>>
>> >> >> > >>>> wondering if I am doing it on the correct
way or is there a
>> >> better
>> >> >> > >>>>>>
>> >> >> > >>>>> way to
>> >> >> > >>>
>> >> >> > >>>> do this?
>> >> >> > >>>>>>
>> >> >> > >>>>>> Also I see in the current implementation
that the usage of
>> >> wsrmp
>> >> >> > 1.0
>> >> >> > >>>>>> settings is defined in the wsrm-manager.xsd
and wsrmp
>> 1.1/1.2
>> >> >> elements
>> >> >> > >>>>>>
>> >> >> > >>>>> are
>> >> >> > >>>>>
>> >> >> > >>>>>> not supported. As it also is stated
in issue
>> >> >> > >>>>>> https://issues.apache.org/**jira/browse/CXF-4139<
>> >> >> https://issues.apache.org/jira/browse/CXF-4139>.
>> >> >> > >>>>>>  Though the wsrmp
>> >> >> > >>>>>>
>> >> >> > >>>>> 1.1/1.2
>> >> >> > >>>>>
>> >> >> > >>>>>> has totally different elements, the
most important delivery
>> >> >> assurance
>> >> >> > >>>>>> settings are already supported by
Apache CXF wsrm-manager
>> >> >> > >>>>>>
>> >> >> > >>>>> configurations.
>> >> >> > >>>
>> >> >> > >>>> My question on this is: What is the impact
for Apache CXF
>> when a
>> >> >> WSDL
>> >> >> > >>>>>>
>> >> >> > >>>>> is
>> >> >> > >>>
>> >> >> > >>>> provided that uses the wsrmp 1.1/1.2 policy
elements? Will
>> they
>> >> be
>> >> >> > >>>>>>
>> >> >> > >>>>> ignored
>> >> >> > >>>>>
>> >> >> > >>>>>> and you need to configure these settings
manually through
>> the
>> >> >> manager
>> >> >> > >>>>>>
>> >> >> > >>>>> or
>> >> >> > >>>
>> >> >> > >>>> does CXF automatically convert them to the
internal manager
>> >> >> settings?
>> >> >> > >>>>>>
>> >> >> > >>>>>> I hope someone can help me with clarifying
my questions.
>> >> >> > >>>>>>
>> >> >> > >>>>>> Many thanks in advance!
>> >> >> > >>>>>>
>> >> >> > >>>>>> John Li
>> >> >> > >>>>>>
>> >> >> > >>>>>
>> >> >>
>> >>
>>

Mime
View raw message