RE: FYI: Logging in Enhydra 5.1 vs Enhydra5.0

Hi.

>Daniel Germain:
>I'm currently getting a look at enhydra5.1 wich have a more
>powerfull logging system but take note that old construct such as
>Enhydra.getLogChannel().write(Logger.INFO,msg);
>Enhydra.getLogChannel().write(Logger.DEBUG,msg);
>Enhydra.getLogChannel().write(Logger.ERROR,msg);
>are now all logged under the same level: INFO

Thank you for finding this bug. It is now removed.
Construct like:
Enhydra.getLogChannel().write(Logger.<LEVEL>, msg)
should log just under the <LEVEL> now, not under the INFO.

Notice that LogChannel is not removed from Enhydra 5.1 (for compatibility
with old applications), but its usage is discouraged, for it logs slower
than org.apache.log4j.Logger.
But, if you prefer old way of logging, there is an interesting new feature:
a new logger can be added in log4j.xml configuration file, which can be used
to log just from your application.
The name of that logger should be the same with the name of your class which
extends StandardApplication (without package names).

For example, if you have class:
public class MyEnhydraApp extends StandardApplication

appropriate logger (with appender) in log4j.xml will be:
    <appender name="Console" class="org.apache.log4j.ConsoleAppender">
        <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="%d{ISO8601}: %p: %m%n"/>
        </layout>
    </appender>
    <logger name="MyEnhydraApp" additivity="false">
        <level value="info"/> <!-- all, debug, info, warn, error, fatal,
off -->
        <appender-ref ref="Console"/>
    </logger>

With this lines, you do not have to use org.apache.log4j.Logger explicitly
to log in "MyEnhydraApp" logger.
Just use
Enhydra.getLogChannel().write(Logger.<LEVEL>, msg)
and logs from your application will be separated from other (root) logs.


>exception.printStackTrace(Enhydra.getLogChannel().getLogWriter(Logger.ERROR
));
>will now throw a NullPointerException because Enhydra.getLogChannel()
>return a null pointer.

A null pointer is returned from getLogWriter(...).
Please, use some of the new logging features, or explain (in more details)
your need for LogWriter class.


>Also the default setting I used to take (INFO) now receives
>a lot informative messages from the classes MultiClassLoader, ClassPath
>and ClassPathEntry everytime a class is loaded, but it is probably
>just a matter of configuration to get rid of them by default

Thanks for this remark. Classes MultiClassLoader, ClassPath and
ClassPathEntry were hard coded to log under the INFO level, but it is now
changed to DEBUG.

>Note also that the generated classes from the new DODS now
>   have two constructs in private void runQuery()
>   that are using System.out.println
>System.out.println("DocumentDO"+" Read from Database");
>System.out.println("DocumentDO"+" Read from Cache");
>Should not they be removed?

Thanks again. They will be removed.

Dragan

Together
Novi Sad
Serbia

-----Original Message-----
From: enhydra-admin@xxxxxxxxxxx [mailto:enhydra-admin@xxxxxxxxxxx]On
Behalf Of Daniel Germain
Sent: Thursday, March 27, 2003 3:12 PM
To: enhydra@xxxxxxxxxxx
Subject: Enhydra: FYI: Logging in Enhydra 5.1 vs Enhydra5.0


Hi,

1)
I'm currently getting a look at enhydra5.1 which have a more
powerfull logging system but take note that old construct such as

Enhydra.getLogChannel().write(Logger.INFO,msg);
Enhydra.getLogChannel().write(Logger.DEBUG,msg);
Enhydra.getLogChannel().write(Logger.ERROR,msg);

are now all logged under the same level: INFO

2) and take also note that construct such as

exception.printStackTrace(Enhydra.getLogChannel().getLogWriter(Logger.ERROR)
);

will now throw a NullPointerException because Enhydra.getLogChannel()
return a null pointer.


3)
Also the default setting I used to take (INFO) now receives
a lot informative messages from the classes MultiClassLoader, ClassPath
and ClassPathEntry everytime a class is loaded, but it is probably
just a matter of configuration to get rid of them by default
(in my to do list)

4) Note also that the generated classes from the new DODS now
   have two constructs in private void runQuery()
   that are using System.out.println
System.out.println("DocumentDO"+" Read from Database");
System.out.println("DocumentDO"+" Read from Cache");
Should not they be removed?

5) BTW I recently talk about a problem I had
with using comma separated string in the configuration.
I solve my problem, it was the quote.
I should not have used
Server.ClassPath[] = "path1/classe1.jar, path2/classe2.jar"
but
Server.ClassPath[] = "path1/classe1.jar" , "path2/classe2.jar"

Daniel

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail

_______________________________________________
Enhydra mailing list
Enhydra@xxxxxxxxxxx
http://www.enhydra.org/mailman/listinfo.cgi/enhydra