Classification: UNCLASSIFIED Caveats: NONE Hi, Simon,
I have created the JIRA, TUSCANY-3822 (https://issues.apache.org/jira/browse/TUSCANY-3822), and included the two classes that I changed in order to access the outbound MessageContext in afterInvoke(). I've also successfully integrated our WS-Security solution with Tuscany 1.6.1 (with the fix) using the PolicyHandler approach in a prototype and have indicated to our project management that there's solution based on Tuscany 1.6.1 (with the fix). We got a "go" to proceed down this path and our delivery date is the end of March. Our WS-Security project is to support other projects that are already using Tuscany 1.6 and needed the government-specific WS-Security solution. I'm not sure if there's another more "formal" channel to push for the fix, but I would appreciate it if you or someone from Tuscany could provide the next release information (Tuscany 1.6.2? and date) and would like to make sure that the fix be included. If there's anything else I could do to further help on this, please let me know. Thanks again. Gang -----Original Message----- From: Simon Laws [mailto:simonsl...@googlemail.com] Sent: Monday, January 24, 2011 5:01 PM To: dev@tuscany.apache.org Subject: Re: An issue with PolicyHandler extension framework - a bug or design flaw? (UNCLASSIFIED) On Mon, Jan 24, 2011 at 9:51 PM, Yang, Gang CTR US USA <gang.y...@us.army.mil> wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Hi, Simon and others, > > > > I'm reposting this because I found my earlier post was grouped under an old > topic and it may be why I did not receive any response, which I badly hope > to hear. To provide a background, I'm trying to write a Policy extension to > add a new WS-security implementation to WS binding in Tuscany. In my earlier > post (see http://www.mail-archive.com/dev@tuscany.apache.org/msg15333.html), > I described the problems with Tuscany 1.6.x Policy extension framework using > PolicyInterceptor approach and got some pointers from Simon, one is to try > Tuscany 2.0 and the other is to use the PolicyHandler extension in Tuscany > 1.6.x. > > > > I did not get any response for my request for help on the 2.0 Policy > > issues (see > http://www.mail-archive.com/dev@tuscany.apache.org/msg15353.html), so I went > ahead down to > > the second path Simon suggested - to work with PolicyHandler extension > > point in 1.6.x. > > > > Everything went well on the reference side until I was testing on the > > service side. I think the current PolicyHandler extension framework has > > a defect when processing the PolicyHandler.afterInvoke() call for the > service side and the model does not fit the need to add WS-security to the > binding.ws.axis2 binding implementation. Today PolicyHandler.afterInvoke() > is call with the OMElement response and MessageContext inMC, which is still > the message context for the inbound request. In order to add WS-security to > the response, I need to access the message context for the outbound > response. > > > > So I modified Axis2ServiceInOutSyncMessageReceiver and > > Axis2ServiceProvider classes to delay the calling of > PolicyHandler.afterInvoke() > > from inside Axis2ServiceProvider.invokeTarget() before outMC is constructed > to after outMC has been constructed in > Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic(). After the > change, my prototype worked and it also passed all unit tests. > > > > Now I would like to hear Tuscany developers' opinions and/or get your > blessing. If this change is fine, how can it be pulled back into the code > base? If not, what can be done to support what I would like to do, which is > pretty natural and generic. > > > > I would really appreciate responses so our project can make a decision. > > > > Thanks in advance, > > Gang > > > > PS: > > The following is the code segments to high light the change I made (with > "Gang: ..." comments): > > > > Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic(...) { > > .... > > OMElement responseOM = > (OMElement)provider.invokeTarget(operation, args, inMC); > > > > /* > > for ( PolicyHandler policyHandler : policyHandlerList ) { > > policyHandler.afterInvoke(operation, args, inMC, > responseOM); > > } > > */ > > > > SOAPEnvelope soapEnvelope = > getSOAPFactory(inMC).getDefaultEnvelope(); > > if (null != responseOM ) { > > soapEnvelope.getBody().addChild(responseOM); > > } > > outMC.setEnvelope(soapEnvelope); > > > outMC.getOperationContext().setProperty(Constants.RESPONSE_WRITTEN, > Constants.VALUE_TRUE); > > > > // Gang: Added > > for ( PolicyHandler policyHandler : policyHandlerList ) { > > policyHandler.afterInvoke(responseOM, outMC); > > } > > ... > > } > > > > Axis2ServiceProvider.invokeTarget(...) { > > ... > > // find the runtime wire and invoke it with the message > > RuntimeWire wire = > ((RuntimeComponentService)contract).getRuntimeWire(getBinding()); > > Object response = wire.invoke(op, msg); > > > > // Gang: Commented out > > // for ( PolicyHandler policyHandler : policyHandlerList ) { > > // policyHandler.afterInvoke(response, inMC); > > //} > > > > return response; > > } > > > > > > > > > > Classification: UNCLASSIFIED > Caveats: NONE > > Hi Gang It seems reasonable to me at first glance. I'd like to see it running. A way for me to do this and to get it into Tuscany is for you to create a JIRA and attach your patch to it. I can then apply it locally and take a look at it. Sorry I didn't notice your 2.x question. It is in my reader but I just missed it amongst other stuff. I'd like to make sure that we can do the same thing in 2.x as that is where most development is happening. What I could possibly do when I get 5 minutes is create some policy interceptors which shows you how to get hold of the MC at the before and after locations on reference and server. If in the future you want to move up to 2.x then we'd be more comfortable that the code does what you need it to. Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com Classification: UNCLASSIFIED Caveats: NONE
