[
https://issues.apache.org/jira/browse/WSCOMMONS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719096#action_12719096
]
Konrad K edited comment on WSCOMMONS-299 at 6/13/09 1:24 AM:
-------------------------------------------------------------
Indeed ... But let me explain my motivation first...
In my project, we need to generate policies based on parameters given at a
frontend. Therefore I tried out Metro's policy library but it has the following
disadvantages:
- PolicyAssertion subclasses aren't easy to reuse. For instance i need an
"Issuer" assertion with an wsa:EndpointReferenceType inside. But the class is
missing a convenient constructor or a setter to do so.
- Something which is also quite annoying are the two object models for
policies, namely a source and a normal one. Thus serializing includes lots of
transformation code.
- In the normal model most classes are immutable. Thus I had to package all my
assertions into collections before passing them to an operator. Afterwards I
had to package all my operators before creating a policy. As a result, I have
to generate my policy backwards.
- Its object model doesn't reflect the policy specification as good as Neethi
does.
Neethi adopts the composite pattern and generating a policy looks naturally in
the code. Also CXF's assertions seem to be cool initially, but they have some
mistakes (see http://issues.apache.org/jira/browse/CXF-2282). Another problem
is that they don't implement WS-SecurityPolicy to the letter. I wasn't able to
pass my whole EndpointReference to this setter:
setIssuerEpr(org.w3c.dom.Element issuerEpr), because I might have a wsa:Address
and but also a Metadata element, which need to be direct childs of the Issuer
Assertion. In the end I implemented most Assertions again.
Summarizing my experience i came to the following conclusions:
- The implementation of standardized assertions should be a part of Neethi and
the enforcement of them should be a part of CXF. That would enable people like
me to reuse assertions, as they are specified.
- It would also be nice to support WS-Policy 1.5 ... but currently we can't
switch the policy version consistently, because the serialize methods have
opaque nested policies.
was (Author: creme-fresh):
Indeed ... But let me explain my motivation first...
In my project, we need to generate policies based on parameters given at a
frontend. Therefore I tried out Metro's policy library but it has the following
disadvantages:
- PolicyAssertion subclasses aren't easy to reuse. For instance i need an
"Issuer" assertion with an wsa:EndpointReferenceType inside. But the class is
missing a convenient constructor or a setter to do so.
- Something which is also quite annoying are the two object models for
policies, namely a source and a normal one. Thus serializing includes lots of
transformation code.
- In the normal model most classes are immutable. Thus I had to package all my
assertions into collections before passing them to an operator. Afterwards I
had to package all my operators before creating a policy. As a result, I have
to generate my policy backwards.
- Its object model doesn't reflect the policy specification as good as Neethi
does.
Neethi adopts the composite pattern and generating a policy looks naturally in
the code. Also CXF's assertions seem to be cool initially, but they have some
mistakes (see http://issues.apache.org/jira/browse/CXF-2282). Another problem
is that they don't implement WS-SecurityPolicy to the letter. I wasn't able to
pass my whole EndpointReference to this setter:
setIssuerEpr(org.w3c.dom.Element issuerEpr), because I might have a wsa:Address
and but also a Metadata element, which need to be direct childs of the Issuer
Assertion. In the end I implemented most Assertions again.
Summarizing my experience i came to the following conclusions:
- CXF's Assertions have too much duplicate code ... also because of the
Assertion interface design
- The implementation of standardized assertions should be a part of Neethi and
the enforcement of them should be a part of CXF. That would enable people like
me to reuse assertions, as they are specified.
- It would also be nice to support WS-Policy 1.5 ... but currently we can't
switch the policy version consistently, because the serialize methods have
opaque nested policies.
> Policy intersection is not yet implemented
> ------------------------------------------
>
> Key: WSCOMMONS-299
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-299
> Project: WS-Commons
> Issue Type: Bug
> Components: Policy
> Reporter: Tammo van Lessen
> Attachments: patch.txt, patch2.txt
>
>
> Intersection is crucial for testing compatibility. It was already implemented
> it one of the earlier versions but got somehow lost...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
