Re: Policy support for implementation elements

Mon, 26 Nov 2007 13:18:07 -0800

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" <[EMAIL PROTECTED]>

To: <tuscany-dev@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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]























					Reply via email to