Viv,
For solution #1 to work, your WAR file needs to live inside an EAR file. So
your EAR file would look something like:
/
myapp.war
META-INF/
application.xml
jboss-app.xml
Where the classloading settings are placed in the jboss-app.xml. Also,
please recall that you WAR file should, in turn look something like (NOTE in
particular the presence of log4j.jar in the WEB-INF/lib dir):
/
WEB-INF/
web.xml
jboss-web.xml
lib/
log4.jar
classes/
log4j.properties
Manually setting a properties configurator _may_ affect the containers
logging, depending on what the settings in the file happen to be, and
whether or not you provide your own copy of the log4j.jar embedded within
your web-app. The key here is really ClassLoading. If you can get
Tomcat/Jboss to load the log4j.jar in a local application ClassLoader
everything else is easy. If you cannot, then any configuration file you
manually read will potentially affect the current log4j settings that the
container uses.
-Don
-----Original Message-----
From: Viv Kap [mailto:[EMAIL PROTECTED]
Sent: Monday, June 14, 2004 12:44 AM
To: Log4J Users List
Cc: [EMAIL PROTECTED]
Subject: RE: Property Configurator
Hi Donald
Thank you very much for your suggestions. I tried approach # 2 but it did
not work. So I tried setting the other attribute ( <attribute
name="UseJBossWebLoader">false</attribute> ) But no luck
I like the Solution #1 too. But I tried it using war file and using
jboss-web.xml.
jboss-web>
<class-loading java2ClassLoadingCompliance="false">
<loader-repository>
org.apache:loader=prism.war
<loader-repository-config>java2ParentDelegation=false</loader-repository-con
fig>
</loader-repository>
</class-loading>
</jboss-web>
But this not help too. Does it have to be a .ear for the local scoping to
work ?
After trying everything I tried to see if I can use PropertyConfiguration
and pick up the log4j.properties file from a config directory in the file
system. But seems like this is affecting JBosse's loggng ? Is that true ?
Will setting a PropertyConfiguration in our J2ee application effect the
containers logging ?
Thanks for your help
-_Viv
Thanks for your help
--- Donald Larmee <[EMAIL PROTECTED]> wrote:
> Viv,
>
> The jBoss behavior is not only as a result of the container using
> log4j for its own internal logging, but as a consequence of the jBoss
> Unified ClassLoader methodology, whereby they _intentionally_ share
> jars across applications that have been loaded by the container.
> Some people see this
> as a benefit; some as, umm, not.
>
> Anyway, If you wish to force jBoss to behave a bit more like most J2EE
> containers (and therefore avoid the whole property configurator bit)
> you can try the following approaches...
>
> ASSUMPTIONS:
> - You are using jBoss v3.2.x
> - You are interested in using log4j from w/in a WebApp, from your
> references to WEB-INF/classes & tomcat
>
> SOLUTION #1: Put your war in an ear file.
>
> 1.1- Plan on packaging your war file INSIDE an ear (myapp.ear, for
> purposes of this discussion)
> 1.2- In addition to placing your log4j.properties (or .xml) file in
> the WEB-INF/classes, place the log4j.jar file itself into the
> WEB-INF/lib dir.
> 1.3- Provide a jboss-app.xml file that packaged into your ear and
> looks something like the following:
>
> <jboss-app>
>
> <!-- The following provides EAR level scoping of classloading
> (i.e., J2EE style)
> -->
> <loader-repository>
> com.adc.affiliate:loader=myapp.ear
> </loader-repository>
>
> </jboss-app>
>
> SOLUTION #2: Tweak the embedded Tomcat ClassLoading model w/in jBoss
>
> 2.1- Modify the
>
$JBOSS_HOME/server/$MY_SERVER/deploy/jbossweb-tomcat41.sar/META-INF/jboss-se
> rvice.xml to change the ClassLoading compliance model...
>
> <server>
>
> <mbean
>
code="org.jboss.web.tomcat.tc4.EmbeddedTomcatService"
> name="jboss.web:service=WebServer">
>
> <!-- Get the flag indicating if the normal
> Java2 parent first class
> loading model should be used over the servlet
> 2.3 web container first
> model.
> -->
> <attribute
> name="Java2ClassLoadingCompliance">false</attribute>
> ...
> ...
> </server>
>
> SOLUTION #3: Use the suite of classes included in the log4j sandbox
> distribution (org.apache.log4j.servlet.*) to bootstrap log4j
> (InitServlet and InitContextListener)
>
> FWIW, I use approach #1 when I can.
>
> Hope it helps,
>
> -Don
>
>
> -----Original Message-----
> From: Viv Kap [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 11, 2004 6:40 PM
> To: [EMAIL PROTECTED]
> Subject: Property Configurator
>
> Hi
> I have a J2EE application and we use log4j for logging. We used
> log4j.properties files and packaged it in a war under WEB-INF/classes.
> It all worked fine under Weblogic, Tomcat etc.
> But now when we migrated to JBoss it has its own log4j.xml file. So
> our application grabbed it as the first one and did not load our
> log4j.properties.
> I got around it by using
> -Dlog4j.configuration=log4j.properties in the startup command.
> But I really dont like this soultion because this system property will
> now be applicabe to all applications on JBOSS and thats not a good
> thing.
> Now we are plannning to use our own name like
> log4j-productName.properties file and make use of
> PropertyConfigurator.
> From the startup command we will pass the directory name containg
> config files : example -Dproduct.config=c:/config . In this we will
> have the log4j-product.properties file.
> And we will load it and use PropertyConfigurator.
> But this is not working exactly. When we start the server it gives all
> sort of exception.
> where should I exactly use the PropertyConfigurator ?
> In a static block ? This is what I have
>
> String path =
> System.getProperty("config.home");
> Properties p = new Properties();
> try {
> FileInputStream fis = new
> FileInputStream(path + "/log4j-product.properties");
> p.load(fis);
> } catch (FileNotFoundException e) {
> e.printStackTrace(); //To change body of catch statement
> use Options | File Templates.
> } catch(java.io.IOException ie) {
> ie.printStackTrace();
> }
>
> PropertyConfigurator.configure(p);
>
>
> I get this error:
> 04-06-11 15:32:53,924 INFO [STDOUT] log4j:ERROR
> "org.jboss.logging.util.OnlyOnceErrorHandler" was loaded by
>
[EMAIL PROTECTED]
> 2004-06-11 15:32:53,924 DEBUG
> [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2004-06-11 15:32:53,924 DEBUG
> [org.jboss.mx.loading.UnifiedClassLoader]
> setRepository,
>
[EMAIL PROTECTED],
> [EMAIL PROTECTED]
> url=null ,addedOrder=0}
> 2004-06-11 15:32:53,924 DEBUG
> [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2004-06-11 15:32:53,924 DEBUG
> [org.jboss.mx.loading.UnifiedClassLoader]
> setRepository, r=org
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Friends. Fun. Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
