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