JBossDeveloper

sed s/jndi/log4j/

I must preview my posts :-)

Regards,
Adrian

Hi,
I am using jboss 2.2.2 with tomcat 3.2.3, and I want to use different log4j properties file for the differnt webapps I have. Is it possible for me to borrow the JbossRepository and use it with 2.2.2.

Thanks,
Swami

It isn't done yet. :-(
log4j 1.2 is an alpha release.
Also, it needs a patched version of xdoclet for the
jboss build.

I will post a patch to sourceforge for JBoss3.0final
when that comes out.
The deployment and logging has changed quite a bit
since 2.2.2. I think that used a jboss logger that
forwarded notifications to log4j?
My first version of jboss was 2.4.3

Regards,
Adrian

The log4j 1.2beta 3 has been released. I am looking forward for your Repository Selector. Can you tell me how it would accomodate different webapps and ejb application in using their own log files.

Thanks for the update, I'll have a look at it. :-)

Each application (deployment) will get its own LoggerRepository (Logging Universe).
Each Logging Universe is isolated from the others,
configuration changes don't affect other universes.

The JBossRepositorySelector will be responsible for
assigning each deployment to a Logger Universe.
It will do this based on the classloader(s) given to
the application at deployment.

So when you do for example
Logger log = Logger.getLogger()

it will really do something like (psuedo-code)

Object context = Thread.currentThread().getContextClassLoader();
LoggerRepository repository = JBossRepositorySelector.get(context);
Logger log = repository.getLogger();

Of course this complication is hidden from you.

The overhead of the RepositorySelector is only done
when retrieving Loggers or doing configuration.
Normal logging operations are done through a Logger
which is already assigned to a repository.

I'm not entirely sure how to do the initial
configuration. I'm open to ideas.
The default will be to use the JBoss config.

Possibilities are:
1) Look for a log4j.properties or log4j.xml in META-INF
2) A new entry in jboss.xml or jboss-web.xml
3) Use a sar deployment within your app to deploy a
Log4jService for your application.

Regards,
Adrian

Just wanted to comment on the configuration part, using the log4j.properties or log4j.xml. This limits in the actual production environment where the log4j properties cannot be modified if the log4j is a part of war or ear file.

A new entry in Jboss.xml will require restarts of the jboss and hence it would be nice if we can avoid it.

So if I understand the Repository, the application code does not have to do anything specific but just do getLogger, and getInstance and do their logging. The JbossRepositorySelector will automatically detect the required log properties and will configure the appenders.
Is this right?

You've nearly got it right.

You use log4j normally, you need no knowledge of the
RepositorySelector.

The four parts are:

1) At application deployment a new LoggerRepository
is created for you. It is initially configured using
some mechanism (maybe one I described before?).

2) When the application requests a Logger, the
JBossRepositorySelector directs the request to the
correct LoggerRepository

3) When the application tries to configure log4j from
java code again the JBossRepositorySelector directs the
request to the correct LoggerRepository

4) The configuration needs to be exposed for management.
In 3.0 you can deploy an MBean with your application.
You could use this mechanism to deploy a Log4jService
to configure and watch the application's log4j.properties.
This might be the best way to do point 1.

I plan to go beyond the current Log4jService.
It currently only allows a url for the properties file.
I want to provide other configuration options.
The problem with configure and watch on a properties url is that you get a new thread (not very good on resources).

Regards,
Adrian

Because the jboss 2.4.4 is the actual release I would like to get this to work under 2.4.4. Please let me know how I can help you and may be port your idea(s) to jboss 2.4.4. So that we can take advantage of the log4j 1.2 in jboss 2.4.4.

Thanks,
swami

The first stage is to test current JBoss with log4j 1.2.

This requires a patch to JBoss and Xdoclet.
I've attached a patch from the dev-list. There's some
links at the bottom that show it is not wholly
applicable anymore.

We need to make sure log4j 1.2 won't introduce any
unexpected bugs.
Any testing you can provide would be greatly appreciated.

Regards,
Adrian

