Thanks for the responses,
I figured out what the problem was. I was starting JBoss with a wrapper
that calls org.jboss.Main directly. That wrapper was making some calls
(test calls that I forgot about) directly to some of the MBeans and EJBs..
since the wrapper's classes are loaded using an external class loader, the
log4j classes were unavailable to it..
Sorry for bringing this up inside the dev list.. thought it was some funky
architectural issue which it was not.. thanks again!
john
On Tue, 4 Sep 2001, Scott M Stark wrote:
> 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
