You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Yang, Gang CTR US USA" <ga...@us.army.mil> on 2011/01/24 22:51:12 UTC
An issue with PolicyHandler extension framework - a bug or design flaw? (UNCLASSIFIED)
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
Re: An issue with PolicyHandler extension framework - a bug or design
flaw? (UNCLASSIFIED)
Posted by Simon Nash <na...@apache.org>.
See responses below. I've removed older discussion to make this
easier to follow.
Simon
Yang, Gang CTR US USA wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> (cut)
>
> Thinking about this some more, I believe it's also possible for
> the policy handler to get outMC from inMC for the in-out case. This
> means that we could still call afterInvoke(inMC) for the in-out case
> as we do at present, but make sure that outMC is fully populated with
> the response data before we make this call. The policy handler could
> get outMC from inMC and do whatever processing it wants on the
> contents of outMC.
>
> GY: I guess it's concept and design issue. I think there are two things
> that we have been putting together in our discussion. The first is the
> message pattern: in-only, in-out and out-only. What goes with this is
> the direction of the message. For in-only, there's only one direction,
> inbound. For in-out, there's inbound and outbound. For out-only, there
> is only outbound. This is where I'm interested for WS-security. From a
> service viewpoint looking at the in-out pattern, I would like to think
> processes in terms of inbound and outbound, which would correspond to
> two handler methods in the design, let's say inInvoke() and outInvoke()
> for the inbound and outbound respectively. Naturally I would like to
> access inbound context, inMC, and outbound context, outMC in these two
> methods respectively rather than always inbound context, inMC. That's
> where I came from.
>
On the service side, before/after corresponds to in/out. However, on
the reference invoker side, before/after corresponds to out/in. I don't
think we should attempt to redesign this in the 1.x codebase, but it
could be a useful discussion for the new 2.0 model.
> GY: Then there's the second thing in our discussion, which the timing of
> invocation of the handler's methods relative to the invocation of the
> endpoint via wire. I guess that's why the current methods names are
> called before/afterInvoke(). I had mapped "before" to "in" and "after"
> to "out". This probably explains why I see it the way I did.
>
Bearing in mind that policy handlers aren't just for security, I think
the before/after terminology does have some justification. When writing
security policy handlers for the service side, I agree that before==in
and after==out.
> GY: Back to what should it be moving forward, my opinion is that if we
> keep the methods names as is, then
>
> In-only: beforeInvoke(inMC) / afterInvoke(inMC)
>
+1
> In-out: beforeInvoke(inMC) / afterInvoke(outMC)
>
I don't feel strongly about this. It's more consistent with the
in-only case on the service side to use afterInvoke(inMC). However,
the reference side invoker for the in/out case calls beforeInvoke()
with requestMC and calls afterInvoke() with responseMC, which would
be consistent with the service side calling afterInvoke(outMC).
Another advantage of calling afterInvoke(outMC) on the service side
is that it makes it easy for the afterInvoke() handler to see whether
it needs to deal with a response as well as a request. So on balance
I'm inclined to agree that this change makes sense.
> Out-only: beforeInvoke(outMC) / afterInvoke(outMC)
>
It wouldn't be possible to do this, as the service binding only gets
one shot at calling a handler (before the outbound message is sent).
Also, the names beforeInvoke and afterInvoke aren't meaningful because
there's no service invocation. We can defer this for now as there's
not much likelihood of out-only being added to 1.x.
> GY: Here we combined the two semantics, inbound/outbound and
> before/after into one. One other note on afterInvoke() calling position,
> it needs to be moved from Axis2ServiceProvider.invokeTarget() to a later
> time because outMC, if it's directly passed into afterInvoke() or
> obtained from inMC, has not be setup correctly.
>
I think this change is necessary, as the current positioning of the
afterInvoke() call means that it couldn't (for example) add headers
to the response. I'd be inclined to put the afterInvoke() call
after the code that sets up the SOAP envelope in outMC but before the
code that sets the "response written" flag in the operation context.
Simon
RE: An issue with PolicyHandler extension framework - a bug or design flaw? (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
Simon,
Sorry about the delay - worked from home yesterday and could not respond
(at least did not know how) to respond to existing threads without email
history - I normally use my work email to post and home email did not
get all the mailing copies.
The message is getting too long and hard to locate current discussion
point ("cursor"). My response is embedded with "GY:" prefix following
your most recent text.
Thanks,
Gang
-----Original Message-----
From: Simon Nash [mailto:nash@apache.org]
Sent: Wednesday, February 02, 2011 2:40 AM
To: dev@tuscany.apache.org
Subject: Re: An issue with PolicyHandler extension framework - a bug or
design flaw? (UNCLASSIFIED)
Simon Nash wrote:
> Yang, Gang CTR US USA wrote:
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> Simon,
>>
>> Don't worry about if I'm offended - I'm not. I'm only focused on one
>> aspect and I'm sure there are other aspects that need to be
considered.
>> Discussion only make the product better.
>>
>> The "in-out: beforeInvoke(inMC) / afterInvoke(inMC) /
>> beforeInvoke(outMC)" pattern seems confusing though - just my
opinion. I
>> think "in-out: beforeInvoke(inMC) / afterInvoke(inMC)" is more
>> understandable. afterInvoke() can be called with both inMC and outMC
>> (contexts is an array) so post invocation logging can be done in
>> afterInvoke(). Actually, if Axis2 is used, you can get the inbound
>> context from the outbound context. I'm using it to pass states from
>> inbound to outbound.
>>
> OK, then we could do the following:
> in-only: beforeInvoke(inMC) / afterInvoke(inMC)
> in-out: beforeInvoke(inMC) / afterInvoke(outMC)
> out-only: beforeInvoke(outMC)
>
Thinking about this some more, I believe it's also possible for
the policy handler to get outMC from inMC for the in-out case. This
means that we could still call afterInvoke(inMC) for the in-out case
as we do at present, but make sure that outMC is fully populated with
the response data before we make this call. The policy handler could
get outMC from inMC and do whatever processing it wants on the
contents of outMC.
GY: I guess it's concept and design issue. I think there are two things
that we have been putting together in our discussion. The first is the
message pattern: in-only, in-out and out-only. What goes with this is
the direction of the message. For in-only, there's only one direction,
inbound. For in-out, there's inbound and outbound. For out-only, there
is only outbound. This is where I'm interested for WS-security. From a
service viewpoint looking at the in-out pattern, I would like to think
processes in terms of inbound and outbound, which would correspond to
two handler methods in the design, let's say inInvoke() and outInvoke()
for the inbound and outbound respectively. Naturally I would like to
access inbound context, inMC, and outbound context, outMC in these two
methods respectively rather than always inbound context, inMC. That's
where I came from.
GY: Then there's the second thing in our discussion, which the timing of
invocation of the handler's methods relative to the invocation of the
endpoint via wire. I guess that's why the current methods names are
called before/afterInvoke(). I had mapped "before" to "in" and "after"
to "out". This probably explains why I see it the way I did.
GY: Back to what should it be moving forward, my opinion is that if we
keep the methods names as is, then
In-only: beforeInvoke(inMC) / afterInvoke(inMC)
In-out: beforeInvoke(inMC) / afterInvoke(outMC)
Out-only: beforeInvoke(outMC) / afterInvoke(outMC)
GY: Here we combined the two semantics, inbound/outbound and
before/after into one. One other note on afterInvoke() calling position,
it needs to be moved from Axis2ServiceProvider.invokeTarget() to a later
time because outMC, if it's directly passed into afterInvoke() or
obtained from inMC, has not be setup correctly.
Simon
> When afterInvoke() is called with outMC, it can do postprocessing of
> the request (by getting inMC from outMC) and preprocessing of the
> response.
>
> Simon
>
>> Gang
>>
>> -----Original Message-----
>> From: Simon Nash [mailto:nash@apache.org] Sent: Tuesday, February 01,
>> 2011 12:59 PM
>> To: dev@tuscany.apache.org
>> Subject: Re: An issue with PolicyHandler extension framework - a bug
or
>> design flaw? (UNCLASSIFIED)
>>
>> Yang, Gang CTR US USA wrote:
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> Simon,
>>>
>>> I certainly do not have broad-enough knowledge about Tuscany
internals
>>> to determine if the changes I made was consistent. It only serves as
a
>>> code snippet to demonstrate my issue, but not necessarily final code
>> to
>>> fix the problem. Simon L. said he was going to play with it to see
if
>>> there's any problem. The key issue is that for the outbound
(response)
>>> processing, the outbound context should be provided.
>>>
>> Hi Gang,
>> My comment wasn't intended as any criticism of the code you have
>> written, which fixes an important problem in the case of adding
>> WS-Security to response messages. I was trying to progress the
>> discussion to reach a conclusion among the Tuscany community on
>> what final code change needs to be applied.
>>
>>> Regarding to the Axis2ServiceInOutSyncMessageReceiver vs
>>> Axis2ServiceInMessageReceiver, why would afterInvoke() be even
called
>>> for inbound-only message pattern?
>> >
>> Possibly because someone might want to write log entries both
>> before and after the service method has been invoked, to record the
>> fact that the service request has completed and returned.
>>
>>> Is there a
>>> Axis2ServiceOutMessageReceiver that process the outbound-only
message
>>> pattern? I would think that the outbound-only processing needs some
>>> consideration.
>>>
>> That's a good point. Tuscany currently doesn't support out-only.
>> If this were to be added, it would probably be necessary to call
>> beforeInvoke() with outMC to give the policy handler the opportunity
>> to add the necessary security information to the outbound message.
>> So perhaps the sequence should be:
>> in-only: beforeInvoke(inMC) / afterInvoke(inMC)
>> in-out: beforeInvoke(inMC) / afterInvoke(inMC) /
beforeInvoke(outMC)
>> out-only: beforeInvoke(outMC)
>>
>> Simon
>>
>>> Thanks,
>>> Gang
>>>
>>> -----Original Message-----
>>> From: Simon Nash [mailto:nash@apache.org] Sent: Tuesday, February
01,
>>> 2011 10:58 AM
>>> To: dev@tuscany.apache.org
>>> Subject: Re: An issue with PolicyHandler extension framework - a bug
>> or
>>> design flaw? (UNCLASSIFIED)
>>>
>>> Yang, Gang CTR US USA wrote:
>>>> 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.
>>> I've been thinking about the consequences of moving the position
>>> of the afterInvoke() call. I can see that it works for a security
>>> policy handler, but it could cause problems for some other kind of
>>> policy handler such as logging.
>>>
>>> At present there's a pair of beforeInvoke() and afterInvoke() calls
>>> for every inbound method invocation, whether or not the method
>>> produces a response. These calls are made by the invokeTarget()
>>> method of Axis2ServiceProvider, which can be called from either
>>> Axis2ServiceInOutSyncMessageReceiver or
Axis2ServiceInMessageReceiver.
>>>
>>> With the proposed change, the afterInvoke() call would be part of
>>> Axis2ServiceInOutSyncMessageReceiver and would therefore be made
only
>>> for inbound methods that produce responses, not for inbound methods
>>> that don't produce responses. For a logging policy handler, this
>>> doesn't seem correct.
>>>
>>> Perhaps it would be better to arrange the logic so that
afterInvoke()
>>> is still called by Axis2ServiceProvider for both the in-only case
>>> and the in-out case, and change the signature of the afterInvoke()
>>> call to include outMC if the method is in-out. This would require
>>> passing outMC to Axis2ServiceProvider.invokeTarget() and moving the
>>> logic that sets up outMC from Axis2ServiceInOutSyncMessageReceiver
>>> into Axis2ServiceProvider.
>>>
>>> Simon N.
>>>
>>>> Thanks again.
>>>> Gang
>>>>
>>>> -----Original Message-----
>>>> From: Simon Laws [mailto:simonslaws@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
>>>> <ga...@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
>>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>>
>
>
>
Classification: UNCLASSIFIED
Caveats: NONE
Re: An issue with PolicyHandler extension framework - a bug or design
flaw? (UNCLASSIFIED)
Posted by Simon Nash <na...@apache.org>.
Simon Nash wrote:
> Yang, Gang CTR US USA wrote:
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> Simon,
>>
>> Don't worry about if I'm offended - I'm not. I'm only focused on one
>> aspect and I'm sure there are other aspects that need to be considered.
>> Discussion only make the product better.
>>
>> The "in-out: beforeInvoke(inMC) / afterInvoke(inMC) /
>> beforeInvoke(outMC)" pattern seems confusing though - just my opinion. I
>> think "in-out: beforeInvoke(inMC) / afterInvoke(inMC)" is more
>> understandable. afterInvoke() can be called with both inMC and outMC
>> (contexts is an array) so post invocation logging can be done in
>> afterInvoke(). Actually, if Axis2 is used, you can get the inbound
>> context from the outbound context. I'm using it to pass states from
>> inbound to outbound.
>>
> OK, then we could do the following:
> in-only: beforeInvoke(inMC) / afterInvoke(inMC)
> in-out: beforeInvoke(inMC) / afterInvoke(outMC)
> out-only: beforeInvoke(outMC)
>
Thinking about this some more, I believe it's also possible for
the policy handler to get outMC from inMC for the in-out case. This
means that we could still call afterInvoke(inMC) for the in-out case
as we do at present, but make sure that outMC is fully populated with
the response data before we make this call. The policy handler could
get outMC from inMC and do whatever processing it wants on the
contents of outMC.
Simon
> When afterInvoke() is called with outMC, it can do postprocessing of
> the request (by getting inMC from outMC) and preprocessing of the
> response.
>
> Simon
>
>> Gang
>>
>> -----Original Message-----
>> From: Simon Nash [mailto:nash@apache.org] Sent: Tuesday, February 01,
>> 2011 12:59 PM
>> To: dev@tuscany.apache.org
>> Subject: Re: An issue with PolicyHandler extension framework - a bug or
>> design flaw? (UNCLASSIFIED)
>>
>> Yang, Gang CTR US USA wrote:
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> Simon,
>>>
>>> I certainly do not have broad-enough knowledge about Tuscany internals
>>> to determine if the changes I made was consistent. It only serves as a
>>> code snippet to demonstrate my issue, but not necessarily final code
>> to
>>> fix the problem. Simon L. said he was going to play with it to see if
>>> there's any problem. The key issue is that for the outbound (response)
>>> processing, the outbound context should be provided.
>>>
>> Hi Gang,
>> My comment wasn't intended as any criticism of the code you have
>> written, which fixes an important problem in the case of adding
>> WS-Security to response messages. I was trying to progress the
>> discussion to reach a conclusion among the Tuscany community on
>> what final code change needs to be applied.
>>
>>> Regarding to the Axis2ServiceInOutSyncMessageReceiver vs
>>> Axis2ServiceInMessageReceiver, why would afterInvoke() be even called
>>> for inbound-only message pattern?
>> >
>> Possibly because someone might want to write log entries both
>> before and after the service method has been invoked, to record the
>> fact that the service request has completed and returned.
>>
>>> Is there a
>>> Axis2ServiceOutMessageReceiver that process the outbound-only message
>>> pattern? I would think that the outbound-only processing needs some
>>> consideration.
>>>
>> That's a good point. Tuscany currently doesn't support out-only.
>> If this were to be added, it would probably be necessary to call
>> beforeInvoke() with outMC to give the policy handler the opportunity
>> to add the necessary security information to the outbound message.
>> So perhaps the sequence should be:
>> in-only: beforeInvoke(inMC) / afterInvoke(inMC)
>> in-out: beforeInvoke(inMC) / afterInvoke(inMC) / beforeInvoke(outMC)
>> out-only: beforeInvoke(outMC)
>>
>> Simon
>>
>>> Thanks,
>>> Gang
>>>
>>> -----Original Message-----
>>> From: Simon Nash [mailto:nash@apache.org] Sent: Tuesday, February 01,
>>> 2011 10:58 AM
>>> To: dev@tuscany.apache.org
>>> Subject: Re: An issue with PolicyHandler extension framework - a bug
>> or
>>> design flaw? (UNCLASSIFIED)
>>>
>>> Yang, Gang CTR US USA wrote:
>>>> 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.
>>> I've been thinking about the consequences of moving the position
>>> of the afterInvoke() call. I can see that it works for a security
>>> policy handler, but it could cause problems for some other kind of
>>> policy handler such as logging.
>>>
>>> At present there's a pair of beforeInvoke() and afterInvoke() calls
>>> for every inbound method invocation, whether or not the method
>>> produces a response. These calls are made by the invokeTarget()
>>> method of Axis2ServiceProvider, which can be called from either
>>> Axis2ServiceInOutSyncMessageReceiver or Axis2ServiceInMessageReceiver.
>>>
>>> With the proposed change, the afterInvoke() call would be part of
>>> Axis2ServiceInOutSyncMessageReceiver and would therefore be made only
>>> for inbound methods that produce responses, not for inbound methods
>>> that don't produce responses. For a logging policy handler, this
>>> doesn't seem correct.
>>>
>>> Perhaps it would be better to arrange the logic so that afterInvoke()
>>> is still called by Axis2ServiceProvider for both the in-only case
>>> and the in-out case, and change the signature of the afterInvoke()
>>> call to include outMC if the method is in-out. This would require
>>> passing outMC to Axis2ServiceProvider.invokeTarget() and moving the
>>> logic that sets up outMC from Axis2ServiceInOutSyncMessageReceiver
>>> into Axis2ServiceProvider.
>>>
>>> Simon N.
>>>
>>>> Thanks again.
>>>> Gang
>>>>
>>>> -----Original Message-----
>>>> From: Simon Laws [mailto:simonslaws@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
>>>> <ga...@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
>>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>>
>
>
>
Re: An issue with PolicyHandler extension framework - a bug or design
flaw? (UNCLASSIFIED)
Posted by Simon Nash <na...@apache.org>.
Yang, Gang CTR US USA wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Simon,
>
> Don't worry about if I'm offended - I'm not. I'm only focused on one
> aspect and I'm sure there are other aspects that need to be considered.
> Discussion only make the product better.
>
> The "in-out: beforeInvoke(inMC) / afterInvoke(inMC) /
> beforeInvoke(outMC)" pattern seems confusing though - just my opinion. I
> think "in-out: beforeInvoke(inMC) / afterInvoke(inMC)" is more
> understandable. afterInvoke() can be called with both inMC and outMC
> (contexts is an array) so post invocation logging can be done in
> afterInvoke(). Actually, if Axis2 is used, you can get the inbound
> context from the outbound context. I'm using it to pass states from
> inbound to outbound.
>
OK, then we could do the following:
in-only: beforeInvoke(inMC) / afterInvoke(inMC)
in-out: beforeInvoke(inMC) / afterInvoke(outMC)
out-only: beforeInvoke(outMC)
When afterInvoke() is called with outMC, it can do postprocessing of
the request (by getting inMC from outMC) and preprocessing of the
response.
Simon
> Gang
>
> -----Original Message-----
> From: Simon Nash [mailto:nash@apache.org]
> Sent: Tuesday, February 01, 2011 12:59 PM
> To: dev@tuscany.apache.org
> Subject: Re: An issue with PolicyHandler extension framework - a bug or
> design flaw? (UNCLASSIFIED)
>
> Yang, Gang CTR US USA wrote:
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> Simon,
>>
>> I certainly do not have broad-enough knowledge about Tuscany internals
>> to determine if the changes I made was consistent. It only serves as a
>> code snippet to demonstrate my issue, but not necessarily final code
> to
>> fix the problem. Simon L. said he was going to play with it to see if
>> there's any problem. The key issue is that for the outbound (response)
>> processing, the outbound context should be provided.
>>
> Hi Gang,
> My comment wasn't intended as any criticism of the code you have
> written, which fixes an important problem in the case of adding
> WS-Security to response messages. I was trying to progress the
> discussion to reach a conclusion among the Tuscany community on
> what final code change needs to be applied.
>
>> Regarding to the Axis2ServiceInOutSyncMessageReceiver vs
>> Axis2ServiceInMessageReceiver, why would afterInvoke() be even called
>> for inbound-only message pattern?
> >
> Possibly because someone might want to write log entries both
> before and after the service method has been invoked, to record the
> fact that the service request has completed and returned.
>
>> Is there a
>> Axis2ServiceOutMessageReceiver that process the outbound-only message
>> pattern? I would think that the outbound-only processing needs some
>> consideration.
>>
> That's a good point. Tuscany currently doesn't support out-only.
> If this were to be added, it would probably be necessary to call
> beforeInvoke() with outMC to give the policy handler the opportunity
> to add the necessary security information to the outbound message.
> So perhaps the sequence should be:
> in-only: beforeInvoke(inMC) / afterInvoke(inMC)
> in-out: beforeInvoke(inMC) / afterInvoke(inMC) / beforeInvoke(outMC)
> out-only: beforeInvoke(outMC)
>
> Simon
>
>> Thanks,
>> Gang
>>
>> -----Original Message-----
>> From: Simon Nash [mailto:nash@apache.org]
>> Sent: Tuesday, February 01, 2011 10:58 AM
>> To: dev@tuscany.apache.org
>> Subject: Re: An issue with PolicyHandler extension framework - a bug
> or
>> design flaw? (UNCLASSIFIED)
>>
>> Yang, Gang CTR US USA wrote:
>>> 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.
>> I've been thinking about the consequences of moving the position
>> of the afterInvoke() call. I can see that it works for a security
>> policy handler, but it could cause problems for some other kind of
>> policy handler such as logging.
>>
>> At present there's a pair of beforeInvoke() and afterInvoke() calls
>> for every inbound method invocation, whether or not the method
>> produces a response. These calls are made by the invokeTarget()
>> method of Axis2ServiceProvider, which can be called from either
>> Axis2ServiceInOutSyncMessageReceiver or Axis2ServiceInMessageReceiver.
>>
>> With the proposed change, the afterInvoke() call would be part of
>> Axis2ServiceInOutSyncMessageReceiver and would therefore be made only
>> for inbound methods that produce responses, not for inbound methods
>> that don't produce responses. For a logging policy handler, this
>> doesn't seem correct.
>>
>> Perhaps it would be better to arrange the logic so that afterInvoke()
>> is still called by Axis2ServiceProvider for both the in-only case
>> and the in-out case, and change the signature of the afterInvoke()
>> call to include outMC if the method is in-out. This would require
>> passing outMC to Axis2ServiceProvider.invokeTarget() and moving the
>> logic that sets up outMC from Axis2ServiceInOutSyncMessageReceiver
>> into Axis2ServiceProvider.
>>
>> Simon N.
>>
>>> Thanks again.
>>> Gang
>>>
>>> -----Original Message-----
>>> From: Simon Laws [mailto:simonslaws@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
>>> <ga...@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
>>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
>
RE: An issue with PolicyHandler extension framework - a bug or design flaw? (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
Simon,
Don't worry about if I'm offended - I'm not. I'm only focused on one
aspect and I'm sure there are other aspects that need to be considered.
Discussion only make the product better.
The "in-out: beforeInvoke(inMC) / afterInvoke(inMC) /
beforeInvoke(outMC)" pattern seems confusing though - just my opinion. I
think "in-out: beforeInvoke(inMC) / afterInvoke(inMC)" is more
understandable. afterInvoke() can be called with both inMC and outMC
(contexts is an array) so post invocation logging can be done in
afterInvoke(). Actually, if Axis2 is used, you can get the inbound
context from the outbound context. I'm using it to pass states from
inbound to outbound.
Gang
-----Original Message-----
From: Simon Nash [mailto:nash@apache.org]
Sent: Tuesday, February 01, 2011 12:59 PM
To: dev@tuscany.apache.org
Subject: Re: An issue with PolicyHandler extension framework - a bug or
design flaw? (UNCLASSIFIED)
Yang, Gang CTR US USA wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Simon,
>
> I certainly do not have broad-enough knowledge about Tuscany internals
> to determine if the changes I made was consistent. It only serves as a
> code snippet to demonstrate my issue, but not necessarily final code
to
> fix the problem. Simon L. said he was going to play with it to see if
> there's any problem. The key issue is that for the outbound (response)
> processing, the outbound context should be provided.
>
Hi Gang,
My comment wasn't intended as any criticism of the code you have
written, which fixes an important problem in the case of adding
WS-Security to response messages. I was trying to progress the
discussion to reach a conclusion among the Tuscany community on
what final code change needs to be applied.
> Regarding to the Axis2ServiceInOutSyncMessageReceiver vs
> Axis2ServiceInMessageReceiver, why would afterInvoke() be even called
> for inbound-only message pattern?
>
Possibly because someone might want to write log entries both
before and after the service method has been invoked, to record the
fact that the service request has completed and returned.
> Is there a
> Axis2ServiceOutMessageReceiver that process the outbound-only message
> pattern? I would think that the outbound-only processing needs some
> consideration.
>
That's a good point. Tuscany currently doesn't support out-only.
If this were to be added, it would probably be necessary to call
beforeInvoke() with outMC to give the policy handler the opportunity
to add the necessary security information to the outbound message.
So perhaps the sequence should be:
in-only: beforeInvoke(inMC) / afterInvoke(inMC)
in-out: beforeInvoke(inMC) / afterInvoke(inMC) / beforeInvoke(outMC)
out-only: beforeInvoke(outMC)
Simon
> Thanks,
> Gang
>
> -----Original Message-----
> From: Simon Nash [mailto:nash@apache.org]
> Sent: Tuesday, February 01, 2011 10:58 AM
> To: dev@tuscany.apache.org
> Subject: Re: An issue with PolicyHandler extension framework - a bug
or
> design flaw? (UNCLASSIFIED)
>
> Yang, Gang CTR US USA wrote:
>> 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.
> I've been thinking about the consequences of moving the position
> of the afterInvoke() call. I can see that it works for a security
> policy handler, but it could cause problems for some other kind of
> policy handler such as logging.
>
> At present there's a pair of beforeInvoke() and afterInvoke() calls
> for every inbound method invocation, whether or not the method
> produces a response. These calls are made by the invokeTarget()
> method of Axis2ServiceProvider, which can be called from either
> Axis2ServiceInOutSyncMessageReceiver or Axis2ServiceInMessageReceiver.
>
> With the proposed change, the afterInvoke() call would be part of
> Axis2ServiceInOutSyncMessageReceiver and would therefore be made only
> for inbound methods that produce responses, not for inbound methods
> that don't produce responses. For a logging policy handler, this
> doesn't seem correct.
>
> Perhaps it would be better to arrange the logic so that afterInvoke()
> is still called by Axis2ServiceProvider for both the in-only case
> and the in-out case, and change the signature of the afterInvoke()
> call to include outMC if the method is in-out. This would require
> passing outMC to Axis2ServiceProvider.invokeTarget() and moving the
> logic that sets up outMC from Axis2ServiceInOutSyncMessageReceiver
> into Axis2ServiceProvider.
>
> Simon N.
>
>> Thanks again.
>> Gang
>>
>> -----Original Message-----
>> From: Simon Laws [mailto:simonslaws@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
>> <ga...@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
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
>
Classification: UNCLASSIFIED
Caveats: NONE
Re: An issue with PolicyHandler extension framework - a bug or design
flaw? (UNCLASSIFIED)
Posted by Simon Nash <na...@apache.org>.
Yang, Gang CTR US USA wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Simon,
>
> I certainly do not have broad-enough knowledge about Tuscany internals
> to determine if the changes I made was consistent. It only serves as a
> code snippet to demonstrate my issue, but not necessarily final code to
> fix the problem. Simon L. said he was going to play with it to see if
> there's any problem. The key issue is that for the outbound (response)
> processing, the outbound context should be provided.
>
Hi Gang,
My comment wasn't intended as any criticism of the code you have
written, which fixes an important problem in the case of adding
WS-Security to response messages. I was trying to progress the
discussion to reach a conclusion among the Tuscany community on
what final code change needs to be applied.
> Regarding to the Axis2ServiceInOutSyncMessageReceiver vs
> Axis2ServiceInMessageReceiver, why would afterInvoke() be even called
> for inbound-only message pattern?
>
Possibly because someone might want to write log entries both
before and after the service method has been invoked, to record the
fact that the service request has completed and returned.
> Is there a
> Axis2ServiceOutMessageReceiver that process the outbound-only message
> pattern? I would think that the outbound-only processing needs some
> consideration.
>
That's a good point. Tuscany currently doesn't support out-only.
If this were to be added, it would probably be necessary to call
beforeInvoke() with outMC to give the policy handler the opportunity
to add the necessary security information to the outbound message.
So perhaps the sequence should be:
in-only: beforeInvoke(inMC) / afterInvoke(inMC)
in-out: beforeInvoke(inMC) / afterInvoke(inMC) / beforeInvoke(outMC)
out-only: beforeInvoke(outMC)
Simon
> Thanks,
> Gang
>
> -----Original Message-----
> From: Simon Nash [mailto:nash@apache.org]
> Sent: Tuesday, February 01, 2011 10:58 AM
> To: dev@tuscany.apache.org
> Subject: Re: An issue with PolicyHandler extension framework - a bug or
> design flaw? (UNCLASSIFIED)
>
> Yang, Gang CTR US USA wrote:
>> 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.
> I've been thinking about the consequences of moving the position
> of the afterInvoke() call. I can see that it works for a security
> policy handler, but it could cause problems for some other kind of
> policy handler such as logging.
>
> At present there's a pair of beforeInvoke() and afterInvoke() calls
> for every inbound method invocation, whether or not the method
> produces a response. These calls are made by the invokeTarget()
> method of Axis2ServiceProvider, which can be called from either
> Axis2ServiceInOutSyncMessageReceiver or Axis2ServiceInMessageReceiver.
>
> With the proposed change, the afterInvoke() call would be part of
> Axis2ServiceInOutSyncMessageReceiver and would therefore be made only
> for inbound methods that produce responses, not for inbound methods
> that don't produce responses. For a logging policy handler, this
> doesn't seem correct.
>
> Perhaps it would be better to arrange the logic so that afterInvoke()
> is still called by Axis2ServiceProvider for both the in-only case
> and the in-out case, and change the signature of the afterInvoke()
> call to include outMC if the method is in-out. This would require
> passing outMC to Axis2ServiceProvider.invokeTarget() and moving the
> logic that sets up outMC from Axis2ServiceInOutSyncMessageReceiver
> into Axis2ServiceProvider.
>
> Simon N.
>
>> Thanks again.
>> Gang
>>
>> -----Original Message-----
>> From: Simon Laws [mailto:simonslaws@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
>> <ga...@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
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
>
RE: An issue with PolicyHandler extension framework - a bug or design flaw? (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
Simon,
I certainly do not have broad-enough knowledge about Tuscany internals
to determine if the changes I made was consistent. It only serves as a
code snippet to demonstrate my issue, but not necessarily final code to
fix the problem. Simon L. said he was going to play with it to see if
there's any problem. The key issue is that for the outbound (response)
processing, the outbound context should be provided.
Regarding to the Axis2ServiceInOutSyncMessageReceiver vs
Axis2ServiceInMessageReceiver, why would afterInvoke() be even called
for inbound-only message pattern? Is there a
Axis2ServiceOutMessageReceiver that process the outbound-only message
pattern? I would think that the outbound-only processing needs some
consideration.
Thanks,
Gang
-----Original Message-----
From: Simon Nash [mailto:nash@apache.org]
Sent: Tuesday, February 01, 2011 10:58 AM
To: dev@tuscany.apache.org
Subject: Re: An issue with PolicyHandler extension framework - a bug or
design flaw? (UNCLASSIFIED)
Yang, Gang CTR US USA wrote:
> 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.
>
I've been thinking about the consequences of moving the position
of the afterInvoke() call. I can see that it works for a security
policy handler, but it could cause problems for some other kind of
policy handler such as logging.
At present there's a pair of beforeInvoke() and afterInvoke() calls
for every inbound method invocation, whether or not the method
produces a response. These calls are made by the invokeTarget()
method of Axis2ServiceProvider, which can be called from either
Axis2ServiceInOutSyncMessageReceiver or Axis2ServiceInMessageReceiver.
With the proposed change, the afterInvoke() call would be part of
Axis2ServiceInOutSyncMessageReceiver and would therefore be made only
for inbound methods that produce responses, not for inbound methods
that don't produce responses. For a logging policy handler, this
doesn't seem correct.
Perhaps it would be better to arrange the logic so that afterInvoke()
is still called by Axis2ServiceProvider for both the in-only case
and the in-out case, and change the signature of the afterInvoke()
call to include outMC if the method is in-out. This would require
passing outMC to Axis2ServiceProvider.invokeTarget() and moving the
logic that sets up outMC from Axis2ServiceInOutSyncMessageReceiver
into Axis2ServiceProvider.
Simon N.
> Thanks again.
> Gang
>
> -----Original Message-----
> From: Simon Laws [mailto:simonslaws@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
> <ga...@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
>
Classification: UNCLASSIFIED
Caveats: NONE
Re: An issue with PolicyHandler extension framework - a bug or design
flaw? (UNCLASSIFIED)
Posted by Simon Nash <na...@apache.org>.
Yang, Gang CTR US USA wrote:
> 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.
>
I've been thinking about the consequences of moving the position
of the afterInvoke() call. I can see that it works for a security
policy handler, but it could cause problems for some other kind of
policy handler such as logging.
At present there's a pair of beforeInvoke() and afterInvoke() calls
for every inbound method invocation, whether or not the method
produces a response. These calls are made by the invokeTarget()
method of Axis2ServiceProvider, which can be called from either
Axis2ServiceInOutSyncMessageReceiver or Axis2ServiceInMessageReceiver.
With the proposed change, the afterInvoke() call would be part of
Axis2ServiceInOutSyncMessageReceiver and would therefore be made only
for inbound methods that produce responses, not for inbound methods
that don't produce responses. For a logging policy handler, this
doesn't seem correct.
Perhaps it would be better to arrange the logic so that afterInvoke()
is still called by Axis2ServiceProvider for both the in-only case
and the in-out case, and change the signature of the afterInvoke()
call to include outMC if the method is in-out. This would require
passing outMC to Axis2ServiceProvider.invokeTarget() and moving the
logic that sets up outMC from Axis2ServiceInOutSyncMessageReceiver
into Axis2ServiceProvider.
Simon N.
> Thanks again.
> Gang
>
> -----Original Message-----
> From: Simon Laws [mailto:simonslaws@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
> <ga...@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
>
RE: An issue with PolicyHandler extension framework - a bug or design flaw? (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
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:simonslaws@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
<ga...@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
RE: An issue with PolicyHandler extension framework - a bug or design flaw? (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
Hi, Simon,
Appreciate the quick response. I'll create a JIRA right away and attach the two modified classes for you to play with.
For the 2.0 policy, if it saves your time, I can send you my policy extension code. It's really a simple prototype. Let me know.
Thanks again.
Gang
-----Original Message-----
From: Simon Laws [mailto:simonslaws@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
<ga...@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
Re: An issue with PolicyHandler extension framework - a bug or design
flaw? (UNCLASSIFIED)
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Jan 24, 2011 at 9:51 PM, Yang, Gang CTR US USA
<ga...@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