Joseph Hwang commented on JBWS-3648:
Dear, Alessio! I solved my client-issue with your advice.
But, this time I am struggling with server-side signature and encryption.
@EndpointConfig annotation in my server class does not work.
Pls, check this issue, https://community.jboss.org/thread/232031
WS-Policy code-first improvements
Project: JBoss Web Services
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: jbossws-cxf, productivity
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Fix For: jbossws-cxf-4.2
I'd like to see some kind of ws-policy oriented tooling in JBossWS. Ideally we should
provide some mechanisms for basic code-first development; currently stuff like ws-security
configuration through policies is actually contract based: the user is expected to either
provide a wsdl with proper policies or to use policy attachment, which is basically the
same, writing the actual policy assertion is required.
An idea could be to have a group of pre-defined policy assertions' sets for known
scenarios (for ws-security those could be based e.g. on the Oasis WS-Security Policy
Examples ). Each set would be composed of 'placement points' with a policy to
be attached at each of those points. We'd then possibly have a custom CXF
FactoryBeanListener to be registered in the FactoryBeanListenerManager; the new listener
would perform something similar to what the PolicyAnnotationListener does (based on the
@Policies/@Policy in the code), that is attaching policies to the proper attach points. An
additional step would be to support merging (effective policy through Neethi?) multiple
sets at the same time (say, you want e.g. a specific ws-security set plus a ws-rm set).
With such thing, we could provide the initial sets and let users pick the sets they want
for a given endpoint (perhaps through a custom annotation, or possibly better specifying
the sets' names within a property in a selected Endpoint Config).
The initial policy sets could be stored as xml files in one of the jbossws-cxf jars and
we could provide a mechanism for reading additional ones from the current classpath (to
let users add additional ones).
Finally, this would open up to further tooling improvements; e.g. 1) wsprovide could be
enhanced to process the @EndpointConfig annotation, get the policy sets and produce a
ws-policy enabled wsdl, 2) we could even provide an 'educational' gui tool
showing assertions enabled/disabled depending on the selected sets, etc.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira