Differences between revisions 6 and 7
Revision 6 as of 2013-03-06 18:58:48
Size: 2213
Editor: 137
Comment: Removed spam.
Revision 7 as of 2013-03-07 03:39:38
Size: 2387
Editor: 118
Deletions are marked like this. Additions are marked like this.
Line 30: Line 30:
[[http://vamostech.com/gps-tracking|GPS Tracker Mobil]] | [[http://vamostech.com/gps-tracking|GPS Tracking Kapal]] | [[http://vamostech.com/gps-tracking|GPS Tracker Orang]]

At present, to get a log4j logger you call a static method on the LoggerClass.

However, a J2eeComponent running inside a J2eeContainer really should be getting all of its services from JavaJndi, that is: any means by which it interacts with the outside world.

What log4j needs, then is a "resource archive" (.RAR) and some protocols.

So I suggest the following:

  • Components running inside a container should access log4j by asking JNDI for the name java:comp/log4j. They MUST NOT call the static methods on LoggerClass.

  • JNDI will return a factory object that acts like a J2EE connection pool or a java.sql.DataSource. You "ask" this object for a Logger.

  • The factory object will implement, say, LoggerSource. It will have methods getLogger(), getLogger(String), and getLogger(Class).

  • Loggers fetched from a LoggerSource MUST NOT be kept across TransactionBoundaries.

  • Components MUST NOT use addAppender, callAppenders, setLevel, setPriority etc. These methods MAY throw an UnsupportedOperationException

  • Component writers SHOULD copoerate with deployers to decide on contexts
  • Component writers SHOULD avoid the use of getLogger(Class). Instead, they should use a short context string on the understanding that it will function within a namespace provided by the LoggerSource

Now, at present we can write a connector that does nothing by call the existing Logger static methods. The important thing is to establish the use of LoggerSource and the JNDI name.

Once that is in place, then we can look at things like:

  • configurators that allow one to remap output on a bean by bean basis
  • configurators that redirect different EARs running in the same JVM to different places
  • vendor specific configurators that do hot redirecting of logger streams, that are operated by the various vendor consoles
  • Appenders and formatters that are aware of transactions
  • * that "untangle" lines coming from different transactions and group them together
  • * formatters that "tree structure" nested transactions
  • * and that mark subtransactions that are rolled back and comitted

In concert with this, accesses to the filesystem ought also be done by JNDI. GPS Tracker Mobil | GPS Tracking Kapal | GPS Tracker Orang

J2EE (last edited 2013-03-07 03:39:38 by 118)