Hi Raymond, - How do applications add policy handlers ? For example if an application is wanting to provide some other flavour of logging or authentication how does it get a hook to do this ?
- Also, looking at fixing https://issues.apache.org/jira/browse/TUSCANY-2125I am trying to keep the PolicyProvider mechanism as well as the JavaPolicyRuntimeWireProcessor thing co-existing so that we our bigbank demo going because that demo implements its own PolicyHandler for authorization function. One way of doing this could be if in the JavaPolicyRuntimeWireProcessor I am able to run thro all the interceptors in the invocation chain and see if it has a PolicyInteceptor that handles a particular policySet. If there is one, then I can skip adding the interceptor for this policyset. But I can't figure out a way to do this, since the PolicyInterceptor does not have a marker interface or a accessor method to get the PolicySet name that it handles. Is there a way out for this ? Thanks - Venkat On Sat, Mar 8, 2008 at 1:36 AM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > I checked in changes that integrate the core with these new SPIs and > converted logging and transaction policies under r634776. Can some of you > look into the policy security too? > > Thanks, > Raymond > -------------------------------------------------- > From: "Raymond Feng" <[EMAIL PROTECTED]> > Sent: Thursday, March 06, 2008 10:51 PM > To: <tuscany-dev@ws.apache.org> > Subject: Adding SPIs to handle policies, was: Re: Policy Handlers ? > > > Hi, > > > > I'm adding the following SPIs to provide pluggable implementations to > > various policies in Tuscany. See [1]. > > > > 1) Define a PolicyProviderFactory that can be contributed to the > > ProviderFactoryExtensionPoint by policy extensions. This is similar to > our > > BindingProviderFactory and ImplementationProviderFactory. > > > > 2) Define a PolicyProvider that can be created by PolicyProviderFactory > > for the following policy attach points: > > > > (component, reference, binding) for reference policies > > (component, service, binding) for service polices > > (component, implementation) for implementations > > > > Please note that we leave the PolicyProviderFactory to decide if it will > > create a PolicyProvider based on the resolved policy sets. For some > > policies, even if there is no intent declared, some default behaviors > are > > desired. > > > > 3) Define a PolicyImplementor interface that can be optionally > implemented > > by Binding/Implementaiton Provider to indicate if the > > binding/implementation > > extension will handle the policies by themselves. > > > > 4) The runtime will iterate through all the policies in the resolved > > policySets, if a policy is NOT implemented by binding/implementation > > provider (not on the PolicyImplementor.getImplementedPolices() list), > then > > call PolicyProvider.createInterceptor() to add an interceptor. > > > > I also have the logging policy and transaction policy converted into > these > > new SPIs locally. I'll check them in if we agree the SPIs are the right > > way to go. > > > > Thanks, > > Raymond > > > > [1] http://svn.apache.org/viewvc?rev=634558&view=rev > > > > -------------------------------------------------- > > From: "Raymond Feng" <[EMAIL PROTECTED]> > > Sent: Thursday, November 29, 2007 9:01 AM > > To: <tuscany-dev@ws.apache.org> > > Subject: Re: Policy Handlers ? > > > >> Hi, > >> > >> Let's take the transaction policy as an example to understand the > >> responsibilities of the players. > >> > >> Assuming the following intents are declared against the binding or > >> implementation types, what code are needed to enforce the semantics? > >> > >> Intent > Binding/Implementation > >> Type > >> ---------------------------------- > ------------------------------------- > >> 1. managedTransaction.global implementation.java > >> 2. managedTransaction.global implementation.bpel > >> 3. suspendsTransaction a reference or service with > >> binding.sca (local in-VM case) > >> 4. suspendsTransaction a reference with binding.ws > >> 5. propagatesTransaction a reference with binding.ws > >> 6. propagatesTransaction a service with binding.ws > >> > >> In case 1 & 2, an transaction interceptor can be added to the > invocation. > >> The interceptor interacts with the transaction manager to make sure a > >> global > >> transaction is demarcated before the control hits the component > >> implementation. The interceptor can be independent of the > implementation > >> types. > >> > >> In case 3 & 4, an transaction interceptor can be added to the > invocation > >> to > >> suspend the current transaction before delegating to the next invoker > and > >> resume the transaction after the control is returned. > >> > >> In case 5, the binding.ws provider will have to deal with > >> WS-AtomicTransaction to make sure the transaction context can be > >> propagated > >> over the SOAP protocol. > >> > >> In case 6, if there is an incoming transaction from the WS-AT, the > >> binding.ws provider will need to import the transaction. > >> > >> It seems that the logic that enforces the intents could be a joint > effort > >> of > >> a policy interceptor and the binding/implementation provider. > >> > >> Thanks, > >> Raymond > >> > >> ----- Original Message ----- > >> From: "Venkata Krishnan" <[EMAIL PROTECTED]> > >> To: <tuscany-dev@ws.apache.org> > >> Sent: Wednesday, November 28, 2007 9:05 AM > >> Subject: Policy Handlers ? > >> > >> > >>> Hi, > >>> > >>> Sebastien and Raymond, thanks for your responses on the other > thread... > >>> I > >>> will follow up the issues there one by one. Here I want to discuss > >>> about > >>> PolicyHandlers. > >>> > >>> Every policyset encapsulate policies that could follow a standard > model > >>> such > >>> as ws-policy or could follow a custom model as in the case of our > >>> axis2-config-param policy and jdkLogging policy. > >>> > >>> Each implementation and binding type could have its own way of > >>> interpretting > >>> these policy models and affecting them accordingly in the binding or > >>> implementation. For example the axis2 binding simply injects the > >>> ws-policy > >>> into the axis configuration. Some other binding that works with > >>> ws-policy > >>> might handle this differently. > >>> > >>> This sort of 'policy handling' is what I had initially thought of as > >>> something that can be dealt by PolicyHandler classes. Now I find that > >>> how > >>> these classes look and what they do inside it entirely upto the > binding > >>> and > >>> implementation types including when they are called i.e. during start > or > >>> stop of the binding/implementatoin or during invocation of service > >>> methods > >>> etc. > >>> > >>> Given that the PolicyHandler is getting to be something internal to > the > >>> binding or implementation do we ever have to define an SPI for it ? I > >>> am > >>> basically questioning the current implementation of defining > >>> PolicyHandler > >>> classes in a services sort of file in META-INF directory, loading and > >>> instantiating them, invoking them and so on. > >>> > >>> Is there a view-point I am missing here? > >>> > >>> Thanks > >>> -Venkat > >>> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
