You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Venkata Krishnan <fo...@gmail.com> on 2007/10/03 20:24:22 UTC
Policy support for implementation elements
Hi,
I've now added support for computing policy intents and policysets in
'implementation' elements. I shall work on a sample to demonstrate this and
should be able to get that in by tomorrow.
For the sample I am planning to use 'logging' as an intent and want to want
to have a couple of logging strategies encapsulated as policies that provide
this intent. Thoughts?
Besides this, I am also trying to get support for ws-policy going - hope to
get something working with that soon.
Thanks
- Venkat
Re: Policy support for implementation elements
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
I've further checked in some minor changes to the calculator sample under
r584064 which adds log statements to the implementation classes. The logger
name I have used is 'calculator'. Then, in the definitions.xml I have
stated the logger name for the logging policyset as 'calculator'. Now, if
we change the loglevel element value in this policy set to ALL or FINEST,
you'd see the log messages from the implementations.
So, we have been able to instrument the logging inside implementations by
the sepcification of policies. Do people agree with this ? :)
Thanks
- Venkat
On 10/11/07, Venkata Krishnan <fo...@gmail.com> wrote:
>
> Hi...
>
> I have set up a policyset for JDKLogging and a policy handler for the
> same. All this is now in a separate module called policy-logging. I have
> hooked up the policyhandler in the java impl runtime. It would be good if
> folks can give me opinion on the hooks I have placed to setup and invoke
> policies.
>
> I have modified the calculator sample to include the jdk logging policy.
> Here is the policyset that is used....
>
> <policySet name="tuscany:JDKLoggingPolicy"
> provides="logging"
> appliesTo="sca:implementation.java"
> xmlns="http://www.osoa.org/xmlns/sca/1.0">
> <tuscany:jdkLogger xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"
> name="test.logger">
> <logLevel>INFO</logLevel>
> <resourceBundle>CalculatorLogMessages</resourceBundle>
> <useParentHandlers>false</useParentHandlers>
> </tuscany:jdkLogger>
> </policySet>
>
> This is just a few of the things that we could configure in JDK Logging.
> We can grow this to include other things as well as we go along.
>
> Here is how a component in the calculator sample uses logging intent.
>
> <component name="AddServiceComponent">
> <implementation.java class="calculator.AddServiceImpl"
> requires="logging"/>
> </component>
>
> If you run the sample you will see an 'INFO' level log message now for the
> add function. If you change the 'logLevel' element to 'ALL' in the above
> policyset, in the definitions.xml file of the calculator sample and run
> again, you'd see more log statements.
>
> I guess applications can use this policyset structure to define their
> logging options. If more options are to be supported such as specifying
> additional log handler classes etc. we need to go and extend the processor
> and the handler class in the policy.logging module. I'll do this as an
> when I get feedback on this.
>
> While the current set up enables logging in the java implementation
> extension, the logging intent and policy can also be used to configure
> logging within the business logic implementation too, since JDK logging
> functions at a global level. So, from the SCA composite level you could
> instrument the logging within implementations. I will add something that
> demonstrates this, into the calculator sample... hope I am right in my
> supposition :)
>
> Thanks
>
> - Venkat
>
>
>
>
> On 10/9/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > Venkata Krishnan wrote:
> > > Hi,
> > >
> > > I've been trying to figure out if there is a common pattern in how
> > > implementations and bindings could be interpretting and applying
> > policies so
> > > that we could include this in the SPI. But haven't been successful
> > with
> > > this. Maybe with getting policies to work with a few implementation
> > types
> > > will give a better idea.
> > >
> > > So, to start with I have extended the java implementaion type a bit to
> > > support policies. I have picked on the 'Logging' intent for now and
> > have
> > > implemented a rudimentary logging mechanism that simply uses
> > > System.out.println. I am going to soon replace this with a formal
> > Logging
> > > system. I've been looking a SLF4J so that we could facilitate
> > switching of
> > > various logging implementations thro policy specifications. But seems
> > like
> > > there is no programmatic way of binding the logging options (such as
> > log4j
> > > or JDK Logging) into SLF4J. The logging implementation jar in the
> > > classpath is the one that would get picked up it seems. So for now I
> > plan
> > > to go on with using the JDK Logger and having policies to specify the
> > > logging levels, logging handlers and so on.
> > >
> >
> > +1 to use the JDK logger as this is what we're using for logging inside
> > the Tuscany runtime as well.
> >
> > Is the Logging policy a sample policy? or are you planning to make it
> > available in Tuscany for people to use in their applications?
> >
> > Can you show what the XML to turn logging on looks like?
> >
> > > While I am working on completing this, I'd like to explore another
> > > implementation type for including policy support for a QoS - maybe
> > > transactions.
> > >
> >
> > Good idea! There's a public draft of a Transaction spec at OSOA and
> > several people on the dev and user list have expressed an interest in
> > the transaction policy.
> > > I'd appreciate a lot if people could give me some feedback on the
> > approach I
> > > have taken for the java implementation type and also suggestions on a
> > > implementation type that we could pickup for supporting transactions.
> > >
> >
> > How about changing the Online Store sample to update a database from the
> > ShoppingCart Java component as a starting point?
> >
> > > Thanks.
> > >
> > > - Venkat
> > >
> > >
> >
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: Policy support for implementation elements
Posted by Raymond Feng <en...@gmail.com>.
It seems the logging example is taken from the SCA policy framework
specification. Are you going to propose to the spec group to replace it?
"logging" may not be accurate term, but I think it would be reasonble to
model the requirements of "monitoring" or "auditing" business activities as
intents.
Thanks,
Raymond
----- Original Message -----
From: "Mike Edwards" <mi...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Tuesday, October 16, 2007 5:12 AM
Subject: Re: Policy support for implementation elements
> Venkat,
>
> I'm sorry to be a party pooper here, but I don't think that the use of
> logging via an intent is a good way of doing things.
>
> The SCA idea of intents is that they are a way of expressing requirements
> that an implementation has (or a service or a reference).
>
> So, for a service, it's possible to say "I need my messages encrypted" by
> using @requires="confidentiality". For an implementation, one of the
> transaction intents like @requires="managedTransaction" would also be
> reasonable.
>
> Logging is a very different thing, in my opinion. It seems like something
> that is really a runtime configuration option. I can see that it is
> useful to tell the runtime to log or not to log, and how much to log, but
> I'm really struggling to see why I'd mark my implementations or my
> composites with metadata about logging.
>
> Now, I'm not against capturing the logging levels within a PolicySet, it
> that is convenient. But the application of those policies to the runtime
> does look like an act of configuring the runtime itself ("start the
> runtime with PolicySets X, Y, Z.....")
>
>
> Yours, Mike.
>
> Venkata Krishnan wrote:
>> Hi...
>>
>> I have set up a policyset for JDKLogging and a policy handler for the
>> same.
>> All this is now in a separate module called policy-logging. I have
>> hooked
>> up the policyhandler in the java impl runtime. It would be good if folks
>> can give me opinion on the hooks I have placed to setup and invoke
>> policies.
>>
>> I have modified the calculator sample to include the jdk logging policy.
>> Here is the policyset that is used....
>>
>> <policySet name="tuscany:JDKLoggingPolicy"
>> provides="logging"
>> appliesTo="sca:implementation.java"
>> xmlns="http://www.osoa.org/xmlns/sca/1.0">
>> <tuscany:jdkLogger xmlns:tuscany="
>> http://tuscany.apache.org/xmlns/sca/1.0" name="test.logger">
>> <logLevel>INFO</logLevel>
>> <resourceBundle>CalculatorLogMessages</resourceBundle>
>> <useParentHandlers>false</useParentHandlers>
>> </tuscany:jdkLogger>
>> </policySet>
>>
>> This is just a few of the things that we could configure in JDK Logging.
>> We
>> can grow this to include other things as well as we go along.
>>
>> Here is how a component in the calculator sample uses logging intent.
>>
>> <component name="AddServiceComponent">
>> <implementation.java class="calculator.AddServiceImpl"
>> requires="logging"/>
>> </component>
>>
>> If you run the sample you will see an 'INFO' level log message now for
>> the
>> add function. If you change the 'logLevel' element to 'ALL' in the above
>> policyset, in the definitions.xml file of the calculator sample and run
>> again, you'd see more log statements.
>>
>> I guess applications can use this policyset structure to define their
>> logging options. If more options are to be supported such as specifying
>> additional log handler classes etc. we need to go and extend the
>> processor
>> and the handler class in the policy.logging module. I'll do this as an
>> when
>> I get feedback on this.
>>
>> While the current set up enables logging in the java implementation
>> extension, the logging intent and policy can also be used to configure
>> logging within the business logic implementation too, since JDK logging
>> functions at a global level. So, from the SCA composite level you could
>> instrument the logging within implementations. I will add something that
>> demonstrates this, into the calculator sample... hope I am right in my
>> supposition :)
>>
>> Thanks
>>
>> - Venkat
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy support for implementation elements
Posted by Mike Edwards <mi...@gmail.com>.
Venkat,
I'm sorry to be a party pooper here, but I don't think that the use of
logging via an intent is a good way of doing things.
The SCA idea of intents is that they are a way of expressing
requirements that an implementation has (or a service or a reference).
So, for a service, it's possible to say "I need my messages encrypted"
by using @requires="confidentiality". For an implementation, one of the
transaction intents like @requires="managedTransaction" would also be
reasonable.
Logging is a very different thing, in my opinion. It seems like
something that is really a runtime configuration option. I can see that
it is useful to tell the runtime to log or not to log, and how much to
log, but I'm really struggling to see why I'd mark my implementations or
my composites with metadata about logging.
Now, I'm not against capturing the logging levels within a PolicySet, it
that is convenient. But the application of those policies to the
runtime does look like an act of configuring the runtime itself ("start
the runtime with PolicySets X, Y, Z.....")
Yours, Mike.
Venkata Krishnan wrote:
> Hi...
>
> I have set up a policyset for JDKLogging and a policy handler for the same.
> All this is now in a separate module called policy-logging. I have hooked
> up the policyhandler in the java impl runtime. It would be good if folks
> can give me opinion on the hooks I have placed to setup and invoke policies.
>
> I have modified the calculator sample to include the jdk logging policy.
> Here is the policyset that is used....
>
> <policySet name="tuscany:JDKLoggingPolicy"
> provides="logging"
> appliesTo="sca:implementation.java"
> xmlns="http://www.osoa.org/xmlns/sca/1.0">
> <tuscany:jdkLogger xmlns:tuscany="
> http://tuscany.apache.org/xmlns/sca/1.0" name="test.logger">
> <logLevel>INFO</logLevel>
> <resourceBundle>CalculatorLogMessages</resourceBundle>
> <useParentHandlers>false</useParentHandlers>
> </tuscany:jdkLogger>
> </policySet>
>
> This is just a few of the things that we could configure in JDK Logging. We
> can grow this to include other things as well as we go along.
>
> Here is how a component in the calculator sample uses logging intent.
>
> <component name="AddServiceComponent">
> <implementation.java class="calculator.AddServiceImpl"
> requires="logging"/>
> </component>
>
> If you run the sample you will see an 'INFO' level log message now for the
> add function. If you change the 'logLevel' element to 'ALL' in the above
> policyset, in the definitions.xml file of the calculator sample and run
> again, you'd see more log statements.
>
> I guess applications can use this policyset structure to define their
> logging options. If more options are to be supported such as specifying
> additional log handler classes etc. we need to go and extend the processor
> and the handler class in the policy.logging module. I'll do this as an when
> I get feedback on this.
>
> While the current set up enables logging in the java implementation
> extension, the logging intent and policy can also be used to configure
> logging within the business logic implementation too, since JDK logging
> functions at a global level. So, from the SCA composite level you could
> instrument the logging within implementations. I will add something that
> demonstrates this, into the calculator sample... hope I am right in my
> supposition :)
>
> Thanks
>
> - Venkat
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy support for implementation elements
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi...
I have set up a policyset for JDKLogging and a policy handler for the same.
All this is now in a separate module called policy-logging. I have hooked
up the policyhandler in the java impl runtime. It would be good if folks
can give me opinion on the hooks I have placed to setup and invoke policies.
I have modified the calculator sample to include the jdk logging policy.
Here is the policyset that is used....
<policySet name="tuscany:JDKLoggingPolicy"
provides="logging"
appliesTo="sca:implementation.java"
xmlns="http://www.osoa.org/xmlns/sca/1.0">
<tuscany:jdkLogger xmlns:tuscany="
http://tuscany.apache.org/xmlns/sca/1.0" name="test.logger">
<logLevel>INFO</logLevel>
<resourceBundle>CalculatorLogMessages</resourceBundle>
<useParentHandlers>false</useParentHandlers>
</tuscany:jdkLogger>
</policySet>
This is just a few of the things that we could configure in JDK Logging. We
can grow this to include other things as well as we go along.
Here is how a component in the calculator sample uses logging intent.
<component name="AddServiceComponent">
<implementation.java class="calculator.AddServiceImpl"
requires="logging"/>
</component>
If you run the sample you will see an 'INFO' level log message now for the
add function. If you change the 'logLevel' element to 'ALL' in the above
policyset, in the definitions.xml file of the calculator sample and run
again, you'd see more log statements.
I guess applications can use this policyset structure to define their
logging options. If more options are to be supported such as specifying
additional log handler classes etc. we need to go and extend the processor
and the handler class in the policy.logging module. I'll do this as an when
I get feedback on this.
While the current set up enables logging in the java implementation
extension, the logging intent and policy can also be used to configure
logging within the business logic implementation too, since JDK logging
functions at a global level. So, from the SCA composite level you could
instrument the logging within implementations. I will add something that
demonstrates this, into the calculator sample... hope I am right in my
supposition :)
Thanks
- Venkat
On 10/9/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Venkata Krishnan wrote:
> > Hi,
> >
> > I've been trying to figure out if there is a common pattern in how
> > implementations and bindings could be interpretting and applying
> policies so
> > that we could include this in the SPI. But haven't been successful with
> > this. Maybe with getting policies to work with a few implementation
> types
> > will give a better idea.
> >
> > So, to start with I have extended the java implementaion type a bit to
> > support policies. I have picked on the 'Logging' intent for now and
> have
> > implemented a rudimentary logging mechanism that simply uses
> > System.out.println. I am going to soon replace this with a formal
> Logging
> > system. I've been looking a SLF4J so that we could facilitate switching
> of
> > various logging implementations thro policy specifications. But seems
> like
> > there is no programmatic way of binding the logging options (such as
> log4j
> > or JDK Logging) into SLF4J. The logging implementation jar in the
> > classpath is the one that would get picked up it seems. So for now I
> plan
> > to go on with using the JDK Logger and having policies to specify the
> > logging levels, logging handlers and so on.
> >
>
> +1 to use the JDK logger as this is what we're using for logging inside
> the Tuscany runtime as well.
>
> Is the Logging policy a sample policy? or are you planning to make it
> available in Tuscany for people to use in their applications?
>
> Can you show what the XML to turn logging on looks like?
>
> > While I am working on completing this, I'd like to explore another
> > implementation type for including policy support for a QoS - maybe
> > transactions.
> >
>
> Good idea! There's a public draft of a Transaction spec at OSOA and
> several people on the dev and user list have expressed an interest in
> the transaction policy.
> > I'd appreciate a lot if people could give me some feedback on the
> approach I
> > have taken for the java implementation type and also suggestions on a
> > implementation type that we could pickup for supporting transactions.
> >
>
> How about changing the Online Store sample to update a database from the
> ShoppingCart Java component as a starting point?
>
> > Thanks.
> >
> > - Venkat
> >
> >
>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Policies associated with an operation, was Re: Policy support for implementation elements
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
Yes this is something that I want to resolve along with what I am facing
with policies for implementation elements. I suppose the problem is just
about similar.
Thanks.
- Venkat
On 10/9/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Jean-Sebastien Delfino wrote:
> > Venkata Krishnan wrote:
> >> Hi,
> >>
> >> I've been trying to figure out if there is a common pattern in how
> >> implementations and bindings could be interpretting and applying
> >> policies so
> >> that we could include this in the SPI. But haven't been successful
> with
> >> this. Maybe with getting policies to work with a few implementation
> >> types
> >> will give a better idea.
> >>
> Looking at this I noticed that Policy.getOperations() is still commented
> out. Are you going to put the operation support back?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Policies associated with an operation, was Re: Policy support for
implementation elements
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Venkata Krishnan wrote:
>> Hi,
>>
>> I've been trying to figure out if there is a common pattern in how
>> implementations and bindings could be interpretting and applying
>> policies so
>> that we could include this in the SPI. But haven't been successful with
>> this. Maybe with getting policies to work with a few implementation
>> types
>> will give a better idea.
>>
Looking at this I noticed that Policy.getOperations() is still commented
out. Are you going to put the operation support back?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy support for implementation elements
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
> Hi,
>
> I've been trying to figure out if there is a common pattern in how
> implementations and bindings could be interpretting and applying policies so
> that we could include this in the SPI. But haven't been successful with
> this. Maybe with getting policies to work with a few implementation types
> will give a better idea.
>
> So, to start with I have extended the java implementaion type a bit to
> support policies. I have picked on the 'Logging' intent for now and have
> implemented a rudimentary logging mechanism that simply uses
> System.out.println. I am going to soon replace this with a formal Logging
> system. I've been looking a SLF4J so that we could facilitate switching of
> various logging implementations thro policy specifications. But seems like
> there is no programmatic way of binding the logging options (such as log4j
> or JDK Logging) into SLF4J. The logging implementation jar in the
> classpath is the one that would get picked up it seems. So for now I plan
> to go on with using the JDK Logger and having policies to specify the
> logging levels, logging handlers and so on.
>
+1 to use the JDK logger as this is what we're using for logging inside
the Tuscany runtime as well.
Is the Logging policy a sample policy? or are you planning to make it
available in Tuscany for people to use in their applications?
Can you show what the XML to turn logging on looks like?
> While I am working on completing this, I'd like to explore another
> implementation type for including policy support for a QoS - maybe
> transactions.
>
Good idea! There's a public draft of a Transaction spec at OSOA and
several people on the dev and user list have expressed an interest in
the transaction policy.
> I'd appreciate a lot if people could give me some feedback on the approach I
> have taken for the java implementation type and also suggestions on a
> implementation type that we could pickup for supporting transactions.
>
How about changing the Online Store sample to update a database from the
ShoppingCart Java component as a starting point?
> Thanks.
>
> - Venkat
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy support for implementation elements
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
I've been trying to figure out if there is a common pattern in how
implementations and bindings could be interpretting and applying policies so
that we could include this in the SPI. But haven't been successful with
this. Maybe with getting policies to work with a few implementation types
will give a better idea.
So, to start with I have extended the java implementaion type a bit to
support policies. I have picked on the 'Logging' intent for now and have
implemented a rudimentary logging mechanism that simply uses
System.out.println. I am going to soon replace this with a formal Logging
system. I've been looking a SLF4J so that we could facilitate switching of
various logging implementations thro policy specifications. But seems like
there is no programmatic way of binding the logging options (such as log4j
or JDK Logging) into SLF4J. The logging implementation jar in the
classpath is the one that would get picked up it seems. So for now I plan
to go on with using the JDK Logger and having policies to specify the
logging levels, logging handlers and so on.
While I am working on completing this, I'd like to explore another
implementation type for including policy support for a QoS - maybe
transactions.
I'd appreciate a lot if people could give me some feedback on the approach I
have taken for the java implementation type and also suggestions on a
implementation type that we could pickup for supporting transactions.
Thanks.
- Venkat