Donnie,
I'm in a situation where I really need to be able to modify the
log4j.properties file after the application is deployed, which means
that the file must be outside of the .ear file. We're using the
conifgureAndWatch() call to set this up and naming it something unique
such as
If that's a fundamental requirement, then that seems like a reasonable approach. J2EE
really seems to be focused on fully-packaged deployments with no reliance at the app
level on the file system itself. Of course, you can only take that so far since the
configuration for a log file will need
DONNIE HALE wrote:
[snip]
Our approach was likely to be an admin EJB which we'd call to accomplish what
you're using configureAndWatch for. The advantage of your approach is simplicity.
The advantage of ours is portability across both containers and logging packages.
Interesting thought,
I'm jumping in on the middle of a thread so excuse me if I'm missing something.
I'd think the most EJB styled approach would be to put everything in the DB, logs
and configuration. The JDBCAppenders in contribs work well for logging. You'd need a
special configureAndWatch to handle pulling
We don't do any programmatic startup stuff. It's all in our log4j.properties file.
We do use NDCs. So we have a servlet filter which sets the NDC to a value prefixed
with JSP when the app is in the web app space, and a dynamic proxy which sets the
NDC to a value prefixed with EJB when the app
Hi,
We are also using the same architecture.But I have the following questions
1) What if log4j.properties exists in the classpath ?Will log4j use the file inside
the EAR or the one in the classpath.How to resolve this ?
2)Our Directory structure is
src
|
EJB-MODULES
