You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@cxf.apache.org by Josh Hill <Jo...@finzsoft.com> on 2013/05/20 08:42:14 UTC

Dynamic policies using spring properties

I annotate my web services with one class level policy and two per method to take advantage of the placement attribute (see Fig 1). I would like to set the policy's uri as a spring property (see Fig 2).

My first solution was to use an custom policy in/out interceptor to read the @Policy annotation's uri and if surround with "${}" then build a dynamic policy using Neethi and set it to PolicyConstants.POLICY_OVERRIDE. A problem I encountered with this approach is that I need to attach three different policies using different placements. Merging them may be a last resort option.

A temporary hack would be to alter org.apache.cxf.resource.ExtendedURIResolver.resolve() to resolve a uri surrounded with "${}" to a spring property. I'm hoping someone here can suggest a better solution.

Any thoughts

Fig 1.
@WebService
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use = SOAPBinding.Use.LITERAL)
@Policy(uri = "classpath:/policy/service.policy", placement = Policy.Placement.SERVICE)
public interface ProductWS {

    @WebMethod
    @WebResult(name = "product-wsresponse")
    @Policies({
            @Policy(uri = "classpath:/policy/service-input.policy", placement = Policy.Placement.BINDING_OPERATION_INPUT),
            @Policy(uri = "classpath:/policy/service-output.policy", placement = Policy.Placement.BINDING_OPERATION_OUTPUT)
    })
    ProductResponseMessage products(@WebParam(name = "product-wsrequest") ProductRequestMessage productRequestMessage);
}

Fig 2.
@WebService
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use = SOAPBinding.Use.LITERAL)
@Policy(uri = "${product.service.policy}", placement = Policy.Placement.SERVICE)
public interface ProductWS {

    @WebMethod
    @WebResult(name = "product-wsresponse")
    @Policies({
            @Policy(uri = "${product.service.input.policy}", placement = Policy.Placement.BINDING_OPERATION_INPUT),
            @Policy(uri = "${product.service.output.policy}", placement = Policy.Placement.BINDING_OPERATION_OUTPUT)
    })
    ProductResponseMessage products(@WebParam(name = "product-wsrequest") ProductRequestMessage productRequestMessage);
}



Josh Hill
Senior Java Developer



[cid:imagea80aa5.png@f27a0f82.ae304923]



sovereign finance and banking software



A Level 1, Building C, Millennium Centre, 602 Great South Road, Greenlane, Auckland, New Zealand
D 64 9 571 6812       P 64 9 571 6800    F 64 9 571 6899
E Josh.Hill@finzsoft.com    W www.finzsoft.com<http://www.finzsoft.com>


Please note: This email contains information that is confidential and may be privileged. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this email or attachments. If you have received this in error, please notify Finzsoft Solutions (New Zealand) Ltd immediately by return email and delete this email. Thank you.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________

Re: Dynamic policies using spring properties

Posted by Jason Pell <ja...@pellcorp.com>.

The PolicyAnnotationListener
(rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/PolicyAnnotationListener.java)
is where you would probably be looking at to add actual dynamic support as
discussed above.




On Tue, May 21, 2013 at 9:08 PM, Jason Pell <ja...@pellcorp.com> wrote:

