yes, this is the right forum since im interested in this for the eclipse
plugins.
would be good if you could send the manifest.mf so i can relate it to the
text.
thanks.
/max
Max,
*1: Centralize all logging configuration to a single file: *
jdk1.4 logging: By default, jdk logging finds config file in jre/lib
directory, but this doesn't put control of the configuration into the
rcp provider unless the provider is also delivering a full jre. Better
to set the java.utils.logging.config.file property.
log4j: By default, log4j will find the config file 'log4j.properties'
in the classpath. Relying on this in Eclipse is possible (you can use
eclipse classloading buddy policy), but is non-deterministic because you
can't predict which pluguin Eclipse will find the file. Better to set
the command line property: log4j.configuration.
At productization time, command line properties for your rcp product are
set in the launching arguments section of the configuration page in the
product editor.
During plugin development and testing, you can set command line
properties in the VM arguments text panel your plugin's Run
configuration. Find the Run configuration by selecting Run... from the
Run workbench menu.
*2: Appender in hibernate plugin can be found by the log4j plugin:*
Assuming there is a log4j plugin..... The log4j plugin must have a
Buddy Policy that will make visible appenders contributed by other
plugins. I choose 'registered':
Eclipse-BuddyPolicy: registered
in its Manifest.MF file. Then, any plugin that has an appender would
register as a buddy with the log4j plugin with
Eclipse-BuddyRegister: org.apache.log4j
This assumes the log4j plugin is named org.apache.log4j. This is a good
assumption because McAffer's book promotes the convention that a code
library plugin is named for the java package within.
In reality, there isn't an eclipse log4j plugin. McAffer's book
suggests this would be a job for Apache logging project.
*3: How to swap among logging frameworks: log4j, jdk1.4, SimpleLog,
nlog4j*
Assume there are code library plugins for slf4j, one plugin for each
framework that slf4j supports. For example, org.slf4j.log4j is a plugin
that contains interface code to log4j, org.slf4j.jdk14 contains
interface code for jdk logging api. Also, each of these plugins
contains a copy of slf4j's commons-logging implementation. All of these
plugins export the org.apache.commons.logging packages and the org.slf4j
packages.
Your plugin that invokes the logging api must import the logging api.
Use 'import' not 'required' to declare to eclipse your plugin's
dependencies. 'Required' means your plugin depends on a specific plugin
by name; 'import' means your plugin depends on any resolved, enabled
plugin that exports the named packages. In the dependencies page of
your plugin's manifest editor, put the logging api packages in the
'import' panel: org.apache.commons.logging,
org.apache.commons.logging.impl, org.slf4j, org.slf4j.impl,
org.slf4j.spi.
I hope you have setup a plugin development target. It isolates your
development bed from your eclipse installation plugins. Load the log4j
plugin and the org.slf4j.log4j plugin into your target. To swap from
one framework to the other, say from log4j to jdk logging, load and
enable the org.slf4j.jdk14 plugin into your target, and disable the
org.slf4j.log4j plugin you have been using.
I think the swap capability is cool but not something an rcp end user
would be interested in taking advantage of. For a developer of a code
library plugin, like hibernate or its dependencies, this capability
means that the rcp developers which use your plugins won't be tied to
log4j. I also think this capability is useful for hibernate, like for
swapping multiple cache implementation plugins, but I don't know enough
about the cache api and am guessing.
*Sidebar:* Creating a code library plugin is very easy and takes only a
few minutes. Create a new project -> plugin development -> plugin from
existing jar files, select the jar files to be included, modify the
manifest (imports, exports), and thats it. Wouldn't it be nice if
providers of code libraries did this for you?
I can send the MANIFEST.MF file for each of the code library plugins
I've created. Is this the right forum?
John
Max Rydahl Andersen wrote:
I also found solutions to some other issues like: how to centralize
all logging configuration to a single file, and how an appender in
hibernate plugin can be found by the log4j plugin, and how to swap
to a different slf4j implementation library so jdk logging, nlog4j
or simple log
I'm willing to share the details if you are interested.
I'm definitly interested.
/max
John
Max Rydahl Andersen wrote:
yes, i also find slf4j interesting, but afaik it won't help solve
the logging problem while other components i use uses common logging.
And it will also still have issues with duplicate configuration
etc., but im not sure.
/max
Hi.
When developing eclipse plugins, I ended up with a severe
limitation when a
plugins makes reference to the apache-commons-logging library AND
each
other.
Well, digging around I found the slf4j library
(http://www.slf4j.org/) that
seems to solve my problem.
The cenario where the problem arose was eclipse, where my plugin may
reference or not hibernate's plugin, and both had apache log. Each
plugin
MAY exist without the other, so each one must have logging, but
when they
are both used, we got classloading problems.
I'm testing this new library now in the java.tri plugin. It may
be usefull
to the hibernate-tools.
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
[EMAIL PROTECTED]
http://hibernate.org
JBoss Inc
[EMAIL PROTECTED]
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
