Hi Erik,
Sorry to jump in a little late. I monitor this list on my home PC but I
travel during the week.
Erik van Zijst wrote:
>
> First is the reconfiguration thing as described below in the earlier mail.
>
That's a tough one. Log4j is certainly configurable at runtime. There
are two notions of runtime configuration. What others call runtime
log4j would call initialization time (via property files). The
configuration can also be changed later in runtime programatically. As
you're aware, it can only be done locally (within the same JVM).
I'm not familiar with having an EJB server call an EJB client in order
to change client attributes (whether it be logging or otherwise). I am
currently working on a reasonably sized CORBA (insurance claim
registration call center) that has recently gone in production. To
change client properties, we use the old-fashon approach of sending out
modified property files to the client machine and restarting. Most
enterprises are very good at distributed files out to client machines in
an automated manner. If a particular Customer Service Rep (CSR) called
in saying her machine was acting funny, we could either send her a
modified property file with configuration changes or have someone at the
CSR location (in a different timezone than some of the servers) do it
directly.
Remote configuration is something I'm very interested in and continue to
regularly think about. One direction with potential is providing JMX
implementations of certain log4j elements. But other than Sun's
reference implemenation and Tivoli's TMX (from IBM's alphaworks site),
we're somewhat short of an abundance of JMX agents to choose from.
> Second, since the JVM's of our remote clients will be sending us logs over
> RMI, I need the log messages to contain server (IP address) information.
You can use the example Category in
org.apache.log4j.examples.appserver. I'd like to make this part of the
main stream distribution (remove the "examples" from the package name).
But first I need to iron out some of the configuration difficulties it
has (as well as all other extensions like it).
> To forward log events over RMI, I wrote the client a RemoteAppender which has
> a reference to an EJB. This EJB exposes one method which takes the
> LoggingEvent. The EJB then passes the events (coming from multiple clients)
> to its Category instance with callAppenders().
The SocketLogger, together with SimpleSocketServer, should do what you
need without creating extra EJBs (the fewer, the better in large
environments). In our application we have SimpleSocketServers, we call
them Dispatchers, which receive messages from all the servers in a
certain class. So one for production servers, one for training, one for
QA and one for system testing. Each dispatcher serves CORBA servers
from various places in the country. The dispatcher in turn sends the
events to whoever needs them: various console machines. In the case of
the production dispatcher, it also sends events to a universal agent of
CA's Candle Command Center. The command center is monitored by the
operations staff.
The console machines and command center machines which listen to the
messages only need the following items installed:
1. a Java runtime environment
2. log4j.jar
3. a property file for configuration
Hope this helps,
- Paul
--
Beware of bugs in the above code. I have
only proved it correct, not tried it.
-Don Knuth
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