> Hi,
>
> Not sure if this will suffice, but you can reference spring bean id's in
> java first @Policy annotations, for example:
>
>
> https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/main/java/com/pellcorp/server/security/SecuritySimpleServiceImpl.java
>
> See that I have used:
>
> @Policy(uri="#UsernamePasswordPolicy",
>
> Which has been defined here:
>
>
> https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/main/resources/UsernamePasswordPolicy.xml
>
> You can then import your policies into your spring context, see for
> example:
>
>
> https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/main/resources/META-INF/applicationContext.xml
>
> What I then do if I want to vary the policy definition is have different
> spring xml files all with the same # bean id, and based on spring
> properties import the correct one.
>
> <import resource="${security.policy.file}" />
>
> It does not give you actual dynamic based on spring properties, but if you
> can define 3 bean names and then have various different spring files that
> each define those three, you can configure which to import.
>
>
>
> On Mon, May 20, 2013 at 4:42 PM, Josh Hill <Jo...@finzsoft.com> wrote:
>
>>  I annotate my web services with one class level policy and two per
>> method to take advantage of the placement attribute (see Fig 1). I would
>> like to set the policy’s uri as a spring property (see Fig 2). ****
>>
>> ** **
>>
>> My first solution was to use an custom policy in/out interceptor to read
>> the @Policy annotation’s uri and if surround with “${}” then build a
>> dynamic policy using Neethi and set it to PolicyConstants.POLICY_OVERRIDE.
>> A problem I encountered with this approach is that I need to attach three
>> different policies using different placements. Merging them may be a last
>> resort option.****
>>
>> ** **
>>
>> A temporary hack would be to alter
>> org.apache.cxf.resource.ExtendedURIResolver.resolve() to resolve a uri
>> surrounded with “${}” to a spring property. I’m hoping someone here can
>> suggest a better solution.****
>>
>> ** **
>>
>> Any thoughts****
>>
>> ** **
>>
>> Fig 1.****
>>
>> @WebService****
>>
>> @SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use =
>> SOAPBinding.Use.LITERAL)****
>>
>> @Policy(uri = "classpath:/policy/service.policy", placement =
>> Policy.Placement.SERVICE)****
>>
>> public interface ProductWS {****
>>
>> ** **
>>
>>     @WebMethod****
>>
>>     @WebResult(name = "product-wsresponse")****
>>
>>     @Policies({****
>>
>>             @Policy(uri = "classpath:/policy/service-input.policy",
>> placement = Policy.Placement.BINDING_OPERATION_INPUT),****
>>
>>             @Policy(uri = "classpath:/policy/service-output.policy",
>> placement = Policy.Placement.BINDING_OPERATION_OUTPUT)****
>>
>>     })****
>>
>>     ProductResponseMessage products(@WebParam(name = "product-wsrequest")
>> ProductRequestMessage productRequestMessage);****
>>
>> }****
>>
>> ** **
>>
>> Fig 2.****
>>
>> @WebService****
>>
>> @SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use =
>> SOAPBinding.Use.LITERAL)****
>>
>> @Policy(uri = "${product.service.policy}", placement =
>> Policy.Placement.SERVICE)****
>>
>> public interface ProductWS {****
>>
>> ** **
>>
>>     @WebMethod****
>>
>>     @WebResult(name = "product-wsresponse")****
>>
>>     @Policies({****
>>
>>             @Policy(uri = "${product.service.input.policy}", placement =
>> Policy.Placement.BINDING_OPERATION_INPUT),****
>>
>>             @Policy(uri = "${product.service.output.policy}", placement =
>> Policy.Placement.BINDING_OPERATION_OUTPUT)****
>>
>>     })****
>>
>>     ProductResponseMessage products(@WebParam(name = "product-wsrequest")
>> ProductRequestMessage productRequestMessage);****
>>
>> } ****
>>
>>
>>
>> *Josh Hill*
>> Senior Java Developer
>>
>>
>>
>> [image: Finzsoft - Your Vision + Our Innovations]
>>
>>
>>
>> sovereign finance and banking software
>>
>>
>>
>> *A* Level 1, Building C, Millennium Centre, 602 Great South Road,
>> Greenlane, Auckland, New Zealand
>> *D* 64 9 571 6812       *P* 64 9 571 6800    *F* 64 9 571 6899
>> *E* Josh.Hill@finzsoft.com    *W* www.finzsoft.com
>>
>>
>>       *Please note*: This email contains information that is
>> confidential and may be privileged. If you are not the intended recipient, you
>> must not peruse, use, disseminate, distribute or copy this email or
>> attachments. If you have received this in error, please notify Finzsoft
>> Solutions (New Zealand) Ltd immediately by return email and delete this
>> email. Thank you.
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the Symantec Email Security.cloud service.
>> ______________________________________________________________________
>>
>
>

Re: Dynamic policies using spring properties

Posted by Jason Pell <ja...@pellcorp.com>.

Hi,

Not sure if this will suffice, but you can reference spring bean id's in
java first @Policy annotations, for example:

https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/main/java/com/pellcorp/server/security/SecuritySimpleServiceImpl.java

See that I have used:

