log4j

[tom.baeyens]

Alejandro,

You've introduced log4j. Can you identify precisely where it is required ? Is it avoidable ?

Can you also list the other dependencies you've introduced ? And how these are transitive ?

I want the ivy.xml to contain the real transitive dependencies as to which lib is using which lib.

Since we don't use log4j but java.logging, it should be removed from the pvm ivy file in the end. So we should know which lib needs it and bring the ivy repo up to date in that respect.

Can you post all the knowledge you have about the libs and their dependencies here ?

[tom.baeyens]

Can you post all the knowledge you have about the libs and their dependencies here ?

I meant of course only the new libs that you recently introduced with the enterprise move :-)

[kukeltje]

I'm interested in the 'why' of moving from log4j (or more specific commons logging) to java.logging

[estaub]

>> I'm interested in the 'why' of moving from log4j (or more specific commons logging) to java.logging

Yes... I would like to be able to have unified logging to a single log file, in a situation where JBPM is one component. This means that everything needs to funnel to the same back end. Your mileage may differ, but I don't see much use of java.logging.

log4j is the most likely place that all the other config files are set up for.
commons logging allows the integrator to integrate with something else, if desired.

A viable alternative to commons logging, used in Hibernate FWIW, is slf4j. It is architecturally quite different from commons logging. It has the advantage of not trying to do dynamic loading of the underlying logger - thus avoiding a lot of snafus with J2EE containers and other dynamic classloaders. If this were used, I'd recommend using it with log4j as the back end, for common config-file syntax.

[tom.baeyens]

i want pvm to run without external library dependencies.

i don't have a problem with writing a lava.util.logging - to - log4j bridge in case people want it.

i was looking into that under the assumption that such a thing would already exist in jboss. but it doesn't seem to be.

so we probably have to provide it ourselves.

[tom.baeyens]

i added a simple pluggability layer in the pvm code itself:

1) if logging.properties is available on the classpath then java util logging will be used.

2) if log4j is on the classpath, then log4j will be used

3) if none of the above, java util logging will be used anyway

when java util logging is used, a property is checked in the logging.properties configuration. if the property 'redirect.commons.logging' is set, then commons logging is redirected to java util jdk logging (even if log4j is on the classpath)

we could add a check for commons logging if that would be desired, but i don't yet see the need for that.

[aguizar]

I propose renaming the org.jbpm.log package to org.jbpm.yalf - yet another logging facade :-)

Seriously tough, since Hibernate will switch from commons-logging to slf4j in version 3.3 (see HHH-2696) I support Ed's suggestion of adopting it rather than cooking our own solution. In most cases the pvm will be deployed with hibernate, and slf4j will be a (transitive) dependency anyway. I don't think a small extra dependency is worth not leveraging a product that seems to fit the bill so well.

[aguizar]

Regarding the original post: the new dependencies introduced by the enterprise components are:
jboss - j2ee - 4.2.1.GA - enterprise->default
apache - cactus - 1.7.2 - compile, test.enterprise->default Other dependencies that I declared earlier, namely commons-httpclient, commons-codec, commons-logging and aspectj were actually cactus dependencies which are already declared in the corresponding ivy file for cactus.

[tom.baeyens]

i mind the extra dependency.

the only thing that could be better then in the current code is the auto detection and configuration. people know how commons-logging works. not sure how slf4j does it.

but our own mechanism has some form of auto-detecting the desired logging and binding to either java.util.logging or log4j.

how does that detection work in slf4j ?

another option that i'm willing to explore is to include the slf4j classes in the pvm sources and rename the packages.

[tom.baeyens]

Regarding the original post: the new dependencies introduced by the enterprise components are:
<ul><li>jboss - j2ee - 4.2.1.GA - enterprise->default</li>
<li>apache - cactus - 1.7.2 - compile, test.enterprise->default</li></ul> Other dependencies that I declared earlier, namely commons-httpclient, commons-codec, commons-logging and aspectj were actually cactus dependencies which are already declared in the corresponding ivy file for cactus.

cool. thanks !

[estaub]

>> I want pvm to run without external library dependencies.

Here, here! Sorry I pushed otherwise.

>> how does that detection work in slf4j ?

(Given my comment above, this may be irrelevant...)
Slf4j takes the radical viewpoint that sooner or later, you need to have a meeting of minds with the underlying engine - and that sooner (build-time) is better than later (run-time) because of classloader problems, etc.

So slf4j comes with a variety of implementation jars that talk to back ends: log4j, jul, jcl, and logback (a new one from the slf4j/log4j author). You pick the jar for the back end you want to use. There IS no detection.

FWIW, it also comes with front-end "fakers" that impersonate log4j, jul, or jcl. You have to be careful to not include a "faker" that's the same as the back-end implementation - their classnames collide.

-ed

[tom.baeyens]

"estaub" wrote:
You pick the jar for the back end you want to use. There IS no detection.

ah. that makes sense. thanks for the clarification.

i still prefer to have it as part of the jbpm classes.

...tight call, though.

ps. can you ping me through email ? myfirstname dot mylastname at jboss dot com

[kukeltje]

Hahaha... Come on Tom don't be so careful in posting your email address. It is shown TWICE in each post you make.... in a way that can be used by spammers