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

[Kevin Ruland]

Jing Tao wrote:

> Hi, Kevin:
>
> It is not good idea to use EcogridUtil in Kpler. I think we should
> remove them from DarwinCoreMetaDataSpecification and DarwinCoreSchema.
>
Jing,

I'm completely with you there.  I'm already digging about both those
classes and will take a stab at getting rid of those calls.  I think
they are using the xml helper stuff.

My longer term goals (2 weeks maybe...) is to get rid of the need for
both the "Transformer" classes in Kepler.  This is the right thing to do.

Another problem is the use of EcogridUtil in
EcogridFactoryRegistryCleint.  I don't know what the calls are but if
they are calls to the debug logger, they need to go away.  All the
output from kepler should be controlled by kepler and not be a side
effect of some jar.  -- of course, we could slip a System.property call
into the jar to enable/disable logging -- seems like a lot of work for a
little benefit.  The caller of these methods should accomodate errors
and report as necessary.

> It seems worth to use log4j to replace 308 debugMessage :)
>
It's easier to count that it is to change.  Some of the nicer editors
like emacs or sed </sarcasm> should be able to convert 90% of em
automatically though.

Kevin

> 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
>>>>
>>