@Policy(uri="#UsernamePasswordPolicy",

Which has been defined here:

https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/main/resources/UsernamePasswordPolicy.xml

You can then import your policies into your spring context, see for example:

https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/main/resources/META-INF/applicationContext.xml

What I then do if I want to vary the policy definition is have different
spring xml files all with the same # bean id, and based on spring
properties import the correct one.

<import resource="${security.policy.file}" />

It does not give you actual dynamic based on spring properties, but if you
can define 3 bean names and then have various different spring files that
each define those three, you can configure which to import.



On Mon, May 20, 2013 at 4:42 PM, Josh Hill <Jo...@finzsoft.com> wrote:

>  I annotate my web services with one class level policy and two per
> method to take advantage of the placement attribute (see Fig 1). I would
> like to set the policy’s uri as a spring property (see Fig 2). ****
>
> ** **
>
> My first solution was to use an custom policy in/out interceptor to read
> the @Policy annotation’s uri and if surround with “${}” then build a
> dynamic policy using Neethi and set it to PolicyConstants.POLICY_OVERRIDE.
> A problem I encountered with this approach is that I need to attach three
> different policies using different placements. Merging them may be a last
> resort option.****
>
> ** **
>
> A temporary hack would be to alter
> org.apache.cxf.resource.ExtendedURIResolver.resolve() to resolve a uri
> surrounded with “${}” to a spring property. I’m hoping someone here can
> suggest a better solution.****
>
> ** **
>
> Any thoughts****
>
> ** **
>
> Fig 1.****
>
> @WebService****
>
> @SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use =
> SOAPBinding.Use.LITERAL)****
>
> @Policy(uri = "classpath:/policy/service.policy", placement =
> Policy.Placement.SERVICE)****
>
> public interface ProductWS {****
>
> ** **
>
>     @WebMethod****
>
>     @WebResult(name = "product-wsresponse")****
>
>     @Policies({****
>
>             @Policy(uri = "classpath:/policy/service-input.policy",
> placement = Policy.Placement.BINDING_OPERATION_INPUT),****
>
>             @Policy(uri = "classpath:/policy/service-output.policy",
> placement = Policy.Placement.BINDING_OPERATION_OUTPUT)****
>
>     })****
>
>     ProductResponseMessage products(@WebParam(name = "product-wsrequest")
> ProductRequestMessage productRequestMessage);****
>
> }****
>
> ** **
>
> Fig 2.****
>
> @WebService****
>
> @SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use =
> SOAPBinding.Use.LITERAL)****
>
> @Policy(uri = "${product.service.policy}", placement =
> Policy.Placement.SERVICE)****
>
> public interface ProductWS {****
>
> ** **
>
>     @WebMethod****
>
>     @WebResult(name = "product-wsresponse")****
>
>     @Policies({****
>
>             @Policy(uri = "${product.service.input.policy}", placement =
> Policy.Placement.BINDING_OPERATION_INPUT),****
>
>             @Policy(uri = "${product.service.output.policy}", placement =
> Policy.Placement.BINDING_OPERATION_OUTPUT)****
>
>     })****
>
>     ProductResponseMessage products(@WebParam(name = "product-wsrequest")
> ProductRequestMessage productRequestMessage);****
>
> } ****
>
>
>
> *Josh Hill*
> Senior Java Developer
>
>
>
> [image: Finzsoft - Your Vision + Our Innovations]
>
>
>
> sovereign finance and banking software
>
>
>
> *A* Level 1, Building C, Millennium Centre, 602 Great South Road,
> Greenlane, Auckland, New Zealand
> *D* 64 9 571 6812       *P* 64 9 571 6800    *F* 64 9 571 6899
> *E* Josh.Hill@finzsoft.com    *W* www.finzsoft.com
>
>
>       *Please note*: This email contains information that is confidential
> and may be privileged. If you are not the intended recipient, you must
> not peruse, use, disseminate, distribute or copy this email or attachments.
> If you have received this in error, please notify Finzsoft Solutions (New
> Zealand) Ltd immediately by return email and delete this email. Thank you.
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> ______________________________________________________________________
>

RE: Dynamic policies using spring properties

Posted by Andrei Shakirin <as...@talend.com>.

Hi Josh,

>My first solution was to use an custom policy in/out interceptor to read the @Policy annotation's uri and if surround with "${}" then build a dynamic policy using Neethi and set it to >PolicyConstants.POLICY_OVERRIDE. A problem I encountered with this approach is that I need to attach three different policies using different placements. Merging them may be a last resort option.

