You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Christopher Moesel <Ch...@avid.com> on 2007/04/20 20:39:33 UTC
Questions While Implementing MTOM Policy
Hello,
I'm trying to implement a plugin for the MTOM Policy specification.
This is essentially a policy that states whether or not MTOM should be
used (or is optional). I intend on contributing it back to CXF, so I
figure I'm OK sending this to the dev list. ;)
I've created a MTOMAssertionBuilder that uses PrimitiveAssertions, a
MTOMPolicyInterceptor (that at this point just prints out if it is
asserted), and a MTOMPolicyInterceptorProvider.
I've registered the MTOMAssertionBuilder and
MTOMPolicyInterceptorProvider in
META-INF/cxf/cxf-extension-mtom-policy.xml and created a corresponding
META-INF/cxf/cxf.extension file. According to the documentation, this
is all that is needed to register them in CXF.
When I try my service (that has the ws-policy and ws-mtom-policy jars in
its classpath), none of my MTOM policy classes seem to be called. Do I
need to do something else to register them with my service, or is having
the policy assertion in the port of my WSDL file enough? It seems I
must be missing something important.
If it would be helpful, I can zip up the module and send it along.
Thanks!
Chris
Re: Questions While Implementing MTOM Policy
Posted by Andrea Smyth <an...@iona.com>.
Dan Diephouse wrote:
> OK, yeah ignore whatever I just said about optional not needing a prefix.
> The attribute does need to be qualified, I read the schema wrong.
>
> W.r.t to normalization, I think what is supposed to happen is this: If an
> element is optional (i.e. <OptimizedMimeSerialization
> wsp:Optional="true"/>), then that expression becomes equivalent to
>
> <ExactlyOne>
> <All><OptimizedMimeSerialization></All>
> <All/>
> </ExactlyOne>
>
> This would be considered the normalized expression. Or at least this
> is what
> I'm inferring from the code - a policy expert may correct me :-).
That's correct - it is what the code should be doing according to
http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Optional_Policy_Assertions
<http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Optional_Policy_Assertions>
>
> - Dan
>
> On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
>
>>
>> Hi Dan,
>>
>> I'm not sure we're looking at the same code... I'm looking at the
>> PrimitiveAssertion.java at http://preview.tinyurl.com/2qtfy3.
>>
>> If you look at the normalize method on line 94, you'll see that if the
>> assertion is optional, it creates a new ExactlyOne policy component
>> with two
>> Alls. The first All contains the result of cloneMandatory() which
>> constructs a clone with optional set to false. The second All is
>> empty. This new PolicyComponent is what is returned. The non-optional
>> assertion in the first All is what ends up being exposed to my
>> interceptor. But my interceptor is not away of the 2nd empty All--
>> so it
>> doesn't know this is really optional.
>>
>> Hopefully that makes a little more sense? Again, I'm also pretty
>> unfamiliar with the normalization, so it's possible this is the intended
>> behavior.
>>
>> When I get back to work on Monday I'll hack on it a little more and send
>> along a patch if it might help-- I am developing it inside the CXF code
>> base.
>>
>> Gotta go-- wife says it's time to stop working. ;)
>>
>> -Chris
>>
>>
>> -----Original Message-----
>> From: Dan Diephouse [mailto:dan@envoisolutions.com]
>> Sent: Fri 4/20/2007 5:42 PM
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: Questions While Implementing MTOM Policy
>>
>> Hi Christopher,
>>
>> It sounds like a possible bug. The normalization logic looks right
>> (for my
>> inexperienced eyes). It only adds a second All if optional is false. Do
>> you
>> know where optional gets set to false? Only place I see that called is
>> JaxbAssertionBuilder:104...
>>
>> I'm not sure if you're doing this in your own build or within in the CXF
>> build, but you could possibly send a patch along and I'll try to take a
>> peek. Or, you can take a gander at fixing normalization yourself.
>> I'll be
>> honest, I'm not that familiar with how normalization works yet in
>> CXF, but
>> I'll see if I can help.
>>
>> - Dan
>>
>> On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
>> >
>> > I fit in a little more work... It's almost their, except that even
>> > though I set my policy assertion to wsp:Optional="true", by the
>> time it
>> > makes it to the interceptor, the optional attribute is false.
>> >
>> > If I debug, I can see that when the PrimitiveAssertion is built, it
>> > correctly sets the "optional" attribute to true. But somewhere
>> down the
>> > line, the assertion is "normalized" and the optional flag gets
>> reset to
>> > false. This appears to be happening in the
>> PrimitiveAssertion.normalize
>> > method. The PolicyComponent returned is an ExactlyOne that
>> contains two
>> > Alls. The first All has a PrimitiveAssertion with optional set to
>> > false. The second All is empty.
>> >
>> > Is this the intended behavior? Is this a translation of optional=true
>> > to an ExactlyOne with one required Assertion and one empty Assertion?
>> > If so, how can I tell the difference between that and optional=false
>> > from within an interceptor?
>
Why does your interceptor need to be aware of it ?
The policy may have been specified in normalised form in WSDL already -
so your interceptor (or the policy framework its behalf) must browse all
alternatives anyway, and check for two alternatives A and B that differ
by nothing else except in that where one has an optional mtom assertion
the other ones has no such assertion, and all other assertions are
identical in these two alternatives (or where one is missing in A it is
present in B as a required assertion). In other words you'd have to
reverse the normalisation process and instead 'make it as compact as
possible' so that no matter which way the policy was expressed the
resulting behaviour is the same.
The problem seems related to who selects a policy alternative and when
the selection is made. So far, the policy framework takes the approach
to make that choice as early as possible (i.e. when message type and
operation are known). The rationale behind this is to not add
interceptors to the chain(s) when they are not needed. Also, at the
moment the framework simply chooses the first alternative that can
potentially be supported, not taking into account that some assertions
are more costly to support than others.
This can be changed to a more 'be prepared for any choice of
alternative' approach, as is already do on the inbound chains (where the
underlying message type and operation are not known upfront).
Or, to be more flexible, we could a choice between early and deferred
alternative selection.
If an assertion provider/interceptor wants exclusive rights on the
interpretation of an optionality attribute in an assertion, it should
define a corresponding attribute in its own namespace rather then
depending on wsp:Optional.
Andrea.
>
>> >
>> > Or does that question not even make sense? ;)
>> >
>> > -Chris
>> >
>> > -----Original Message-----
>> > From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
>> > Sent: Friday, April 20, 2007 4:16 PM
>> > To: cxf-dev@incubator.apache.org
>> > Subject: RE: Questions While Implementing MTOM Policy
>> >
>> > Thanks Dan-- that information has helped me get a bit further. I'm
>> > afraid I won't be able to do any more work on it until Monday
>> though...
>> > I'll let you know how things are going...
>> >
>> > -Chris
>> >
>> > -----Original Message-----
>> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
>> > Sent: Friday, April 20, 2007 3:15 PM
>> > To: cxf-dev@incubator.apache.org
>> > Subject: Re: Questions While Implementing MTOM Policy
>> >
>> > Hi Christopher,
>> >
>> > A zip of the module or a paste of the interceptor, mtom-policy.xml
>> file,
>> > and
>> > interceptor provider would be extremely helpful.
>> >
>> > Re question #2 - is your question how do I apply this mtom policy
>> to my
>> > service? I think the two mechanisms we have right now are WSDL Policy
>> > Attachments and creating an external policy. I'm working on a third
>> > where we
>> > can embed it in an <endpoint>/<client> configuration.
>> >
>> > Here's a small example of how to load an external policy file:
>> >
>> > <bean class="
>> >
>> org.apache.cxf.ws.policy.attachment.external.ExternalAttachmentProvider"
>> > >
>> > <constructor-arg ref="cxf"/>
>> > <property name="location"
>> > value="org/apache/cxf/systest/ws/policy/addr-external.xml"/>
>> > </bean>
>> >
>> > And then the external file:
>> >
>> > <attachments xmlns:wsp="http://www.w3.org/2006/07/ws-policy"
>> xmlns:wsa="
>> > http://www.w3.org/2005/08/addressing">
>> > <wsp:PolicyAttachment>
>> > <wsp:AppliesTo>
>> > <wsa:EndpointReference>
>> >
>> > <wsa:Address>http://localhost:9020/SoapContext/GreeterPort
>> > </wsa:Address>
>> > </wsa:EndpointReference>
>> > </wsp:AppliesTo>
>> > <wsp:Policy>
>> > <wsam:Addressing xmlns:wsam="
>> > http://www.w3.org/2007/01/addressing/metadata">
>> > <wsp:Policy/>
>> > </wsam:Addressing>
>> > </wsp:Policy>
>> > </wsp:PolicyAttachment>
>> > </attachments>
>> >
>> > This is part of the policy system tests. How are you configuring your
>> > service right now? Via the API? Via Spring?
>> > - Dan
>> >
>> > On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
>> > >
>> > > A Quick Update:
>> > >
>> > > I moved the bean configurations from the
>> > > META-INF/cxf/cxf-extension-mtom-policy.xml file to my service's own
>> > > Spring configuration file. Now I can see that my
>> > MTOMAssertionBuilder,
>> > > MTOMPolicyInterceptorProvider, and MTOMPolicyInterceptors are at
>> least
>> > > instantiated (which is further than I got before).
>> > >
>> > > But, the handleMessage method on my MTOMPolicyInterceptor is never
>> > > called when I make a request to the service, so something still
>> > doesn't
>> > > seem to be registered right.
>> > >
>> > > So two questions now:
>> > >
>> > > 1) Why wasn't my META-INF/cxf/cxf-extension-mtom-policy.xml file
>> > never
>> > > loaded by the framework?
>> > >
>> > > 2) How do I get my service to actually build those assertions and
>> > > intercept the messages?
>> > >
>> > > Thanks,
>> > > Chris
>> > >
>> > > -----Original Message-----
>> > > From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
>> > > Sent: Friday, April 20, 2007 2:40 PM
>> > > To: cxf-dev@incubator.apache.org
>> > > Subject: Questions While Implementing MTOM Policy
>> > >
>> > > Hello,
>> > >
>> > > I'm trying to implement a plugin for the MTOM Policy specification.
>> > > This is essentially a policy that states whether or not MTOM
>> should be
>> > > used (or is optional). I intend on contributing it back to CXF,
>> so I
>> > > figure I'm OK sending this to the dev list. ;)
>> > >
>> > > I've created a MTOMAssertionBuilder that uses PrimitiveAssertions, a
>> > > MTOMPolicyInterceptor (that at this point just prints out if it is
>> > > asserted), and a MTOMPolicyInterceptorProvider.
>> > >
>> > > I've registered the MTOMAssertionBuilder and
>> > > MTOMPolicyInterceptorProvider in
>> > > META-INF/cxf/cxf-extension-mtom-policy.xml and created a
>> corresponding
>> > > META-INF/cxf/cxf.extension file. According to the documentation,
>> this
>> > > is all that is needed to register them in CXF.
>> > >
>> > > When I try my service (that has the ws-policy and ws-mtom-policy
>> jars
>> > in
>> > > its classpath), none of my MTOM policy classes seem to be
>> called. Do
>> > I
>> > > need to do something else to register them with my service, or is
>> > having
>> > > the policy assertion in the port of my WSDL file enough? It seems I
>> > > must be missing something important.
>> > >
>> > > If it would be helpful, I can zip up the module and send it along.
>> > >
>> > > Thanks!
>> > > Chris
>> > >
>> >
>> >
>> >
>> > --
>> > Dan Diephouse
>> > Envoi Solutions
>> > http://envoisolutions.com | http://netzooid.com/blog
>> >
>>
>>
>>
>> --
>> Dan Diephouse
>> Envoi Solutions
>> http://envoisolutions.com | http://netzooid.com/blog
>>
>>
>
>
Re: Questions While Implementing MTOM Policy
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
The interesting bit here is that it would help looking at this normalized expression, and indeed at any other
policy expression, being primarily targeted at the client runtime.
Specifically, the optionality hint tells the client (by causing two alternatives created in the normalized form) that it may or may not choose the MTOM serialization when sending a given message to a service.
On the service side the optionality hint does not imply that the service may choose not to support MTOM. By exposing the MTOM assertion the service guarantees MTOM will be supported.
So how the service will know that the MTOM processing should be done or not ? One message flowing to this service may be MTOMed (one client decided to do it) and the other one won't be MTOMed (the other client decided not to ot it may just be MTOM-unaware). The only hint is the MIME type of the incoming message.
Given that, the only thing the MTOM-policy interceptor can really do is to check the in MIME type, and if it points to the fact MTOM is used then set the mtom.enabled property for the actual MTOM handler (unless this handler checls the MIME type itself). MTOM policy interceptor can only do the policy validation on a given message if the MTOM policy assertion is not marked as optional.
Cheers, Sergey
> OK, yeah ignore whatever I just said about optional not needing a prefix.
> The attribute does need to be qualified, I read the schema wrong.
>
> W.r.t to normalization, I think what is supposed to happen is this: If an
> element is optional (i.e. <OptimizedMimeSerialization
> wsp:Optional="true"/>), then that expression becomes equivalent to
>
> <ExactlyOne>
> <All><OptimizedMimeSerialization></All>
> <All/>
> </ExactlyOne>
>
> This would be considered the normalized expression. Or at least this is what
> I'm inferring from the code - a policy expert may correct me :-).
>
> - Dan
>
> On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
>>
>> Hi Dan,
>>
>> I'm not sure we're looking at the same code... I'm looking at the
>> PrimitiveAssertion.java at http://preview.tinyurl.com/2qtfy3.
>>
>> If you look at the normalize method on line 94, you'll see that if the
>> assertion is optional, it creates a new ExactlyOne policy component with two
>> Alls. The first All contains the result of cloneMandatory() which
>> constructs a clone with optional set to false. The second All is
>> empty. This new PolicyComponent is what is returned. The non-optional
>> assertion in the first All is what ends up being exposed to my
>> interceptor. But my interceptor is not away of the 2nd empty All-- so it
>> doesn't know this is really optional.
>>
>> Hopefully that makes a little more sense? Again, I'm also pretty
>> unfamiliar with the normalization, so it's possible this is the intended
>> behavior.
>>
>> When I get back to work on Monday I'll hack on it a little more and send
>> along a patch if it might help-- I am developing it inside the CXF code
>> base.
>>
>> Gotta go-- wife says it's time to stop working. ;)
>>
>> -Chris
>>
>>
>> -----Original Message-----
>> From: Dan Diephouse [mailto:dan@envoisolutions.com]
>> Sent: Fri 4/20/2007 5:42 PM
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: Questions While Implementing MTOM Policy
>>
>> Hi Christopher,
>>
>> It sounds like a possible bug. The normalization logic looks right (for my
>> inexperienced eyes). It only adds a second All if optional is false. Do
>> you
>> know where optional gets set to false? Only place I see that called is
>> JaxbAssertionBuilder:104...
>>
>> I'm not sure if you're doing this in your own build or within in the CXF
>> build, but you could possibly send a patch along and I'll try to take a
>> peek. Or, you can take a gander at fixing normalization yourself. I'll be
>> honest, I'm not that familiar with how normalization works yet in CXF, but
>> I'll see if I can help.
>>
>> - Dan
>>
>> On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
>> >
>> > I fit in a little more work... It's almost their, except that even
>> > though I set my policy assertion to wsp:Optional="true", by the time it
>> > makes it to the interceptor, the optional attribute is false.
>> >
>> > If I debug, I can see that when the PrimitiveAssertion is built, it
>> > correctly sets the "optional" attribute to true. But somewhere down the
>> > line, the assertion is "normalized" and the optional flag gets reset to
>> > false. This appears to be happening in the PrimitiveAssertion.normalize
>> > method. The PolicyComponent returned is an ExactlyOne that contains two
>> > Alls. The first All has a PrimitiveAssertion with optional set to
>> > false. The second All is empty.
>> >
>> > Is this the intended behavior? Is this a translation of optional=true
>> > to an ExactlyOne with one required Assertion and one empty Assertion?
>> > If so, how can I tell the difference between that and optional=false
>> > from within an interceptor?
>> >
>> > Or does that question not even make sense? ;)
>> >
>> > -Chris
>> >
>> > -----Original Message-----
>> > From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
>> > Sent: Friday, April 20, 2007 4:16 PM
>> > To: cxf-dev@incubator.apache.org
>> > Subject: RE: Questions While Implementing MTOM Policy
>> >
>> > Thanks Dan-- that information has helped me get a bit further. I'm
>> > afraid I won't be able to do any more work on it until Monday though...
>> > I'll let you know how things are going...
>> >
>> > -Chris
>> >
>> > -----Original Message-----
>> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
>> > Sent: Friday, April 20, 2007 3:15 PM
>> > To: cxf-dev@incubator.apache.org
>> > Subject: Re: Questions While Implementing MTOM Policy
>> >
>> > Hi Christopher,
>> >
>> > A zip of the module or a paste of the interceptor, mtom-policy.xml file,
>> > and
>> > interceptor provider would be extremely helpful.
>> >
>> > Re question #2 - is your question how do I apply this mtom policy to my
>> > service? I think the two mechanisms we have right now are WSDL Policy
>> > Attachments and creating an external policy. I'm working on a third
>> > where we
>> > can embed it in an <endpoint>/<client> configuration.
>> >
>> > Here's a small example of how to load an external policy file:
>> >
>> > <bean class="
>> > org.apache.cxf.ws.policy.attachment.external.ExternalAttachmentProvider"
>> > >
>> > <constructor-arg ref="cxf"/>
>> > <property name="location"
>> > value="org/apache/cxf/systest/ws/policy/addr-external.xml"/>
>> > </bean>
>> >
>> > And then the external file:
>> >
>> > <attachments xmlns:wsp="http://www.w3.org/2006/07/ws-policy" xmlns:wsa="
>> > http://www.w3.org/2005/08/addressing">
>> > <wsp:PolicyAttachment>
>> > <wsp:AppliesTo>
>> > <wsa:EndpointReference>
>> >
>> > <wsa:Address>http://localhost:9020/SoapContext/GreeterPort
>> > </wsa:Address>
>> > </wsa:EndpointReference>
>> > </wsp:AppliesTo>
>> > <wsp:Policy>
>> > <wsam:Addressing xmlns:wsam="
>> > http://www.w3.org/2007/01/addressing/metadata">
>> > <wsp:Policy/>
>> > </wsam:Addressing>
>> > </wsp:Policy>
>> > </wsp:PolicyAttachment>
>> > </attachments>
>> >
>> > This is part of the policy system tests. How are you configuring your
>> > service right now? Via the API? Via Spring?
>> > - Dan
>> >
>> > On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
>> > >
>> > > A Quick Update:
>> > >
>> > > I moved the bean configurations from the
>> > > META-INF/cxf/cxf-extension-mtom-policy.xml file to my service's own
>> > > Spring configuration file. Now I can see that my
>> > MTOMAssertionBuilder,
>> > > MTOMPolicyInterceptorProvider, and MTOMPolicyInterceptors are at least
>> > > instantiated (which is further than I got before).
>> > >
>> > > But, the handleMessage method on my MTOMPolicyInterceptor is never
>> > > called when I make a request to the service, so something still
>> > doesn't
>> > > seem to be registered right.
>> > >
>> > > So two questions now:
>> > >
>> > > 1) Why wasn't my META-INF/cxf/cxf-extension-mtom-policy.xml file
>> > never
>> > > loaded by the framework?
>> > >
>> > > 2) How do I get my service to actually build those assertions and
>> > > intercept the messages?
>> > >
>> > > Thanks,
>> > > Chris
>> > >
>> > > -----Original Message-----
>> > > From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
>> > > Sent: Friday, April 20, 2007 2:40 PM
>> > > To: cxf-dev@incubator.apache.org
>> > > Subject: Questions While Implementing MTOM Policy
>> > >
>> > > Hello,
>> > >
>> > > I'm trying to implement a plugin for the MTOM Policy specification.
>> > > This is essentially a policy that states whether or not MTOM should be
>> > > used (or is optional). I intend on contributing it back to CXF, so I
>> > > figure I'm OK sending this to the dev list. ;)
>> > >
>> > > I've created a MTOMAssertionBuilder that uses PrimitiveAssertions, a
>> > > MTOMPolicyInterceptor (that at this point just prints out if it is
>> > > asserted), and a MTOMPolicyInterceptorProvider.
>> > >
>> > > I've registered the MTOMAssertionBuilder and
>> > > MTOMPolicyInterceptorProvider in
>> > > META-INF/cxf/cxf-extension-mtom-policy.xml and created a corresponding
>> > > META-INF/cxf/cxf.extension file. According to the documentation, this
>> > > is all that is needed to register them in CXF.
>> > >
>> > > When I try my service (that has the ws-policy and ws-mtom-policy jars
>> > in
>> > > its classpath), none of my MTOM policy classes seem to be called. Do
>> > I
>> > > need to do something else to register them with my service, or is
>> > having
>> > > the policy assertion in the port of my WSDL file enough? It seems I
>> > > must be missing something important.
>> > >
>> > > If it would be helpful, I can zip up the module and send it along.
>> > >
>> > > Thanks!
>> > > Chris
>> > >
>> >
>> >
>> >
>> > --
>> > Dan Diephouse
>> > Envoi Solutions
>> > http://envoisolutions.com | http://netzooid.com/blog
>> >
>>
>>
>>
>> --
>> Dan Diephouse
>> Envoi Solutions
>> http://envoisolutions.com | http://netzooid.com/blog
>>
>>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: Questions While Implementing MTOM Policy
Posted by Dan Diephouse <da...@envoisolutions.com>.
OK, yeah ignore whatever I just said about optional not needing a prefix.
The attribute does need to be qualified, I read the schema wrong.
W.r.t to normalization, I think what is supposed to happen is this: If an
element is optional (i.e. <OptimizedMimeSerialization
wsp:Optional="true"/>), then that expression becomes equivalent to
<ExactlyOne>
<All><OptimizedMimeSerialization></All>
<All/>
</ExactlyOne>
This would be considered the normalized expression. Or at least this is what
I'm inferring from the code - a policy expert may correct me :-).
- Dan
On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
>
> Hi Dan,
>
> I'm not sure we're looking at the same code... I'm looking at the
> PrimitiveAssertion.java at http://preview.tinyurl.com/2qtfy3.
>
> If you look at the normalize method on line 94, you'll see that if the
> assertion is optional, it creates a new ExactlyOne policy component with two
> Alls. The first All contains the result of cloneMandatory() which
> constructs a clone with optional set to false. The second All is
> empty. This new PolicyComponent is what is returned. The non-optional
> assertion in the first All is what ends up being exposed to my
> interceptor. But my interceptor is not away of the 2nd empty All-- so it
> doesn't know this is really optional.
>
> Hopefully that makes a little more sense? Again, I'm also pretty
> unfamiliar with the normalization, so it's possible this is the intended
> behavior.
>
> When I get back to work on Monday I'll hack on it a little more and send
> along a patch if it might help-- I am developing it inside the CXF code
> base.
>
> Gotta go-- wife says it's time to stop working. ;)
>
> -Chris
>
>
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Fri 4/20/2007 5:42 PM
> To: cxf-dev@incubator.apache.org
> Subject: Re: Questions While Implementing MTOM Policy
>
> Hi Christopher,
>
> It sounds like a possible bug. The normalization logic looks right (for my
> inexperienced eyes). It only adds a second All if optional is false. Do
> you
> know where optional gets set to false? Only place I see that called is
> JaxbAssertionBuilder:104...
>
> I'm not sure if you're doing this in your own build or within in the CXF
> build, but you could possibly send a patch along and I'll try to take a
> peek. Or, you can take a gander at fixing normalization yourself. I'll be
> honest, I'm not that familiar with how normalization works yet in CXF, but
> I'll see if I can help.
>
> - Dan
>
> On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
> >
> > I fit in a little more work... It's almost their, except that even
> > though I set my policy assertion to wsp:Optional="true", by the time it
> > makes it to the interceptor, the optional attribute is false.
> >
> > If I debug, I can see that when the PrimitiveAssertion is built, it
> > correctly sets the "optional" attribute to true. But somewhere down the
> > line, the assertion is "normalized" and the optional flag gets reset to
> > false. This appears to be happening in the PrimitiveAssertion.normalize
> > method. The PolicyComponent returned is an ExactlyOne that contains two
> > Alls. The first All has a PrimitiveAssertion with optional set to
> > false. The second All is empty.
> >
> > Is this the intended behavior? Is this a translation of optional=true
> > to an ExactlyOne with one required Assertion and one empty Assertion?
> > If so, how can I tell the difference between that and optional=false
> > from within an interceptor?
> >
> > Or does that question not even make sense? ;)
> >
> > -Chris
> >
> > -----Original Message-----
> > From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
> > Sent: Friday, April 20, 2007 4:16 PM
> > To: cxf-dev@incubator.apache.org
> > Subject: RE: Questions While Implementing MTOM Policy
> >
> > Thanks Dan-- that information has helped me get a bit further. I'm
> > afraid I won't be able to do any more work on it until Monday though...
> > I'll let you know how things are going...
> >
> > -Chris
> >
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: Friday, April 20, 2007 3:15 PM
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Questions While Implementing MTOM Policy
> >
> > Hi Christopher,
> >
> > A zip of the module or a paste of the interceptor, mtom-policy.xml file,
> > and
> > interceptor provider would be extremely helpful.
> >
> > Re question #2 - is your question how do I apply this mtom policy to my
> > service? I think the two mechanisms we have right now are WSDL Policy
> > Attachments and creating an external policy. I'm working on a third
> > where we
> > can embed it in an <endpoint>/<client> configuration.
> >
> > Here's a small example of how to load an external policy file:
> >
> > <bean class="
> > org.apache.cxf.ws.policy.attachment.external.ExternalAttachmentProvider"
> > >
> > <constructor-arg ref="cxf"/>
> > <property name="location"
> > value="org/apache/cxf/systest/ws/policy/addr-external.xml"/>
> > </bean>
> >
> > And then the external file:
> >
> > <attachments xmlns:wsp="http://www.w3.org/2006/07/ws-policy" xmlns:wsa="
> > http://www.w3.org/2005/08/addressing">
> > <wsp:PolicyAttachment>
> > <wsp:AppliesTo>
> > <wsa:EndpointReference>
> >
> > <wsa:Address>http://localhost:9020/SoapContext/GreeterPort
> > </wsa:Address>
> > </wsa:EndpointReference>
> > </wsp:AppliesTo>
> > <wsp:Policy>
> > <wsam:Addressing xmlns:wsam="
> > http://www.w3.org/2007/01/addressing/metadata">
> > <wsp:Policy/>
> > </wsam:Addressing>
> > </wsp:Policy>
> > </wsp:PolicyAttachment>
> > </attachments>
> >
> > This is part of the policy system tests. How are you configuring your
> > service right now? Via the API? Via Spring?
> > - Dan
> >
> > On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
> > >
> > > A Quick Update:
> > >
> > > I moved the bean configurations from the
> > > META-INF/cxf/cxf-extension-mtom-policy.xml file to my service's own
> > > Spring configuration file. Now I can see that my
> > MTOMAssertionBuilder,
> > > MTOMPolicyInterceptorProvider, and MTOMPolicyInterceptors are at least
> > > instantiated (which is further than I got before).
> > >
> > > But, the handleMessage method on my MTOMPolicyInterceptor is never
> > > called when I make a request to the service, so something still
> > doesn't
> > > seem to be registered right.
> > >
> > > So two questions now:
> > >
> > > 1) Why wasn't my META-INF/cxf/cxf-extension-mtom-policy.xml file
> > never
> > > loaded by the framework?
> > >
> > > 2) How do I get my service to actually build those assertions and
> > > intercept the messages?
> > >
> > > Thanks,
> > > Chris
> > >
> > > -----Original Message-----
> > > From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
> > > Sent: Friday, April 20, 2007 2:40 PM
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Questions While Implementing MTOM Policy
> > >
> > > Hello,
> > >
> > > I'm trying to implement a plugin for the MTOM Policy specification.
> > > This is essentially a policy that states whether or not MTOM should be
> > > used (or is optional). I intend on contributing it back to CXF, so I
> > > figure I'm OK sending this to the dev list. ;)
> > >
> > > I've created a MTOMAssertionBuilder that uses PrimitiveAssertions, a
> > > MTOMPolicyInterceptor (that at this point just prints out if it is
> > > asserted), and a MTOMPolicyInterceptorProvider.
> > >
> > > I've registered the MTOMAssertionBuilder and
> > > MTOMPolicyInterceptorProvider in
> > > META-INF/cxf/cxf-extension-mtom-policy.xml and created a corresponding
> > > META-INF/cxf/cxf.extension file. According to the documentation, this
> > > is all that is needed to register them in CXF.
> > >
> > > When I try my service (that has the ws-policy and ws-mtom-policy jars
> > in
> > > its classpath), none of my MTOM policy classes seem to be called. Do
> > I
> > > need to do something else to register them with my service, or is
> > having
> > > the policy assertion in the port of my WSDL file enough? It seems I
> > > must be missing something important.
> > >
> > > If it would be helpful, I can zip up the module and send it along.
> > >
> > > Thanks!
> > > Chris
> > >
> >
> >
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Questions While Implementing MTOM Policy
Posted by Christopher Moesel <Ch...@avid.com>.
Hi Dan,
I'm not sure we're looking at the same code... I'm looking at the PrimitiveAssertion.java at http://preview.tinyurl.com/2qtfy3.
If you look at the normalize method on line 94, you'll see that if the assertion is optional, it creates a new ExactlyOne policy component with two Alls. The first All contains the result of cloneMandatory() which constructs a clone with optional set to false. The second All is empty. This new PolicyComponent is what is returned. The non-optional assertion in the first All is what ends up being exposed to my interceptor. But my interceptor is not away of the 2nd empty All-- so it doesn't know this is really optional.
Hopefully that makes a little more sense? Again, I'm also pretty unfamiliar with the normalization, so it's possible this is the intended behavior.
When I get back to work on Monday I'll hack on it a little more and send along a patch if it might help-- I am developing it inside the CXF code base.
Gotta go-- wife says it's time to stop working. ;)
-Chris
-----Original Message-----
From: Dan Diephouse [mailto:dan@envoisolutions.com]
Sent: Fri 4/20/2007 5:42 PM
To: cxf-dev@incubator.apache.org
Subject: Re: Questions While Implementing MTOM Policy
Hi Christopher,
It sounds like a possible bug. The normalization logic looks right (for my
inexperienced eyes). It only adds a second All if optional is false. Do you
know where optional gets set to false? Only place I see that called is
JaxbAssertionBuilder:104...
I'm not sure if you're doing this in your own build or within in the CXF
build, but you could possibly send a patch along and I'll try to take a
peek. Or, you can take a gander at fixing normalization yourself. I'll be
honest, I'm not that familiar with how normalization works yet in CXF, but
I'll see if I can help.
- Dan
On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
>
> I fit in a little more work... It's almost their, except that even
> though I set my policy assertion to wsp:Optional="true", by the time it
> makes it to the interceptor, the optional attribute is false.
>
> If I debug, I can see that when the PrimitiveAssertion is built, it
> correctly sets the "optional" attribute to true. But somewhere down the
> line, the assertion is "normalized" and the optional flag gets reset to
> false. This appears to be happening in the PrimitiveAssertion.normalize
> method. The PolicyComponent returned is an ExactlyOne that contains two
> Alls. The first All has a PrimitiveAssertion with optional set to
> false. The second All is empty.
>
> Is this the intended behavior? Is this a translation of optional=true
> to an ExactlyOne with one required Assertion and one empty Assertion?
> If so, how can I tell the difference between that and optional=false
> from within an interceptor?
>
> Or does that question not even make sense? ;)
>
> -Chris
>
> -----Original Message-----
> From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
> Sent: Friday, April 20, 2007 4:16 PM
> To: cxf-dev@incubator.apache.org
> Subject: RE: Questions While Implementing MTOM Policy
>
> Thanks Dan-- that information has helped me get a bit further. I'm
> afraid I won't be able to do any more work on it until Monday though...
> I'll let you know how things are going...
>
> -Chris
>
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Friday, April 20, 2007 3:15 PM
> To: cxf-dev@incubator.apache.org
> Subject: Re: Questions While Implementing MTOM Policy
>
> Hi Christopher,
>
> A zip of the module or a paste of the interceptor, mtom-policy.xml file,
> and
> interceptor provider would be extremely helpful.
>
> Re question #2 - is your question how do I apply this mtom policy to my
> service? I think the two mechanisms we have right now are WSDL Policy
> Attachments and creating an external policy. I'm working on a third
> where we
> can embed it in an <endpoint>/<client> configuration.
>
> Here's a small example of how to load an external policy file:
>
> <bean class="
> org.apache.cxf.ws.policy.attachment.external.ExternalAttachmentProvider"
> >
> <constructor-arg ref="cxf"/>
> <property name="location"
> value="org/apache/cxf/systest/ws/policy/addr-external.xml"/>
> </bean>
>
> And then the external file:
>
> <attachments xmlns:wsp="http://www.w3.org/2006/07/ws-policy" xmlns:wsa="
> http://www.w3.org/2005/08/addressing">
> <wsp:PolicyAttachment>
> <wsp:AppliesTo>
> <wsa:EndpointReference>
>
> <wsa:Address>http://localhost:9020/SoapContext/GreeterPort
> </wsa:Address>
> </wsa:EndpointReference>
> </wsp:AppliesTo>
> <wsp:Policy>
> <wsam:Addressing xmlns:wsam="
> http://www.w3.org/2007/01/addressing/metadata">
> <wsp:Policy/>
> </wsam:Addressing>
> </wsp:Policy>
> </wsp:PolicyAttachment>
> </attachments>
>
> This is part of the policy system tests. How are you configuring your
> service right now? Via the API? Via Spring?
> - Dan
>
> On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
> >
> > A Quick Update:
> >
> > I moved the bean configurations from the
> > META-INF/cxf/cxf-extension-mtom-policy.xml file to my service's own
> > Spring configuration file. Now I can see that my
> MTOMAssertionBuilder,
> > MTOMPolicyInterceptorProvider, and MTOMPolicyInterceptors are at least
> > instantiated (which is further than I got before).
> >
> > But, the handleMessage method on my MTOMPolicyInterceptor is never
> > called when I make a request to the service, so something still
> doesn't
> > seem to be registered right.
> >
> > So two questions now:
> >
> > 1) Why wasn't my META-INF/cxf/cxf-extension-mtom-policy.xml file
> never
> > loaded by the framework?
> >
> > 2) How do I get my service to actually build those assertions and
> > intercept the messages?
> >
> > Thanks,
> > Chris
> >
> > -----Original Message-----
> > From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
> > Sent: Friday, April 20, 2007 2:40 PM
> > To: cxf-dev@incubator.apache.org
> > Subject: Questions While Implementing MTOM Policy
> >
> > Hello,
> >
> > I'm trying to implement a plugin for the MTOM Policy specification.
> > This is essentially a policy that states whether or not MTOM should be
> > used (or is optional). I intend on contributing it back to CXF, so I
> > figure I'm OK sending this to the dev list. ;)
> >
> > I've created a MTOMAssertionBuilder that uses PrimitiveAssertions, a
> > MTOMPolicyInterceptor (that at this point just prints out if it is
> > asserted), and a MTOMPolicyInterceptorProvider.
> >
> > I've registered the MTOMAssertionBuilder and
> > MTOMPolicyInterceptorProvider in
> > META-INF/cxf/cxf-extension-mtom-policy.xml and created a corresponding
> > META-INF/cxf/cxf.extension file. According to the documentation, this
> > is all that is needed to register them in CXF.
> >
> > When I try my service (that has the ws-policy and ws-mtom-policy jars
> in
> > its classpath), none of my MTOM policy classes seem to be called. Do
> I
> > need to do something else to register them with my service, or is
> having
> > the policy assertion in the port of my WSDL file enough? It seems I
> > must be missing something important.
> >
> > If it would be helpful, I can zip up the module and send it along.
> >
> > Thanks!
> > Chris
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Questions While Implementing MTOM Policy
Posted by Christopher Moesel <Ch...@avid.com>.
Hi Dan,
I don't think I'm even using the JaxbAssertionBuilder-- I think I do remember seeing where it got set to false though... but I'm not at my computer that I've got my work on. Let me see if I can find it in the online SVN view of the CXF code.
-Chris
-----Original Message-----
From: Dan Diephouse [mailto:dan@envoisolutions.com]
Sent: Fri 4/20/2007 5:44 PM
To: cxf-dev@incubator.apache.org
Subject: Re: Questions While Implementing MTOM Policy
Actually, I think I see the issue: In JaxbAssertionBuilder.getOptionality it
has this line:
boolean optional = false;
String value = element.getAttributeNS(
Constants.Q_ELEM_OPTIONAL_ATTR.getNamespaceURI(),
Constants.Q_ELEM_OPTIONAL_ATTR.getLocalPart());
if (Boolean.valueOf(value)) {
optional = true;
}
return optional;
The issue is that the attribute is NOT qualified. So I think it should just
be:
String value = element.getAttribute(
Constants.Q_ELEM_OPTIONAL_ATTR.getLocalPart());
Does that fix things?
- Dan
On 4/20/07, Dan Diephouse <da...@envoisolutions.com> wrote:
>
> Hi Christopher,
>
> It sounds like a possible bug. The normalization logic looks right (for my
> inexperienced eyes). It only adds a second All if optional is false. Do you
> know where optional gets set to false? Only place I see that called is
> JaxbAssertionBuilder:104...
>
> I'm not sure if you're doing this in your own build or within in the CXF
> build, but you could possibly send a patch along and I'll try to take a
> peek. Or, you can take a gander at fixing normalization yourself. I'll be
> honest, I'm not that familiar with how normalization works yet in CXF, but
> I'll see if I can help.
>
> - Dan
>
> On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
> >
> > I fit in a little more work... It's almost their, except that even
> > though I set my policy assertion to wsp:Optional="true", by the time it
> > makes it to the interceptor, the optional attribute is false.
> >
> > If I debug, I can see that when the PrimitiveAssertion is built, it
> > correctly sets the "optional" attribute to true. But somewhere down the
> > line, the assertion is "normalized" and the optional flag gets reset to
> > false. This appears to be happening in the PrimitiveAssertion.normalize
> > method. The PolicyComponent returned is an ExactlyOne that contains two
> > Alls. The first All has a PrimitiveAssertion with optional set to
> > false. The second All is empty.
> >
> > Is this the intended behavior? Is this a translation of optional=true
> > to an ExactlyOne with one required Assertion and one empty Assertion?
> > If so, how can I tell the difference between that and optional=false
> > from within an interceptor?
> >
> > Or does that question not even make sense? ;)
> >
> > -Chris
> >
> > -----Original Message-----
> > From: Christopher Moesel [mailto:Christopher_Moesel@avid.com ]
> > Sent: Friday, April 20, 2007 4:16 PM
> > To: cxf-dev@incubator.apache.org
> > Subject: RE: Questions While Implementing MTOM Policy
> >
> > Thanks Dan-- that information has helped me get a bit further. I'm
> > afraid I won't be able to do any more work on it until Monday though...
> > I'll let you know how things are going...
> >
> > -Chris
> >
> > -----Original Message-----
> > From: Dan Diephouse [mailto: dan@envoisolutions.com]
> > Sent: Friday, April 20, 2007 3:15 PM
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Questions While Implementing MTOM Policy
> >
> > Hi Christopher,
> >
> > A zip of the module or a paste of the interceptor, mtom-policy.xml file,
> > and
> > interceptor provider would be extremely helpful.
> >
> > Re question #2 - is your question how do I apply this mtom policy to my
> > service? I think the two mechanisms we have right now are WSDL Policy
> > Attachments and creating an external policy. I'm working on a third
> > where we
> > can embed it in an <endpoint>/<client> configuration.
> >
> > Here's a small example of how to load an external policy file:
> >
> > <bean class="
> > org.apache.cxf.ws.policy.attachment.external.ExternalAttachmentProvider"
> > >
> > <constructor-arg ref="cxf"/>
> > <property name="location"
> > value="org/apache/cxf/systest/ws/policy/addr-external.xml"/>
> > </bean>
> >
> > And then the external file:
> >
> > <attachments xmlns:wsp=" http://www.w3.org/2006/07/ws-policy"
> > xmlns:wsa="
> > http://www.w3.org/2005/08/addressing">
> > <wsp:PolicyAttachment>
> > <wsp:AppliesTo>
> > <wsa:EndpointReference>
> >
> > <wsa:Address>http://localhost:9020/SoapContext/GreeterPort
> > </wsa:Address>
> > </wsa:EndpointReference>
> > </wsp:AppliesTo>
> > <wsp:Policy>
> > <wsam:Addressing xmlns:wsam="
> > http://www.w3.org/2007/01/addressing/metadata">
> > <wsp:Policy/>
> > </wsam:Addressing>
> > </wsp:Policy>
> > </wsp:PolicyAttachment>
> > </attachments>
> >
> > This is part of the policy system tests. How are you configuring your
> > service right now? Via the API? Via Spring?
> > - Dan
> >
> > On 4/20/07, Christopher Moesel < Christopher_Moesel@avid.com> wrote:
> > >
> > > A Quick Update:
> > >
> > > I moved the bean configurations from the
> > > META-INF/cxf/cxf-extension-mtom-policy.xml file to my service's own
> > > Spring configuration file. Now I can see that my
> > MTOMAssertionBuilder,
> > > MTOMPolicyInterceptorProvider, and MTOMPolicyInterceptors are at least
> > > instantiated (which is further than I got before).
> > >
> > > But, the handleMessage method on my MTOMPolicyInterceptor is never
> > > called when I make a request to the service, so something still
> > doesn't
> > > seem to be registered right.
> > >
> > > So two questions now:
> > >
> > > 1) Why wasn't my META-INF/cxf/cxf-extension-mtom-policy.xml file
> > never
> > > loaded by the framework?
> > >
> > > 2) How do I get my service to actually build those assertions and
> > > intercept the messages?
> > >
> > > Thanks,
> > > Chris
> > >
> > > -----Original Message-----
> > > From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
> > > Sent: Friday, April 20, 2007 2:40 PM
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Questions While Implementing MTOM Policy
> > >
> > > Hello,
> > >
> > > I'm trying to implement a plugin for the MTOM Policy specification.
> > > This is essentially a policy that states whether or not MTOM should be
> >
> > > used (or is optional). I intend on contributing it back to CXF, so I
> > > figure I'm OK sending this to the dev list. ;)
> > >
> > > I've created a MTOMAssertionBuilder that uses PrimitiveAssertions, a
> > > MTOMPolicyInterceptor (that at this point just prints out if it is
> > > asserted), and a MTOMPolicyInterceptorProvider.
> > >
> > > I've registered the MTOMAssertionBuilder and
> > > MTOMPolicyInterceptorProvider in
> > > META-INF/cxf/cxf-extension-mtom-policy.xml and created a corresponding
> > > META-INF/cxf/cxf.extension file. According to the documentation, this
> > > is all that is needed to register them in CXF.
> > >
> > > When I try my service (that has the ws-policy and ws-mtom-policy jars
> > in
> > > its classpath), none of my MTOM policy classes seem to be called. Do
> > I
> > > need to do something else to register them with my service, or is
> > having
> > > the policy assertion in the port of my WSDL file enough? It seems I
> > > must be missing something important.
> > >
> > > If it would be helpful, I can zip up the module and send it along.
> > >
> > > Thanks!
> > > Chris
> > >
> >
> >
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Questions While Implementing MTOM Policy
Posted by Dan Diephouse <da...@envoisolutions.com>.
Actually, I think I see the issue: In JaxbAssertionBuilder.getOptionality it
has this line:
boolean optional = false;
String value = element.getAttributeNS(
Constants.Q_ELEM_OPTIONAL_ATTR.getNamespaceURI(),
Constants.Q_ELEM_OPTIONAL_ATTR.getLocalPart());
if (Boolean.valueOf(value)) {
optional = true;
}
return optional;
The issue is that the attribute is NOT qualified. So I think it should just
be:
String value = element.getAttribute(
Constants.Q_ELEM_OPTIONAL_ATTR.getLocalPart());
Does that fix things?
- Dan
On 4/20/07, Dan Diephouse <da...@envoisolutions.com> wrote:
>
> Hi Christopher,
>
> It sounds like a possible bug. The normalization logic looks right (for my
> inexperienced eyes). It only adds a second All if optional is false. Do you
> know where optional gets set to false? Only place I see that called is
> JaxbAssertionBuilder:104...
>
> I'm not sure if you're doing this in your own build or within in the CXF
> build, but you could possibly send a patch along and I'll try to take a
> peek. Or, you can take a gander at fixing normalization yourself. I'll be
> honest, I'm not that familiar with how normalization works yet in CXF, but
> I'll see if I can help.
>
> - Dan
>
> On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
> >
> > I fit in a little more work... It's almost their, except that even
> > though I set my policy assertion to wsp:Optional="true", by the time it
> > makes it to the interceptor, the optional attribute is false.
> >
> > If I debug, I can see that when the PrimitiveAssertion is built, it
> > correctly sets the "optional" attribute to true. But somewhere down the
> > line, the assertion is "normalized" and the optional flag gets reset to
> > false. This appears to be happening in the PrimitiveAssertion.normalize
> > method. The PolicyComponent returned is an ExactlyOne that contains two
> > Alls. The first All has a PrimitiveAssertion with optional set to
> > false. The second All is empty.
> >
> > Is this the intended behavior? Is this a translation of optional=true
> > to an ExactlyOne with one required Assertion and one empty Assertion?
> > If so, how can I tell the difference between that and optional=false
> > from within an interceptor?
> >
> > Or does that question not even make sense? ;)
> >
> > -Chris
> >
> > -----Original Message-----
> > From: Christopher Moesel [mailto:Christopher_Moesel@avid.com ]
> > Sent: Friday, April 20, 2007 4:16 PM
> > To: cxf-dev@incubator.apache.org
> > Subject: RE: Questions While Implementing MTOM Policy
> >
> > Thanks Dan-- that information has helped me get a bit further. I'm
> > afraid I won't be able to do any more work on it until Monday though...
> > I'll let you know how things are going...
> >
> > -Chris
> >
> > -----Original Message-----
> > From: Dan Diephouse [mailto: dan@envoisolutions.com]
> > Sent: Friday, April 20, 2007 3:15 PM
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Questions While Implementing MTOM Policy
> >
> > Hi Christopher,
> >
> > A zip of the module or a paste of the interceptor, mtom-policy.xml file,
> > and
> > interceptor provider would be extremely helpful.
> >
> > Re question #2 - is your question how do I apply this mtom policy to my
> > service? I think the two mechanisms we have right now are WSDL Policy
> > Attachments and creating an external policy. I'm working on a third
> > where we
> > can embed it in an <endpoint>/<client> configuration.
> >
> > Here's a small example of how to load an external policy file:
> >
> > <bean class="
> > org.apache.cxf.ws.policy.attachment.external.ExternalAttachmentProvider"
> > >
> > <constructor-arg ref="cxf"/>
> > <property name="location"
> > value="org/apache/cxf/systest/ws/policy/addr-external.xml"/>
> > </bean>
> >
> > And then the external file:
> >
> > <attachments xmlns:wsp=" http://www.w3.org/2006/07/ws-policy"
> > xmlns:wsa="
> > http://www.w3.org/2005/08/addressing">
> > <wsp:PolicyAttachment>
> > <wsp:AppliesTo>
> > <wsa:EndpointReference>
> >
> > <wsa:Address>http://localhost:9020/SoapContext/GreeterPort
> > </wsa:Address>
> > </wsa:EndpointReference>
> > </wsp:AppliesTo>
> > <wsp:Policy>
> > <wsam:Addressing xmlns:wsam="
> > http://www.w3.org/2007/01/addressing/metadata">
> > <wsp:Policy/>
> > </wsam:Addressing>
> > </wsp:Policy>
> > </wsp:PolicyAttachment>
> > </attachments>
> >
> > This is part of the policy system tests. How are you configuring your
> > service right now? Via the API? Via Spring?
> > - Dan
> >
> > On 4/20/07, Christopher Moesel < Christopher_Moesel@avid.com> wrote:
> > >
> > > A Quick Update:
> > >
> > > I moved the bean configurations from the
> > > META-INF/cxf/cxf-extension-mtom-policy.xml file to my service's own
> > > Spring configuration file. Now I can see that my
> > MTOMAssertionBuilder,
> > > MTOMPolicyInterceptorProvider, and MTOMPolicyInterceptors are at least
> > > instantiated (which is further than I got before).
> > >
> > > But, the handleMessage method on my MTOMPolicyInterceptor is never
> > > called when I make a request to the service, so something still
> > doesn't
> > > seem to be registered right.
> > >
> > > So two questions now:
> > >
> > > 1) Why wasn't my META-INF/cxf/cxf-extension-mtom-policy.xml file
> > never
> > > loaded by the framework?
> > >
> > > 2) How do I get my service to actually build those assertions and
> > > intercept the messages?
> > >
> > > Thanks,
> > > Chris
> > >
> > > -----Original Message-----
> > > From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
> > > Sent: Friday, April 20, 2007 2:40 PM
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Questions While Implementing MTOM Policy
> > >
> > > Hello,
> > >
> > > I'm trying to implement a plugin for the MTOM Policy specification.
> > > This is essentially a policy that states whether or not MTOM should be
> >
> > > used (or is optional). I intend on contributing it back to CXF, so I
> > > figure I'm OK sending this to the dev list. ;)
> > >
> > > I've created a MTOMAssertionBuilder that uses PrimitiveAssertions, a
> > > MTOMPolicyInterceptor (that at this point just prints out if it is
> > > asserted), and a MTOMPolicyInterceptorProvider.
> > >
> > > I've registered the MTOMAssertionBuilder and
> > > MTOMPolicyInterceptorProvider in
> > > META-INF/cxf/cxf-extension-mtom-policy.xml and created a corresponding
> > > META-INF/cxf/cxf.extension file. According to the documentation, this
> > > is all that is needed to register them in CXF.
> > >
> > > When I try my service (that has the ws-policy and ws-mtom-policy jars
> > in
> > > its classpath), none of my MTOM policy classes seem to be called. Do
> > I
> > > need to do something else to register them with my service, or is
> > having
> > > the policy assertion in the port of my WSDL file enough? It seems I
> > > must be missing something important.
> > >
> > > If it would be helpful, I can zip up the module and send it along.
> > >
> > > Thanks!
> > > Chris
> > >
> >
> >
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Questions While Implementing MTOM Policy
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi Christopher,
It sounds like a possible bug. The normalization logic looks right (for my
inexperienced eyes). It only adds a second All if optional is false. Do you
know where optional gets set to false? Only place I see that called is
JaxbAssertionBuilder:104...
I'm not sure if you're doing this in your own build or within in the CXF
build, but you could possibly send a patch along and I'll try to take a
peek. Or, you can take a gander at fixing normalization yourself. I'll be
honest, I'm not that familiar with how normalization works yet in CXF, but
I'll see if I can help.
- Dan
On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
>
> I fit in a little more work... It's almost their, except that even
> though I set my policy assertion to wsp:Optional="true", by the time it
> makes it to the interceptor, the optional attribute is false.
>
> If I debug, I can see that when the PrimitiveAssertion is built, it
> correctly sets the "optional" attribute to true. But somewhere down the
> line, the assertion is "normalized" and the optional flag gets reset to
> false. This appears to be happening in the PrimitiveAssertion.normalize
> method. The PolicyComponent returned is an ExactlyOne that contains two
> Alls. The first All has a PrimitiveAssertion with optional set to
> false. The second All is empty.
>
> Is this the intended behavior? Is this a translation of optional=true
> to an ExactlyOne with one required Assertion and one empty Assertion?
> If so, how can I tell the difference between that and optional=false
> from within an interceptor?
>
> Or does that question not even make sense? ;)
>
> -Chris
>
> -----Original Message-----
> From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
> Sent: Friday, April 20, 2007 4:16 PM
> To: cxf-dev@incubator.apache.org
> Subject: RE: Questions While Implementing MTOM Policy
>
> Thanks Dan-- that information has helped me get a bit further. I'm
> afraid I won't be able to do any more work on it until Monday though...
> I'll let you know how things are going...
>
> -Chris
>
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Friday, April 20, 2007 3:15 PM
> To: cxf-dev@incubator.apache.org
> Subject: Re: Questions While Implementing MTOM Policy
>
> Hi Christopher,
>
> A zip of the module or a paste of the interceptor, mtom-policy.xml file,
> and
> interceptor provider would be extremely helpful.
>
> Re question #2 - is your question how do I apply this mtom policy to my
> service? I think the two mechanisms we have right now are WSDL Policy
> Attachments and creating an external policy. I'm working on a third
> where we
> can embed it in an <endpoint>/<client> configuration.
>
> Here's a small example of how to load an external policy file:
>
> <bean class="
> org.apache.cxf.ws.policy.attachment.external.ExternalAttachmentProvider"
> >
> <constructor-arg ref="cxf"/>
> <property name="location"
> value="org/apache/cxf/systest/ws/policy/addr-external.xml"/>
> </bean>
>
> And then the external file:
>
> <attachments xmlns:wsp="http://www.w3.org/2006/07/ws-policy" xmlns:wsa="
> http://www.w3.org/2005/08/addressing">
> <wsp:PolicyAttachment>
> <wsp:AppliesTo>
> <wsa:EndpointReference>
>
> <wsa:Address>http://localhost:9020/SoapContext/GreeterPort
> </wsa:Address>
> </wsa:EndpointReference>
> </wsp:AppliesTo>
> <wsp:Policy>
> <wsam:Addressing xmlns:wsam="
> http://www.w3.org/2007/01/addressing/metadata">
> <wsp:Policy/>
> </wsam:Addressing>
> </wsp:Policy>
> </wsp:PolicyAttachment>
> </attachments>
>
> This is part of the policy system tests. How are you configuring your
> service right now? Via the API? Via Spring?
> - Dan
>
> On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
> >
> > A Quick Update:
> >
> > I moved the bean configurations from the
> > META-INF/cxf/cxf-extension-mtom-policy.xml file to my service's own
> > Spring configuration file. Now I can see that my
> MTOMAssertionBuilder,
> > MTOMPolicyInterceptorProvider, and MTOMPolicyInterceptors are at least
> > instantiated (which is further than I got before).
> >
> > But, the handleMessage method on my MTOMPolicyInterceptor is never
> > called when I make a request to the service, so something still
> doesn't
> > seem to be registered right.
> >
> > So two questions now:
> >
> > 1) Why wasn't my META-INF/cxf/cxf-extension-mtom-policy.xml file
> never
> > loaded by the framework?
> >
> > 2) How do I get my service to actually build those assertions and
> > intercept the messages?
> >
> > Thanks,
> > Chris
> >
> > -----Original Message-----
> > From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
> > Sent: Friday, April 20, 2007 2:40 PM
> > To: cxf-dev@incubator.apache.org
> > Subject: Questions While Implementing MTOM Policy
> >
> > Hello,
> >
> > I'm trying to implement a plugin for the MTOM Policy specification.
> > This is essentially a policy that states whether or not MTOM should be
> > used (or is optional). I intend on contributing it back to CXF, so I
> > figure I'm OK sending this to the dev list. ;)
> >
> > I've created a MTOMAssertionBuilder that uses PrimitiveAssertions, a
> > MTOMPolicyInterceptor (that at this point just prints out if it is
> > asserted), and a MTOMPolicyInterceptorProvider.
> >
> > I've registered the MTOMAssertionBuilder and
> > MTOMPolicyInterceptorProvider in
> > META-INF/cxf/cxf-extension-mtom-policy.xml and created a corresponding
> > META-INF/cxf/cxf.extension file. According to the documentation, this
> > is all that is needed to register them in CXF.
> >
> > When I try my service (that has the ws-policy and ws-mtom-policy jars
> in
> > its classpath), none of my MTOM policy classes seem to be called. Do
> I
> > need to do something else to register them with my service, or is
> having
> > the policy assertion in the port of my WSDL file enough? It seems I
> > must be missing something important.
> >
> > If it would be helpful, I can zip up the module and send it along.
> >
> > Thanks!
> > Chris
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Questions While Implementing MTOM Policy
Posted by Christopher Moesel <Ch...@avid.com>.
I fit in a little more work... It's almost their, except that even
though I set my policy assertion to wsp:Optional="true", by the time it
makes it to the interceptor, the optional attribute is false.
If I debug, I can see that when the PrimitiveAssertion is built, it
correctly sets the "optional" attribute to true. But somewhere down the
line, the assertion is "normalized" and the optional flag gets reset to
false. This appears to be happening in the PrimitiveAssertion.normalize
method. The PolicyComponent returned is an ExactlyOne that contains two
Alls. The first All has a PrimitiveAssertion with optional set to
false. The second All is empty.
Is this the intended behavior? Is this a translation of optional=true
to an ExactlyOne with one required Assertion and one empty Assertion?
If so, how can I tell the difference between that and optional=false
from within an interceptor?
Or does that question not even make sense? ;)
-Chris
-----Original Message-----
From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
Sent: Friday, April 20, 2007 4:16 PM
To: cxf-dev@incubator.apache.org
Subject: RE: Questions While Implementing MTOM Policy
Thanks Dan-- that information has helped me get a bit further. I'm
afraid I won't be able to do any more work on it until Monday though...
I'll let you know how things are going...
-Chris
-----Original Message-----
From: Dan Diephouse [mailto:dan@envoisolutions.com]
Sent: Friday, April 20, 2007 3:15 PM
To: cxf-dev@incubator.apache.org
Subject: Re: Questions While Implementing MTOM Policy
Hi Christopher,
A zip of the module or a paste of the interceptor, mtom-policy.xml file,
and
interceptor provider would be extremely helpful.
Re question #2 - is your question how do I apply this mtom policy to my
service? I think the two mechanisms we have right now are WSDL Policy
Attachments and creating an external policy. I'm working on a third
where we
can embed it in an <endpoint>/<client> configuration.
Here's a small example of how to load an external policy file:
<bean class="
org.apache.cxf.ws.policy.attachment.external.ExternalAttachmentProvider"
>
<constructor-arg ref="cxf"/>
<property name="location"
value="org/apache/cxf/systest/ws/policy/addr-external.xml"/>
</bean>
And then the external file:
<attachments xmlns:wsp="http://www.w3.org/2006/07/ws-policy" xmlns:wsa="
http://www.w3.org/2005/08/addressing">
<wsp:PolicyAttachment>
<wsp:AppliesTo>
<wsa:EndpointReference>
<wsa:Address>http://localhost:9020/SoapContext/GreeterPort
</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wsp:Policy>
<wsam:Addressing xmlns:wsam="
http://www.w3.org/2007/01/addressing/metadata">
<wsp:Policy/>
</wsam:Addressing>
</wsp:Policy>
</wsp:PolicyAttachment>
</attachments>
This is part of the policy system tests. How are you configuring your
service right now? Via the API? Via Spring?
- Dan
On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
>
> A Quick Update:
>
> I moved the bean configurations from the
> META-INF/cxf/cxf-extension-mtom-policy.xml file to my service's own
> Spring configuration file. Now I can see that my
MTOMAssertionBuilder,
> MTOMPolicyInterceptorProvider, and MTOMPolicyInterceptors are at least
> instantiated (which is further than I got before).
>
> But, the handleMessage method on my MTOMPolicyInterceptor is never
> called when I make a request to the service, so something still
doesn't
> seem to be registered right.
>
> So two questions now:
>
> 1) Why wasn't my META-INF/cxf/cxf-extension-mtom-policy.xml file
never
> loaded by the framework?
>
> 2) How do I get my service to actually build those assertions and
> intercept the messages?
>
> Thanks,
> Chris
>
> -----Original Message-----
> From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
> Sent: Friday, April 20, 2007 2:40 PM
> To: cxf-dev@incubator.apache.org
> Subject: Questions While Implementing MTOM Policy
>
> Hello,
>
> I'm trying to implement a plugin for the MTOM Policy specification.
> This is essentially a policy that states whether or not MTOM should be
> used (or is optional). I intend on contributing it back to CXF, so I
> figure I'm OK sending this to the dev list. ;)
>
> I've created a MTOMAssertionBuilder that uses PrimitiveAssertions, a
> MTOMPolicyInterceptor (that at this point just prints out if it is
> asserted), and a MTOMPolicyInterceptorProvider.
>
> I've registered the MTOMAssertionBuilder and
> MTOMPolicyInterceptorProvider in
> META-INF/cxf/cxf-extension-mtom-policy.xml and created a corresponding
> META-INF/cxf/cxf.extension file. According to the documentation, this
> is all that is needed to register them in CXF.
>
> When I try my service (that has the ws-policy and ws-mtom-policy jars
in
> its classpath), none of my MTOM policy classes seem to be called. Do
I
> need to do something else to register them with my service, or is
having
> the policy assertion in the port of my WSDL file enough? It seems I
> must be missing something important.
>
> If it would be helpful, I can zip up the module and send it along.
>
> Thanks!
> Chris
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Questions While Implementing MTOM Policy
Posted by Christopher Moesel <Ch...@avid.com>.
Thanks Dan-- that information has helped me get a bit further. I'm
afraid I won't be able to do any more work on it until Monday though...
I'll let you know how things are going...
-Chris
-----Original Message-----
From: Dan Diephouse [mailto:dan@envoisolutions.com]
Sent: Friday, April 20, 2007 3:15 PM
To: cxf-dev@incubator.apache.org
Subject: Re: Questions While Implementing MTOM Policy
Hi Christopher,
A zip of the module or a paste of the interceptor, mtom-policy.xml file,
and
interceptor provider would be extremely helpful.
Re question #2 - is your question how do I apply this mtom policy to my
service? I think the two mechanisms we have right now are WSDL Policy
Attachments and creating an external policy. I'm working on a third
where we
can embed it in an <endpoint>/<client> configuration.
Here's a small example of how to load an external policy file:
<bean class="
org.apache.cxf.ws.policy.attachment.external.ExternalAttachmentProvider"
>
<constructor-arg ref="cxf"/>
<property name="location"
value="org/apache/cxf/systest/ws/policy/addr-external.xml"/>
</bean>
And then the external file:
<attachments xmlns:wsp="http://www.w3.org/2006/07/ws-policy" xmlns:wsa="
http://www.w3.org/2005/08/addressing">
<wsp:PolicyAttachment>
<wsp:AppliesTo>
<wsa:EndpointReference>
<wsa:Address>http://localhost:9020/SoapContext/GreeterPort
</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wsp:Policy>
<wsam:Addressing xmlns:wsam="
http://www.w3.org/2007/01/addressing/metadata">
<wsp:Policy/>
</wsam:Addressing>
</wsp:Policy>
</wsp:PolicyAttachment>
</attachments>
This is part of the policy system tests. How are you configuring your
service right now? Via the API? Via Spring?
- Dan
On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
>
> A Quick Update:
>
> I moved the bean configurations from the
> META-INF/cxf/cxf-extension-mtom-policy.xml file to my service's own
> Spring configuration file. Now I can see that my
MTOMAssertionBuilder,
> MTOMPolicyInterceptorProvider, and MTOMPolicyInterceptors are at least
> instantiated (which is further than I got before).
>
> But, the handleMessage method on my MTOMPolicyInterceptor is never
> called when I make a request to the service, so something still
doesn't
> seem to be registered right.
>
> So two questions now:
>
> 1) Why wasn't my META-INF/cxf/cxf-extension-mtom-policy.xml file
never
> loaded by the framework?
>
> 2) How do I get my service to actually build those assertions and
> intercept the messages?
>
> Thanks,
> Chris
>
> -----Original Message-----
> From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
> Sent: Friday, April 20, 2007 2:40 PM
> To: cxf-dev@incubator.apache.org
> Subject: Questions While Implementing MTOM Policy
>
> Hello,
>
> I'm trying to implement a plugin for the MTOM Policy specification.
> This is essentially a policy that states whether or not MTOM should be
> used (or is optional). I intend on contributing it back to CXF, so I
> figure I'm OK sending this to the dev list. ;)
>
> I've created a MTOMAssertionBuilder that uses PrimitiveAssertions, a
> MTOMPolicyInterceptor (that at this point just prints out if it is
> asserted), and a MTOMPolicyInterceptorProvider.
>
> I've registered the MTOMAssertionBuilder and
> MTOMPolicyInterceptorProvider in
> META-INF/cxf/cxf-extension-mtom-policy.xml and created a corresponding
> META-INF/cxf/cxf.extension file. According to the documentation, this
> is all that is needed to register them in CXF.
>
> When I try my service (that has the ws-policy and ws-mtom-policy jars
in
> its classpath), none of my MTOM policy classes seem to be called. Do
I
> need to do something else to register them with my service, or is
having
> the policy assertion in the port of my WSDL file enough? It seems I
> must be missing something important.
>
> If it would be helpful, I can zip up the module and send it along.
>
> Thanks!
> Chris
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Questions While Implementing MTOM Policy
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi Christopher,
A zip of the module or a paste of the interceptor, mtom-policy.xml file, and
interceptor provider would be extremely helpful.
Re question #2 - is your question how do I apply this mtom policy to my
service? I think the two mechanisms we have right now are WSDL Policy
Attachments and creating an external policy. I'm working on a third where we
can embed it in an <endpoint>/<client> configuration.
Here's a small example of how to load an external policy file:
<bean class="
org.apache.cxf.ws.policy.attachment.external.ExternalAttachmentProvider">
<constructor-arg ref="cxf"/>
<property name="location"
value="org/apache/cxf/systest/ws/policy/addr-external.xml"/>
</bean>
And then the external file:
<attachments xmlns:wsp="http://www.w3.org/2006/07/ws-policy" xmlns:wsa="
http://www.w3.org/2005/08/addressing">
<wsp:PolicyAttachment>
<wsp:AppliesTo>
<wsa:EndpointReference>
<wsa:Address>http://localhost:9020/SoapContext/GreeterPort
</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wsp:Policy>
<wsam:Addressing xmlns:wsam="
http://www.w3.org/2007/01/addressing/metadata">
<wsp:Policy/>
</wsam:Addressing>
</wsp:Policy>
</wsp:PolicyAttachment>
</attachments>
This is part of the policy system tests. How are you configuring your
service right now? Via the API? Via Spring?
- Dan
On 4/20/07, Christopher Moesel <Ch...@avid.com> wrote:
>
> A Quick Update:
>
> I moved the bean configurations from the
> META-INF/cxf/cxf-extension-mtom-policy.xml file to my service's own
> Spring configuration file. Now I can see that my MTOMAssertionBuilder,
> MTOMPolicyInterceptorProvider, and MTOMPolicyInterceptors are at least
> instantiated (which is further than I got before).
>
> But, the handleMessage method on my MTOMPolicyInterceptor is never
> called when I make a request to the service, so something still doesn't
> seem to be registered right.
>
> So two questions now:
>
> 1) Why wasn't my META-INF/cxf/cxf-extension-mtom-policy.xml file never
> loaded by the framework?
>
> 2) How do I get my service to actually build those assertions and
> intercept the messages?
>
> Thanks,
> Chris
>
> -----Original Message-----
> From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
> Sent: Friday, April 20, 2007 2:40 PM
> To: cxf-dev@incubator.apache.org
> Subject: Questions While Implementing MTOM Policy
>
> Hello,
>
> I'm trying to implement a plugin for the MTOM Policy specification.
> This is essentially a policy that states whether or not MTOM should be
> used (or is optional). I intend on contributing it back to CXF, so I
> figure I'm OK sending this to the dev list. ;)
>
> I've created a MTOMAssertionBuilder that uses PrimitiveAssertions, a
> MTOMPolicyInterceptor (that at this point just prints out if it is
> asserted), and a MTOMPolicyInterceptorProvider.
>
> I've registered the MTOMAssertionBuilder and
> MTOMPolicyInterceptorProvider in
> META-INF/cxf/cxf-extension-mtom-policy.xml and created a corresponding
> META-INF/cxf/cxf.extension file. According to the documentation, this
> is all that is needed to register them in CXF.
>
> When I try my service (that has the ws-policy and ws-mtom-policy jars in
> its classpath), none of my MTOM policy classes seem to be called. Do I
> need to do something else to register them with my service, or is having
> the policy assertion in the port of my WSDL file enough? It seems I
> must be missing something important.
>
> If it would be helpful, I can zip up the module and send it along.
>
> Thanks!
> Chris
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Questions While Implementing MTOM Policy
Posted by Christopher Moesel <Ch...@avid.com>.
A Quick Update:
I moved the bean configurations from the
META-INF/cxf/cxf-extension-mtom-policy.xml file to my service's own
Spring configuration file. Now I can see that my MTOMAssertionBuilder,
MTOMPolicyInterceptorProvider, and MTOMPolicyInterceptors are at least
instantiated (which is further than I got before).
But, the handleMessage method on my MTOMPolicyInterceptor is never
called when I make a request to the service, so something still doesn't
seem to be registered right.
So two questions now:
1) Why wasn't my META-INF/cxf/cxf-extension-mtom-policy.xml file never
loaded by the framework?
2) How do I get my service to actually build those assertions and
intercept the messages?
Thanks,
Chris
-----Original Message-----
From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
Sent: Friday, April 20, 2007 2:40 PM
To: cxf-dev@incubator.apache.org
Subject: Questions While Implementing MTOM Policy
Hello,
I'm trying to implement a plugin for the MTOM Policy specification.
This is essentially a policy that states whether or not MTOM should be
used (or is optional). I intend on contributing it back to CXF, so I
figure I'm OK sending this to the dev list. ;)
I've created a MTOMAssertionBuilder that uses PrimitiveAssertions, a
MTOMPolicyInterceptor (that at this point just prints out if it is
asserted), and a MTOMPolicyInterceptorProvider.
I've registered the MTOMAssertionBuilder and
MTOMPolicyInterceptorProvider in
META-INF/cxf/cxf-extension-mtom-policy.xml and created a corresponding
META-INF/cxf/cxf.extension file. According to the documentation, this
is all that is needed to register them in CXF.
When I try my service (that has the ws-policy and ws-mtom-policy jars in
its classpath), none of my MTOM policy classes seem to be called. Do I
need to do something else to register them with my service, or is having
the policy assertion in the port of my WSDL file enough? It seems I
must be missing something important.
If it would be helpful, I can zip up the module and send it along.
Thanks!
Chris