[seek-dev] changing ecogrid server side to use commons-logging.

[Jing Tao]

Hi, Kevin:

It is not good idea to use EcogridUtil in Kpler. I think we should remove 
them from DarwinCoreMetaDataSpecification and DarwinCoreSchema.

It seems worth to use log4j to replace 308 debugMessage :)

Thanks,

Jing


Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101

On Wed, 7 Sep 2005, Kevin Ruland wrote:

> Date: Wed, 07 Sep 2005 16:25:43 -0500
> From: Kevin Ruland <kruland at ku.edu>
> To: Jing Tao <tao at nceas.ucsb.edu>
> Cc: seek-dev at ecoinformatics.org
> Subject: Re: [seek-dev] changing ecogrid server side to use commons-logging.
> 
> Jing,
>
> There is some code confusion with the EcogridUtils class.  Currently it
> is placed in the client side jar files (ecogrid-registry-client.jar) and
> delivered to the kepler application.  It is then used by a few classes
> from the client jar (EcogridFactoryRegistryClient,
> DigirJavaToEcogridJavaResultsetTransformer,
> EcogridJavaToDigirJavaQueryTransformer) and the kepler classes:
> o.e.s.datasource.darwincore.DarwinCoreMetaDataSpecification and
> DarwinCoreSchema.
>
> The EcogridUtils class appears to be a catch-all for the static helper
> methods used in ecogrid.  It has logging functions, xml helpers and
> bunch of other things in it.  I suggest we agressively try to remove
> functionality from it and seperate the functions into neat classes
> collecting common functionality.
>
> The final problems are related to the way log4j works.  The logger
> object needs to be handed a class name in order to be properly
> configured by the properties file and the log message prints out the
> class name of the caller.  So by hiding the logger.debug() call in
> EcogridUtils, you end up losing a lot of the functionality
> commons-logging provides.
>
> I do realize there are 308 debugMessage() lines in 22 different classes
> and this does pose a fairly major change.  But in the end it will be
> worth it.
>
> Kevin
>
> Jing Tao wrote:
>
>> Hi, Kevin:
>>
>> It seems good plan to use commons-loggin/log4j infrastructure. But I
>> have a suggestion: rather than change every
>> "EcogridUtils.debugMessage" to
>> "logger.debug", we can modify EcogridUtil.debugMessage directly.
>> Currently EcogridUtil.debugMessage use System.err.println and we can
>> change to use the commons-loggin/log4j.
>>
>> How do you think this apporach?
>>
>> Thanks,
>>
>> Jing
>>
>> Jing Tao
>> National Center for Ecological
>> Analysis and Synthesis (NCEAS)
>> 735 State St. Suite 204
>> Santa Barbara, CA 93101
>>
>> On Wed, 7 Sep 2005, Kevin Ruland wrote:
>>
>>> Date: Wed, 07 Sep 2005 14:12:12 -0500
>>> From: Kevin Ruland <kruland at ku.edu>
>>> To: seek-dev at ecoinformatics.org
>>> Subject: [seek-dev] changing ecogrid server side to use commons-logging.
>>>
>>>
>>> Jing,
>>>
>>> Globus grid services use commons-logging/log4j infrastructure for all
>>> its output.  I decided to make the Digir implementation follow these
>>> lines because it allows easier configuration of log messages.  Matt
>>> suggested it we should try to move all the ecogrid server code to using
>>> this logging mechanism.  Allow me the chance to highlight the changes
>>> needed for this.
>>>
>>> Where before in DigirProxyImpl, it would do this:
>>>
>>> import org.ecoinformatics.ecogrid.EcogridUtils;
>>>
>>> public class DigirProxyImpl implements
>>> EcoGridQueryInterfaceLevelOnePortType {
>>>
>>> public DigirProxyImpl()
>>> {
>>>  EcogridUtils.setDebug(true);
>>>  EcogridUtils.debugMessage( "DigirProxyImpl Constructor", 1 );
>>> }
>>> }
>>>
>>>
>>> It now looks like this:
>>>
>>> import org.apache.commons.logging.Log;
>>> import org.apache.commons.logging.LogFactory;
>>>
>>> public class DigirProxyImpl implements
>>> EcoGridQueryInterfaceLevelOnePortType {
>>>    static Log logger  = LogFactory.getLog(
>>> DigirProxyImpl.class.getName());
>>>
>>>  public DigirProxyImpl()
>>>  {
>>>    if (Logger.isDebugEnabled()) {
>>>     logger.debug("DigirProxyImpl Constructor" );
>>>   }
>>>  }
>>> }
>>>
>>> In reality the test for isDebugEnabled() is not required, but it does
>>> provide performance improvement if the message arguments are expensive
>>> to construct.  In this example, it would read much better without it.
>>>
>>> In order to enable logging in the deployed server, you need to correct
>>> one problem that ogsa's ant deployTomcat introduces.  You need to mv
>>> webapps/ogsa/WEB-INF/ogsilogging.properties to
>>> webapps/ogsa/WEB-INF/classes/ogsilogging.properties.  I corrected the
>>> globus build-services.xml to copy it into the correct location to begin
>>> with.
>>>
>>> Now in order to enable debug level for your class you need to insert a
>>> line in the ogsilogging.properties:
>>>
>>> org.ecoinformatics.ecogrid.digir.impl.DigirProxyImpl=console,debug
>>>
>>> All the log messages sent to console end up in catalina.out.  There
>>> should be a way to configure the logging properties to redirect to a
>>> different file, but I haven't needed to so didn't look for the answer.
>>>
>>> Kevin
>>> _______________________________________________
>>> Seek-dev mailing list
>>> Seek-dev at ecoinformatics.org
>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-dev
>>>
>