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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> Sent: Monday, October 27, 2008 9:25 AM
> To: [email protected]
> 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 <[EMAIL PROTECTED]>
> 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:[EMAIL PROTECTED]
> > Sent: Tuesday, October 21, 2008 9:52 PM
> > To: [email protected]
> > 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 <[EMAIL PROTECTED]>
> > 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