Oops,

Here's the link rather than the attachement.
http://www.mail-archive.com/jboss-development@lists.sourceforge.net/msg10808.html//www.mail-archive.com/jboss-development@lists.sourceforge.net/msg10808.html

Regards,
Adrian

I got the sources with the tag JBoss_2_4_4 and the usage of log4j is spread around the code, it would have been nice if everything was hidden under the org.jboss.logging.Logger and then all the other class calls the getInstance of this class rather than Category of log4j. I would like to proceed with changes provided I understand how to incorporate the JBossRepository for 2.4.4. Any thoughts?

Thanks,
Swami

Yeh,

I've started tidying this up in the 3.0 codebase.
It isn't necessary for the switch to log4j 1.2,
but it will avoid lots of deprecated messages during
compile. :-)
The things to change are
extends Category to extends Logger
extends Priority to extends Level

If you want to do the JBossRepositroy selector, go
ahead. My priority at the moment is JBossMX, but
I can help you do this.

It should look something like (warning untested code)
[pre]
public class JBossRepositorySelector
extends ServiceMBeanSupport
implements JBossRepositorySelectorMBean,
RepositorySelector
{
private final String MAGIC = "JBOSS";
private WeakHashMap assocs = new WeakHashMap();
private LoggerRepository default = null;

// Called by jboss at startup/deployment
protected void startService()
{
default = LogManager.getRootLogger().getLoggerRepository();
LogManager.setRepositorySelector(this, MAGIC);
}

// Called by jboss at stop/undeployment
protected void stopService()
{
// Remove self from LogManager????
}

// Add a classloader context to a repository
public void associate(ClassLoader cl, LoggerRepository lr)
{
assocs.put(cl, lr);
}

// Remove a classloader context to a repository
public void remove(ClassLoader cl)
{
assocs.remove(cl, lr);
}

// Return the associated repository or default
// system repository
public LoggerRepository getLoggerRepository()
{
LoggerRepository result = assocs.get(Thread.currentThread().getContextClassLoader());
if (result == null)
result = default;
return result;
}
}
[/pre]

Then the hard part is associating/removing classloaders
from the repository selector at deployment/undeployment.

For each deployment, create a new LoggerRepository.
For each classloader created by the deployment
invoke "assoc" at deployment and "remove" at undeployment
I haven't investigated the details of how to do this yet.
NOTE: The WebContainer will require special processing,
they tend to create their own classloaders.

Regards,
Adrian

Hello,

I have run into this problem and I tried various alternatives suggested in this thread and related other threads. Nothing seems to work.

I will greatly appreciate if someone please summarizes the steps needed for configuring log4j for an app with the following setup:

0) Where should I put log4j.properties?
1) Using JBoss3.04 with log4j1.2.6 (Logger, not Category!).
2) Application deployed as an EAR file.
3) Logging to file or console, whichever.
4) Support application logging to a separate file from Jboss server logging.
5) If Application is a SAR file, does anything change?
6) If older log4j, what is the setup?

For my part, I tried the following:
a) Since I thought it was a classloader issue, I tried using the jboss-app.xml to force the EAR classloader to be checked first for log4j.properties in its classpath.
b) In log4j.properties, removed rootLogger reference.
c) Tried using an Log4jService in my SAR's jboss-service.xml, but I am not sure what the ConfigurationURL should be if my log4j.properties are in the EAR.

Thank you,
Niranjan

Hello!

I have one question/suggestion about log4j configuration.
I have posted a question in this forum about logging into different logfiles, but unfortunatly not received any answer.

I am deploying several instances of the same .ear file in within one JBoss. Of cource they are not exactly the same. I have changed the jndi names and so on.

I would like to be able to have the server.log and request.log in different files. One for each ear. It would be much easier to follow the traces then.

Is it possible today? If not will it be possible in the future?

/Erik

Did anybody get log4j working in JBoss 3.0.4 for a EJB application?

I never see any output on the console/in the logfile from my application, and i'm running out of ideas :-(

Bye,

Jürgen