You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by Bob Jacoby <bo...@gossamer-group.com> on 2008/10/21 20:35:09 UTC
Programmatically running RampartEngine
I'm trying to write some test cases to validate a custom handler. One of
the requirements of the custom handler is that the rampart receivers
first run and populate the messageContext appropriate
(WSHandlerConstants.RECV_RESULTS).
I'm trying to right test cases to validate my handler. Rather than mock
a messageContext to pass into my handler and set all the associated
properties manually, I'd like to programmatically run the portion of
rampart that generates the security header and processes the soap
message. I would then take the resultant message context and run it
through my handler.
>From looking at the sample test cases included with rampart, this seems
like it would be easy enough. I perform the following steps:
(Generate the Request Stage)
1. Create a message context similar to
rampart-tests\src\test\java\org\apache\rampart\MessageBuilderTestBase
2. Load my policy into the context similar to
rampart-tests\src\test\java\org\apache\rampart\
AsymmetricBindingBuilderTest
3. Create a MessageBuilder and build the context
MessageBuilder builder = new MessageBuilder();
builder.build(ctx);
At this step I have what appears to be a valid SOAP envelope in the
message context that's populated with the SOAP headers. Now I need to
process this SOAP message so the context is populated with the
appropriate properties (WSHandlerConstants.RECV_RESULTS).
(Process Stage)
4. Create an RampartReceiver and process the message context
5. Call my handler with the message context
However, I'm getting an error in Step 4.
java.lang.ClassCastException: org.apache.axiom.om.impl.dom.ElementImpl
incompatible with org.apache.axiom.soap.SOAPHeaderBlock
at
org.apache.rampart.RampartEngine.process(RampartEngine.java:108)
Line 108 of RampartEngine is:
SOAPHeaderBlock elem = (SOAPHeaderBlock) headerBlocksIterator.next();
More context includes:
RampartMessageData rmd = new RampartMessageData(msgCtx, false);
...
SOAPHeader header = rmd.getMsgContext().getEnvelope().getHeader();
if(header == null) {
throw new RampartException("missingSOAPHeader");
}
ArrayList headerBlocks =
header.getHeaderBlocksWithNSURI(WSConstants.WSSE_NS);
SOAPHeaderBlock secHeader = null;
//Issue is axiom - a returned collection must not be null
if(headerBlocks != null) {
Iterator headerBlocksIterator = headerBlocks.iterator();
while (headerBlocksIterator.hasNext()) {
SOAPHeaderBlock elem = (SOAPHeaderBlock)
headerBlocksIterator.next();
if(elem.getLocalName().equals(WSConstants.WSSE_LN)) {
secHeader = elem;
break;
}
}
}
It appears that the iterator returned from
getHeaderBlocksWithNSURI(WSConstants.WSSE_NS) returns an iterator
consisting of ElementImpl, not SOAPHeaderBlocks.
I assume that I'm doing something wrong, but am out of ideas at this
point. I don't see any rampart test cases that test the valid processing
of the results, just a single one that test that RampartEngine fails
when no security header is present. I can provide a test case if anyone
is interested.
Any help would be greatly appreciated.
Thanks,
Bob
Re: Programmatically running RampartEngine
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Bob,
Great :). Thank you very much for you contribution. Please feel free to
submit patches for any improvements.
thanks,
nandana
On Mon, Oct 27, 2008 at 9:34 PM, Bob Jacoby <bo...@gossamer-group.com> wrote:
> Thanks, Nandana. I saw the JIRA update. I figured it was just an issue
> with how I was initializing things in my test case vs an actual bug in
> the core. One thing I noticed was that modification explicitly set it as
> a SOAP 1.1 message (set the content type to "text/xml"). I require 1.2
> messages due to known Axiom issue
> (https://issues.apache.org/jira/browse/RAMPART-164).
>
> I'll submit a patch to the test case to dynamically set the appropriate
> content type based on the namespace. Not needed for this test case since
> it uses a 1.1 message, but I think it'd be good to have for reference.
> I'll also throw together a 1.2 test case and add the before mentioned
> validation.
>
> Thanks,
> Bob
>
> -----Original Message-----
> From: Nandana Mihindukulasooriya [mailto:nandana.cse@gmail.com]
> Sent: Monday, October 27, 2008 9:25 AM
> To: rampart-dev@ws.apache.org
> Subject: Re: Programmatically running RampartEngine
>
> Hi Bob,
> Fixed the class cast problem. Thanks a lot for the contribution. I
> didn't implement any validation logic but I think now you can go ahead
> and
> implement them as you have proposed in your original mail. Hope you can
> contribute some other tests too to check the proper validation. It will
> great if you can implement some test cases for failure cases. For
> example,
> build the messages using one policy and validate the message using some
> other policy by choosing the policies intelligently. For example, you
> can
> have a policy that only signs timestamp to build the message but
> validate it
> with a policy that expects the body of the message to be signed. Rampart
> should through a proper exception. I will also help as much as I can
> whenever I can. Once again thank you very much for your contribution and
> other developers who use Rampart are also welcome to improve Rampart
> test
> cases and other open issues.
>
> thanks,
> nandana
>
> On Wed, Oct 22, 2008 at 10:46 PM, Bob Jacoby <bo...@gossamer-group.com>
> wrote:
>
> > Thanks, Nandana.
> >
> > I created a failing test case and attached it to
> > https://issues.apache.org/jira/browse/RAMPART-202
> > Hopefully I'm just doing something stupid.
> >
> > Thanks,
> > Bob
> >
> > -----Original Message-----
> > From: Nandana Mihindukulasooriya [mailto:nandana.cse@gmail.com]
> > Sent: Tuesday, October 21, 2008 9:52 PM
> > To: rampart-dev@ws.apache.org
> > Subject: Re: Programmatically running RampartEngine
> >
> > Hi Bob,
> > I don't see anything wrong with your steps at the first sight.
> > Please
> > do contribute those test cases to Apache Rampart and then we can debug
> > and
> > fix it. Can you create an JIRA and submit the test cases as a svn
> patch
> > ? .
> > Yes, we need to improve the rampart test cases a lot and it will be
> > great to
> > have this kind of help from the community. You are also welcome to
> > submit
> > patches to any of the open issues and you can even become a committer
> > one
> > day and directly improve the code and the tests. Once again thanks
> for
> > the
> > offer and please submit the test cases as a svn patch.
> >
> > thanks,
> > nandana
> >
> > On Wed, Oct 22, 2008 at 12:05 AM, Bob Jacoby <bo...@gossamer-group.com>
> > wrote:
> >
> > > I'm trying to write some test cases to validate a custom handler.
> One
> > of
> > > the requirements of the custom handler is that the rampart receivers
> > > first run and populate the messageContext appropriate
> > > (WSHandlerConstants.RECV_RESULTS).
> > >
> > > I'm trying to right test cases to validate my handler. Rather than
> > mock
> > > a messageContext to pass into my handler and set all the associated
> > > properties manually, I'd like to programmatically run the portion of
> > > rampart that generates the security header and processes the soap
> > > message. I would then take the resultant message context and run it
> > > through my handler.
> > >
> > > From looking at the sample test cases included with rampart, this
> > seems
> > > like it would be easy enough. I perform the following steps:
> > >
> > > (Generate the Request Stage)
> > > 1. Create a message context similar to
> > >
> rampart-tests\src\test\java\org\apache\rampart\MessageBuilderTestBase
> > >
> > > 2. Load my policy into the context similar to
> > > rampart-tests\src\test\java\org\apache\rampart\
> > > AsymmetricBindingBuilderTest
> > >
> > > 3. Create a MessageBuilder and build the context
> > > MessageBuilder builder = new MessageBuilder();
> > > builder.build(ctx);
> > >
> > > At this step I have what appears to be a valid SOAP envelope in the
> > > message context that's populated with the SOAP headers. Now I need
> to
> > > process this SOAP message so the context is populated with the
> > > appropriate properties (WSHandlerConstants.RECV_RESULTS).
> > >
> > > (Process Stage)
> > > 4. Create an RampartReceiver and process the message context
> > >
> > > 5. Call my handler with the message context
> > >
> > > However, I'm getting an error in Step 4.
> > > java.lang.ClassCastException:
> org.apache.axiom.om.impl.dom.ElementImpl
> > > incompatible with org.apache.axiom.soap.SOAPHeaderBlock
> > > at
> > > org.apache.rampart.RampartEngine.process(RampartEngine.java:108)
> > >
> > > Line 108 of RampartEngine is:
> > > SOAPHeaderBlock elem = (SOAPHeaderBlock)
> headerBlocksIterator.next();
> > >
> > > More context includes:
> > > RampartMessageData rmd = new RampartMessageData(msgCtx, false);
> > > ...
> > > SOAPHeader header = rmd.getMsgContext().getEnvelope().getHeader();
> > > if(header == null) {
> > > throw new RampartException("missingSOAPHeader");
> > > }
> > > ArrayList headerBlocks =
> > > header.getHeaderBlocksWithNSURI(WSConstants.WSSE_NS);
> > > SOAPHeaderBlock secHeader = null;
> > > //Issue is axiom - a returned collection must not be null
> > > if(headerBlocks != null) {
> > > Iterator headerBlocksIterator = headerBlocks.iterator();
> > > while (headerBlocksIterator.hasNext()) {
> > > SOAPHeaderBlock elem = (SOAPHeaderBlock)
> > > headerBlocksIterator.next();
> > > if(elem.getLocalName().equals(WSConstants.WSSE_LN)) {
> > > secHeader = elem;
> > > break;
> > > }
> > > }
> > > }
> > >
> > > It appears that the iterator returned from
> > > getHeaderBlocksWithNSURI(WSConstants.WSSE_NS) returns an iterator
> > > consisting of ElementImpl, not SOAPHeaderBlocks.
> > >
> > > I assume that I'm doing something wrong, but am out of ideas at this
> > > point. I don't see any rampart test cases that test the valid
> > processing
> > > of the results, just a single one that test that RampartEngine fails
> > > when no security header is present. I can provide a test case if
> > anyone
> > > is interested.
> > >
> > > Any help would be greatly appreciated.
> > >
> > > Thanks,
> > > Bob
> > >
> > >
> >
> >
> > --
> > Nandana Mihindukulasooriya
> > WSO2 inc.
> >
> > http://nandana83.blogspot.com/
> > http://www.wso2.org
> >
> > No virus found in this incoming message.
> > Checked by AVG - http://www.avg.com
> > Version: 8.0.175 / Virus Database: 270.8.2/1739 - Release Date:
> > 10/22/2008 7:23 AM
> >
>
>
>
> --
> Nandana Mihindukulasooriya
> WSO2 inc.
>
> http://nandana83.blogspot.com/
> http://www.wso2.org
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.175 / Virus Database: 270.8.2/1739 - Release Date:
> 10/26/2008 9:27 AM
>
--
Nandana Mihindukulasooriya
WSO2 inc.
http://nandana83.blogspot.com/
http://www.wso2.org
RE: Programmatically running RampartEngine
Posted by Bob Jacoby <bo...@gossamer-group.com>.
Thanks, Nandana. I saw the JIRA update. I figured it was just an issue
with how I was initializing things in my test case vs an actual bug in
the core. One thing I noticed was that modification explicitly set it as
a SOAP 1.1 message (set the content type to "text/xml"). I require 1.2
messages due to known Axiom issue
(https://issues.apache.org/jira/browse/RAMPART-164).
I'll submit a patch to the test case to dynamically set the appropriate
content type based on the namespace. Not needed for this test case since
it uses a 1.1 message, but I think it'd be good to have for reference.
I'll also throw together a 1.2 test case and add the before mentioned
validation.
Thanks,
Bob
-----Original Message-----
From: Nandana Mihindukulasooriya [mailto:nandana.cse@gmail.com]
Sent: Monday, October 27, 2008 9:25 AM
To: rampart-dev@ws.apache.org
Subject: Re: Programmatically running RampartEngine
Hi Bob,
Fixed the class cast problem. Thanks a lot for the contribution. I
didn't implement any validation logic but I think now you can go ahead
and
implement them as you have proposed in your original mail. Hope you can
contribute some other tests too to check the proper validation. It will
great if you can implement some test cases for failure cases. For
example,
build the messages using one policy and validate the message using some
other policy by choosing the policies intelligently. For example, you
can
have a policy that only signs timestamp to build the message but
validate it
with a policy that expects the body of the message to be signed. Rampart
should through a proper exception. I will also help as much as I can
whenever I can. Once again thank you very much for your contribution and
other developers who use Rampart are also welcome to improve Rampart
test
cases and other open issues.
thanks,
nandana
On Wed, Oct 22, 2008 at 10:46 PM, Bob Jacoby <bo...@gossamer-group.com>
wrote:
> Thanks, Nandana.
>
> I created a failing test case and attached it to
> https://issues.apache.org/jira/browse/RAMPART-202
> Hopefully I'm just doing something stupid.
>
> Thanks,
> Bob
>
> -----Original Message-----
> From: Nandana Mihindukulasooriya [mailto:nandana.cse@gmail.com]
> Sent: Tuesday, October 21, 2008 9:52 PM
> To: rampart-dev@ws.apache.org
> Subject: Re: Programmatically running RampartEngine
>
> Hi Bob,
> I don't see anything wrong with your steps at the first sight.
> Please
> do contribute those test cases to Apache Rampart and then we can debug
> and
> fix it. Can you create an JIRA and submit the test cases as a svn
patch
> ? .
> Yes, we need to improve the rampart test cases a lot and it will be
> great to
> have this kind of help from the community. You are also welcome to
> submit
> patches to any of the open issues and you can even become a committer
> one
> day and directly improve the code and the tests. Once again thanks
for
> the
> offer and please submit the test cases as a svn patch.
>
> thanks,
> nandana
>
> On Wed, Oct 22, 2008 at 12:05 AM, Bob Jacoby <bo...@gossamer-group.com>
> wrote:
>
> > I'm trying to write some test cases to validate a custom handler.
One
> of
> > the requirements of the custom handler is that the rampart receivers
> > first run and populate the messageContext appropriate
> > (WSHandlerConstants.RECV_RESULTS).
> >
> > I'm trying to right test cases to validate my handler. Rather than
> mock
> > a messageContext to pass into my handler and set all the associated
> > properties manually, I'd like to programmatically run the portion of
> > rampart that generates the security header and processes the soap
> > message. I would then take the resultant message context and run it
> > through my handler.
> >
> > From looking at the sample test cases included with rampart, this
> seems
> > like it would be easy enough. I perform the following steps:
> >
> > (Generate the Request Stage)
> > 1. Create a message context similar to
> >
rampart-tests\src\test\java\org\apache\rampart\MessageBuilderTestBase
> >
> > 2. Load my policy into the context similar to
> > rampart-tests\src\test\java\org\apache\rampart\
> > AsymmetricBindingBuilderTest
> >
> > 3. Create a MessageBuilder and build the context
> > MessageBuilder builder = new MessageBuilder();
> > builder.build(ctx);
> >
> > At this step I have what appears to be a valid SOAP envelope in the
> > message context that's populated with the SOAP headers. Now I need
to
> > process this SOAP message so the context is populated with the
> > appropriate properties (WSHandlerConstants.RECV_RESULTS).
> >
> > (Process Stage)
> > 4. Create an RampartReceiver and process the message context
> >
> > 5. Call my handler with the message context
> >
> > However, I'm getting an error in Step 4.
> > java.lang.ClassCastException:
org.apache.axiom.om.impl.dom.ElementImpl
> > incompatible with org.apache.axiom.soap.SOAPHeaderBlock
> > at
> > org.apache.rampart.RampartEngine.process(RampartEngine.java:108)
> >
> > Line 108 of RampartEngine is:
> > SOAPHeaderBlock elem = (SOAPHeaderBlock)
headerBlocksIterator.next();
> >
> > More context includes:
> > RampartMessageData rmd = new RampartMessageData(msgCtx, false);
> > ...
> > SOAPHeader header = rmd.getMsgContext().getEnvelope().getHeader();
> > if(header == null) {
> > throw new RampartException("missingSOAPHeader");
> > }
> > ArrayList headerBlocks =
> > header.getHeaderBlocksWithNSURI(WSConstants.WSSE_NS);
> > SOAPHeaderBlock secHeader = null;
> > //Issue is axiom - a returned collection must not be null
> > if(headerBlocks != null) {
> > Iterator headerBlocksIterator = headerBlocks.iterator();
> > while (headerBlocksIterator.hasNext()) {
> > SOAPHeaderBlock elem = (SOAPHeaderBlock)
> > headerBlocksIterator.next();
> > if(elem.getLocalName().equals(WSConstants.WSSE_LN)) {
> > secHeader = elem;
> > break;
> > }
> > }
> > }
> >
> > It appears that the iterator returned from
> > getHeaderBlocksWithNSURI(WSConstants.WSSE_NS) returns an iterator
> > consisting of ElementImpl, not SOAPHeaderBlocks.
> >
> > I assume that I'm doing something wrong, but am out of ideas at this
> > point. I don't see any rampart test cases that test the valid
> processing
> > of the results, just a single one that test that RampartEngine fails
> > when no security header is present. I can provide a test case if
> anyone
> > is interested.
> >
> > Any help would be greatly appreciated.
> >
> > Thanks,
> > Bob
> >
> >
>
>
> --
> Nandana Mihindukulasooriya
> WSO2 inc.
>
> http://nandana83.blogspot.com/
> http://www.wso2.org
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.175 / Virus Database: 270.8.2/1739 - Release Date:
> 10/22/2008 7:23 AM
>
--
Nandana Mihindukulasooriya
WSO2 inc.
http://nandana83.blogspot.com/
http://www.wso2.org
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.8.2/1739 - Release Date:
10/26/2008 9:27 AM
Re: Programmatically running RampartEngine
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Bob,
Fixed the class cast problem. Thanks a lot for the contribution. I
didn't implement any validation logic but I think now you can go ahead and
implement them as you have proposed in your original mail. Hope you can
contribute some other tests too to check the proper validation. It will
great if you can implement some test cases for failure cases. For example,
build the messages using one policy and validate the message using some
other policy by choosing the policies intelligently. For example, you can
have a policy that only signs timestamp to build the message but validate it
with a policy that expects the body of the message to be signed. Rampart
should through a proper exception. I will also help as much as I can
whenever I can. Once again thank you very much for your contribution and
other developers who use Rampart are also welcome to improve Rampart test
cases and other open issues.
thanks,
nandana
On Wed, Oct 22, 2008 at 10:46 PM, Bob Jacoby <bo...@gossamer-group.com> wrote:
> Thanks, Nandana.
>
> I created a failing test case and attached it to
> https://issues.apache.org/jira/browse/RAMPART-202
> Hopefully I'm just doing something stupid.
>
> Thanks,
> Bob
>
> -----Original Message-----
> From: Nandana Mihindukulasooriya [mailto:nandana.cse@gmail.com]
> Sent: Tuesday, October 21, 2008 9:52 PM
> To: rampart-dev@ws.apache.org
> Subject: Re: Programmatically running RampartEngine
>
> Hi Bob,
> I don't see anything wrong with your steps at the first sight.
> Please
> do contribute those test cases to Apache Rampart and then we can debug
> and
> fix it. Can you create an JIRA and submit the test cases as a svn patch
> ? .
> Yes, we need to improve the rampart test cases a lot and it will be
> great to
> have this kind of help from the community. You are also welcome to
> submit
> patches to any of the open issues and you can even become a committer
> one
> day and directly improve the code and the tests. Once again thanks for
> the
> offer and please submit the test cases as a svn patch.
>
> thanks,
> nandana
>
> On Wed, Oct 22, 2008 at 12:05 AM, Bob Jacoby <bo...@gossamer-group.com>
> wrote:
>
> > I'm trying to write some test cases to validate a custom handler. One
> of
> > the requirements of the custom handler is that the rampart receivers
> > first run and populate the messageContext appropriate
> > (WSHandlerConstants.RECV_RESULTS).
> >
> > I'm trying to right test cases to validate my handler. Rather than
> mock
> > a messageContext to pass into my handler and set all the associated
> > properties manually, I'd like to programmatically run the portion of
> > rampart that generates the security header and processes the soap
> > message. I would then take the resultant message context and run it
> > through my handler.
> >
> > From looking at the sample test cases included with rampart, this
> seems
> > like it would be easy enough. I perform the following steps:
> >
> > (Generate the Request Stage)
> > 1. Create a message context similar to
> > rampart-tests\src\test\java\org\apache\rampart\MessageBuilderTestBase
> >
> > 2. Load my policy into the context similar to
> > rampart-tests\src\test\java\org\apache\rampart\
> > AsymmetricBindingBuilderTest
> >
> > 3. Create a MessageBuilder and build the context
> > MessageBuilder builder = new MessageBuilder();
> > builder.build(ctx);
> >
> > At this step I have what appears to be a valid SOAP envelope in the
> > message context that's populated with the SOAP headers. Now I need to
> > process this SOAP message so the context is populated with the
> > appropriate properties (WSHandlerConstants.RECV_RESULTS).
> >
> > (Process Stage)
> > 4. Create an RampartReceiver and process the message context
> >
> > 5. Call my handler with the message context
> >
> > However, I'm getting an error in Step 4.
> > java.lang.ClassCastException: org.apache.axiom.om.impl.dom.ElementImpl
> > incompatible with org.apache.axiom.soap.SOAPHeaderBlock
> > at
> > org.apache.rampart.RampartEngine.process(RampartEngine.java:108)
> >
> > Line 108 of RampartEngine is:
> > SOAPHeaderBlock elem = (SOAPHeaderBlock) headerBlocksIterator.next();
> >
> > More context includes:
> > RampartMessageData rmd = new RampartMessageData(msgCtx, false);
> > ...
> > SOAPHeader header = rmd.getMsgContext().getEnvelope().getHeader();
> > if(header == null) {
> > throw new RampartException("missingSOAPHeader");
> > }
> > ArrayList headerBlocks =
> > header.getHeaderBlocksWithNSURI(WSConstants.WSSE_NS);
> > SOAPHeaderBlock secHeader = null;
> > //Issue is axiom - a returned collection must not be null
> > if(headerBlocks != null) {
> > Iterator headerBlocksIterator = headerBlocks.iterator();
> > while (headerBlocksIterator.hasNext()) {
> > SOAPHeaderBlock elem = (SOAPHeaderBlock)
> > headerBlocksIterator.next();
> > if(elem.getLocalName().equals(WSConstants.WSSE_LN)) {
> > secHeader = elem;
> > break;
> > }
> > }
> > }
> >
> > It appears that the iterator returned from
> > getHeaderBlocksWithNSURI(WSConstants.WSSE_NS) returns an iterator
> > consisting of ElementImpl, not SOAPHeaderBlocks.
> >
> > I assume that I'm doing something wrong, but am out of ideas at this
> > point. I don't see any rampart test cases that test the valid
> processing
> > of the results, just a single one that test that RampartEngine fails
> > when no security header is present. I can provide a test case if
> anyone
> > is interested.
> >
> > Any help would be greatly appreciated.
> >
> > Thanks,
> > Bob
> >
> >
>
>
> --
> Nandana Mihindukulasooriya
> WSO2 inc.
>
> http://nandana83.blogspot.com/
> http://www.wso2.org
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.175 / Virus Database: 270.8.2/1739 - Release Date:
> 10/22/2008 7:23 AM
>
--
Nandana Mihindukulasooriya
WSO2 inc.
http://nandana83.blogspot.com/
http://www.wso2.org
RE: Programmatically running RampartEngine
Posted by Bob Jacoby <bo...@gossamer-group.com>.
Thanks, Nandana.
I created a failing test case and attached it to
https://issues.apache.org/jira/browse/RAMPART-202
Hopefully I'm just doing something stupid.
Thanks,
Bob
-----Original Message-----
From: Nandana Mihindukulasooriya [mailto:nandana.cse@gmail.com]
Sent: Tuesday, October 21, 2008 9:52 PM
To: rampart-dev@ws.apache.org
Subject: Re: Programmatically running RampartEngine
Hi Bob,
I don't see anything wrong with your steps at the first sight.
Please
do contribute those test cases to Apache Rampart and then we can debug
and
fix it. Can you create an JIRA and submit the test cases as a svn patch
? .
Yes, we need to improve the rampart test cases a lot and it will be
great to
have this kind of help from the community. You are also welcome to
submit
patches to any of the open issues and you can even become a committer
one
day and directly improve the code and the tests. Once again thanks for
the
offer and please submit the test cases as a svn patch.
thanks,
nandana
On Wed, Oct 22, 2008 at 12:05 AM, Bob Jacoby <bo...@gossamer-group.com>
wrote:
> I'm trying to write some test cases to validate a custom handler. One
of
> the requirements of the custom handler is that the rampart receivers
> first run and populate the messageContext appropriate
> (WSHandlerConstants.RECV_RESULTS).
>
> I'm trying to right test cases to validate my handler. Rather than
mock
> a messageContext to pass into my handler and set all the associated
> properties manually, I'd like to programmatically run the portion of
> rampart that generates the security header and processes the soap
> message. I would then take the resultant message context and run it
> through my handler.
>
> From looking at the sample test cases included with rampart, this
seems
> like it would be easy enough. I perform the following steps:
>
> (Generate the Request Stage)
> 1. Create a message context similar to
> rampart-tests\src\test\java\org\apache\rampart\MessageBuilderTestBase
>
> 2. Load my policy into the context similar to
> rampart-tests\src\test\java\org\apache\rampart\
> AsymmetricBindingBuilderTest
>
> 3. Create a MessageBuilder and build the context
> MessageBuilder builder = new MessageBuilder();
> builder.build(ctx);
>
> At this step I have what appears to be a valid SOAP envelope in the
> message context that's populated with the SOAP headers. Now I need to
> process this SOAP message so the context is populated with the
> appropriate properties (WSHandlerConstants.RECV_RESULTS).
>
> (Process Stage)
> 4. Create an RampartReceiver and process the message context
>
> 5. Call my handler with the message context
>
> However, I'm getting an error in Step 4.
> java.lang.ClassCastException: org.apache.axiom.om.impl.dom.ElementImpl
> incompatible with org.apache.axiom.soap.SOAPHeaderBlock
> at
> org.apache.rampart.RampartEngine.process(RampartEngine.java:108)
>
> Line 108 of RampartEngine is:
> SOAPHeaderBlock elem = (SOAPHeaderBlock) headerBlocksIterator.next();
>
> More context includes:
> RampartMessageData rmd = new RampartMessageData(msgCtx, false);
> ...
> SOAPHeader header = rmd.getMsgContext().getEnvelope().getHeader();
> if(header == null) {
> throw new RampartException("missingSOAPHeader");
> }
> ArrayList headerBlocks =
> header.getHeaderBlocksWithNSURI(WSConstants.WSSE_NS);
> SOAPHeaderBlock secHeader = null;
> //Issue is axiom - a returned collection must not be null
> if(headerBlocks != null) {
> Iterator headerBlocksIterator = headerBlocks.iterator();
> while (headerBlocksIterator.hasNext()) {
> SOAPHeaderBlock elem = (SOAPHeaderBlock)
> headerBlocksIterator.next();
> if(elem.getLocalName().equals(WSConstants.WSSE_LN)) {
> secHeader = elem;
> break;
> }
> }
> }
>
> It appears that the iterator returned from
> getHeaderBlocksWithNSURI(WSConstants.WSSE_NS) returns an iterator
> consisting of ElementImpl, not SOAPHeaderBlocks.
>
> I assume that I'm doing something wrong, but am out of ideas at this
> point. I don't see any rampart test cases that test the valid
processing
> of the results, just a single one that test that RampartEngine fails
> when no security header is present. I can provide a test case if
anyone
> is interested.
>
> Any help would be greatly appreciated.
>
> Thanks,
> Bob
>
>
--
Nandana Mihindukulasooriya
WSO2 inc.
http://nandana83.blogspot.com/
http://www.wso2.org
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.8.2/1739 - Release Date:
10/22/2008 7:23 AM
Re: Programmatically running RampartEngine
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Bob,
I don't see anything wrong with your steps at the first sight. Please
do contribute those test cases to Apache Rampart and then we can debug and
fix it. Can you create an JIRA and submit the test cases as a svn patch ? .
Yes, we need to improve the rampart test cases a lot and it will be great to
have this kind of help from the community. You are also welcome to submit
patches to any of the open issues and you can even become a committer one
day and directly improve the code and the tests. Once again thanks for the
offer and please submit the test cases as a svn patch.
thanks,
nandana
On Wed, Oct 22, 2008 at 12:05 AM, Bob Jacoby <bo...@gossamer-group.com> wrote:
> I'm trying to write some test cases to validate a custom handler. One of
> the requirements of the custom handler is that the rampart receivers
> first run and populate the messageContext appropriate
> (WSHandlerConstants.RECV_RESULTS).
>
> I'm trying to right test cases to validate my handler. Rather than mock
> a messageContext to pass into my handler and set all the associated
> properties manually, I'd like to programmatically run the portion of
> rampart that generates the security header and processes the soap
> message. I would then take the resultant message context and run it
> through my handler.
>
> From looking at the sample test cases included with rampart, this seems
> like it would be easy enough. I perform the following steps:
>
> (Generate the Request Stage)
> 1. Create a message context similar to
> rampart-tests\src\test\java\org\apache\rampart\MessageBuilderTestBase
>
> 2. Load my policy into the context similar to
> rampart-tests\src\test\java\org\apache\rampart\
> AsymmetricBindingBuilderTest
>
> 3. Create a MessageBuilder and build the context
> MessageBuilder builder = new MessageBuilder();
> builder.build(ctx);
>
> At this step I have what appears to be a valid SOAP envelope in the
> message context that's populated with the SOAP headers. Now I need to
> process this SOAP message so the context is populated with the
> appropriate properties (WSHandlerConstants.RECV_RESULTS).
>
> (Process Stage)
> 4. Create an RampartReceiver and process the message context
>
> 5. Call my handler with the message context
>
> However, I'm getting an error in Step 4.
> java.lang.ClassCastException: org.apache.axiom.om.impl.dom.ElementImpl
> incompatible with org.apache.axiom.soap.SOAPHeaderBlock
> at
> org.apache.rampart.RampartEngine.process(RampartEngine.java:108)
>
> Line 108 of RampartEngine is:
> SOAPHeaderBlock elem = (SOAPHeaderBlock) headerBlocksIterator.next();
>
> More context includes:
> RampartMessageData rmd = new RampartMessageData(msgCtx, false);
> ...
> SOAPHeader header = rmd.getMsgContext().getEnvelope().getHeader();
> if(header == null) {
> throw new RampartException("missingSOAPHeader");
> }
> ArrayList headerBlocks =
> header.getHeaderBlocksWithNSURI(WSConstants.WSSE_NS);
> SOAPHeaderBlock secHeader = null;
> //Issue is axiom - a returned collection must not be null
> if(headerBlocks != null) {
> Iterator headerBlocksIterator = headerBlocks.iterator();
> while (headerBlocksIterator.hasNext()) {
> SOAPHeaderBlock elem = (SOAPHeaderBlock)
> headerBlocksIterator.next();
> if(elem.getLocalName().equals(WSConstants.WSSE_LN)) {
> secHeader = elem;
> break;
> }
> }
> }
>
> It appears that the iterator returned from
> getHeaderBlocksWithNSURI(WSConstants.WSSE_NS) returns an iterator
> consisting of ElementImpl, not SOAPHeaderBlocks.
>
> I assume that I'm doing something wrong, but am out of ideas at this
> point. I don't see any rampart test cases that test the valid processing
> of the results, just a single one that test that RampartEngine fails
> when no security header is present. I can provide a test case if anyone
> is interested.
>
> Any help would be greatly appreciated.
>
> Thanks,
> Bob
>
>
--
Nandana Mihindukulasooriya
WSO2 inc.
http://nandana83.blogspot.com/
http://www.wso2.org