I think, if you use PolicyConstants.POLICY_OVERRIDE, you don't need to attach policies to WSDL at all. 
Dynamic policy in PolicyConstants.POLICY_OVERRIDE will overwrite all policies in WSDL, they just will be ignored.
See the code in PolicyOutInterceptor:
        // 1. Check overridden policy
        Policy p = (Policy)msg.getContextualProperty(PolicyConstants.POLICY_OVERRIDE);
        if (p != null) {
        // Use dynamic policy
        } else if (MessageUtils.isRequestor(msg)) {
            // 2. Process client policy
         } else {
            // 3. Process service policy
         }

In your interceptor you need to load policy from somewhere, parse it with Neethi and merge if necessary. You can load policies from WSDL, from separate file, from database or remotely.
After set PolicyConstants.POLICY_OVERRIDE property only this policy will be used, all your WSDL policies are irrelevant.

>A temporary hack would be to alter org.apache.cxf.resource.ExtendedURIResolver.resolve() to resolve a uri surrounded with "${}" to a spring property. I'm hoping someone here can suggest a better solution.

This is also possible solution. The benefits of the first one (interceptor + PolicyConstants.POLICY_OVERRIDE) are:
- solution is dynamic (you can change policy for each call without restarting client/service)
- policy can be loaded from any source, not necessarily from WSDL.

It really depends on your use case.

Regards,
Andrei.

From: Josh Hill [mailto:Josh.Hill@finzsoft.com] 
Sent: Montag, 20. Mai 2013 08:42
To: users@cxf.apache.org
Subject: Dynamic policies using spring properties

I annotate my web services with one class level policy and two per method to take advantage of the placement attribute (see Fig 1). I would like to set the policy's uri as a spring property (see Fig 2). 

My first solution was to use an custom policy in/out interceptor to read the @Policy annotation's uri and if surround with "${}" then build a dynamic policy using Neethi and set it to PolicyConstants.POLICY_OVERRIDE. A problem I encountered with this approach is that I need to attach three different policies using different placements. Merging them may be a last resort option.

A temporary hack would be to alter org.apache.cxf.resource.ExtendedURIResolver.resolve() to resolve a uri surrounded with "${}" to a spring property. I'm hoping someone here can suggest a better solution.

Any thoughts

Fig 1.
@WebService
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use = SOAPBinding.Use.LITERAL)
@Policy(uri = "classpath:/policy/service.policy", placement = Policy.Placement.SERVICE)
public interface ProductWS {

    @WebMethod
    @WebResult(name = "product-wsresponse")
    @Policies({
            @Policy(uri = "classpath:/policy/service-input.policy", placement = Policy.Placement.BINDING_OPERATION_INPUT),
            @Policy(uri = "classpath:/policy/service-output.policy", placement = Policy.Placement.BINDING_OPERATION_OUTPUT)
    })
    ProductResponseMessage products(@WebParam(name = "product-wsrequest") ProductRequestMessage productRequestMessage);
}

Fig 2.
@WebService
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use = SOAPBinding.Use.LITERAL)
@Policy(uri = "${product.service.policy}", placement = Policy.Placement.SERVICE)
public interface ProductWS {

    @WebMethod
    @WebResult(name = "product-wsresponse")
    @Policies({
            @Policy(uri = "${product.service.input.policy}", placement = Policy.Placement.BINDING_OPERATION_INPUT),
            @Policy(uri = "${product.service.output.policy}", placement = Policy.Placement.BINDING_OPERATION_OUTPUT)
    })
    ProductResponseMessage products(@WebParam(name = "product-wsrequest") ProductRequestMessage productRequestMessage);
} 
 
Josh Hill 
Senior Java Developer 
 

 
sovereign finance and banking software
 
A Level 1, Building C, Millennium Centre, 602 Great South Road, Greenlane, Auckland, New Zealand
D 64 9 571 6812       P 64 9 571 6800    F 64 9 571 6899
E Josh.Hill@finzsoft.com    W www.finzsoft.com 
 
Please note: This email contains information that is confidential and may be privileged. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this email or attachments. If you have received this in error, please notify Finzsoft Solutions (New Zealand) Ltd immediately by return email and delete this email. Thank you. 

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________