Describe the details of your problem as I have no trouble using log4j in
ejbs,
servlets, etc. The log4j classes are loaded by the mlet class loader and are
available to all other classes.
----- Original Message -----
From: "John Cho" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 04, 2001 5:57 PM
Subject: [JBoss-dev] Architecture Qs for Log4J/JBoss
> Hi,
>
> I'm running into an interesting dilemma with Log4J. I'm guessing JBoss
> (2.4.0final) uses Log4J internally as a logging mechanism and exports some
> of the functionality via a Log4J MLET. Because of the way the Log4J
> classes are loaded by this MLET, none of those standard Log4J classes/apis
> are exposed to EJBs, MBeans, or Message Driven Beans.
>
> All of my EJBs, MBeans, and Message Driven Beans having been accessing
> Log4J directly and they don't work when deployed under JBoss for obvious
> reasons.
>
> I don't want to use the wrapper logging apis to get to Log4J because my
> beans have to be portable across multiple application servers. Which
> leaves me with the following two choices:
>
> 1.) disable the Log4J MLET in JBoss and add the log4j.jar file to the run
> path so that all classes have direct access to it -- works but I get some
> errors from JBoss saying that it can't find the TracePriority class which
> I'm guessing is loaded out of the jboss.jar by the MLET which I've now
> disabled... and although this method works now, how do I know it'll work
> in future releases of JBoss?
>
> 2.) write a wrapper for all my beans... the wrapper uses the Log4J MLET
> when running under JBoss and uses Log4J directly when running on any other
> application server... -- would probably work but would run slower and it
> seems ridiculous to have to do all that work...
>
> I guess the basic problem is that Log4J was written to only have one
> instance running in a VM and since that one instance is used by JBoss, I'm
> forced to disable that instance (option #1) or use that instance in a
> portable way (option #2)...
>
> I was wondering if there has been any consideration given to this problem
> as Log4J is by far the most popular/used logging package out there and
> other people must also be having this same problem unless coding only for
> the JBoss platform... there must be some way of architecting this Log4J
> support so that developers are allowed to access Log4J directly.
>
> Any thoughts appreciated.
>
> john
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
