A problem using log4j in an Enterprise JavaBean

[John Collier <jc...@leadscope.com>]

I am having a problem using log4j inside of an EJB; I can only
log to a file on the first call to the EJB.  Subsequent attempts
to log from other methods in the EJB fail due to an IOException
on the call to flush() the log output.

The environment is as follows.  We are developing an Oracle-based
client-server application using Oracle 8i and their JDeveloper 3.2
development environment.  This also comes with its own JVM (Aurora).
We have upgraded this environment to use JDK 1.3.  Oracle and our
server application both run on Solaris.  The client (and JDeveloper
3.2) executes on a PC running Windows 2000.  I think that is all
the pertinent system information.  

As far as log4j is concerned, we have a thin wrapper class of our 
own that we use for logging.  All of this wrapper class's methods
are static and basically format messages the way want them formatted
and then call log4j methods.  We configure our logging environment
via an XML file using the DOMConfigurator class.  We use a standard
FileAppender object with fairly standard formatting.  In addition
to logging to a file, we also log to "Standard out" via a second
FileAppender.

The behavior I am seeing is as follows.  We create a session EJB.
Inside of the "ejbCreate()" method (a standard method on the EJB
interface, at least I think--I'm still kind of new to this...),
I have placed several logging messages.  All of the logging messages
inside "ejbCreate()" work just fine.  After "ejbCreate()" returns, 
we call another method on the EJB.  Let's call it "methodA()".  
Inside of "methodA()", we attempt to log to the same file that we
logged to back inside of "ejbCreate()".  If fact, we are using the
same objects we used earlier.  However, this time we fail due to
an IOException when attempting to flush() the output (basically, this
operation gets done by the FileWriter.flush() method which simply
calls "flush()" on its associated output stream object).  Because
of this failure, no log output from "methodA()" is ever recorded
in the log file.  However, this output is written to "Standard
out".

The IOException I am getting originates from native code and doesn't
seem to tell me exactly what the problem is.  My suspicion is that
the file descriptor was closed somehow, but thus far I am unable
to prove this (and am not sure what I would do about it if I did
prove this theory).  I modified a local copy of the log4j code to
tell me if any "close()" method was being called, but--at least as
far as I can tell--neither log4j, our Log wrapper class, nor our
EJB code is intentially closing any file object.  This may be some
"side effect" of using EJBs (or, particularly, session EJBs); I'm
not yet knowledgeable enough in this area to know for sure and none
of the document that I have access to indicates that this is standard
behavior for EJBs.

As a work-around, we can configure our XML file to send all of our
log4j output to "Standard out", which means it will wind up in some
Oracle trace file and be a tad bit difficult to locate, but we can
live with that for now.  However, in the long run, we would really
like our log output to wind up in a seperate data file like it does
everywhere else we've been using it (log4j and our Log wrapper work
fine everywhere else in our system).

Any thoughts, comments, suggestions, or answers would be greatly
appreciated.


 

Re: A problem using log4j in an Enterprise JavaBean

[Ceki Gülcü <cg...@qos.ch>]

Jon,

If I recall correctly, the Oracle JVM closes files after each flush operation. I suggest that you use the SocketAppender/SocketServer combination assuming that sockets is not an issue... Cheers, Ceki

At 10:35 22.02.2001 -0500, John Collier wrote:
>I am having a problem using log4j inside of an EJB; I can only
>log to a file on the first call to the EJB.  Subsequent attempts
>to log from other methods in the EJB fail due to an IOException
>on the call to flush() the log output.
>
>The environment is as follows.  We are developing an Oracle-based
>client-server application using Oracle 8i and their JDeveloper 3.2
>development environment.  This also comes with its own JVM (Aurora).
>We have upgraded this environment to use JDK 1.3.  Oracle and our
>server application both run on Solaris.  The client (and JDeveloper
>3.2) executes on a PC running Windows 2000.  I think that is all
>the pertinent system information.  
>
>As far as log4j is concerned, we have a thin wrapper class of our 
>own that we use for logging.  All of this wrapper class's methods
>are static and basically format messages the way want them formatted
>and then call log4j methods.  We configure our logging environment
>via an XML file using the DOMConfigurator class.  We use a standard
>FileAppender object with fairly standard formatting.  In addition
>to logging to a file, we also log to "Standard out" via a second
>FileAppender.
>
>The behavior I am seeing is as follows.  We create a session EJB.
>Inside of the "ejbCreate()" method (a standard method on the EJB
>interface, at least I think--I'm still kind of new to this...),
>I have placed several logging messages.  All of the logging messages
>inside "ejbCreate()" work just fine.  After "ejbCreate()" returns, 
>we call another method on the EJB.  Let's call it "methodA()".  
>Inside of "methodA()", we attempt to log to the same file that we
>logged to back inside of "ejbCreate()".  If fact, we are using the
>same objects we used earlier.  However, this time we fail due to
>an IOException when attempting to flush() the output (basically, this
>operation gets done by the FileWriter.flush() method which simply
>calls "flush()" on its associated output stream object).  Because
>of this failure, no log output from "methodA()" is ever recorded
>in the log file.  However, this output is written to "Standard
>out".
>
>The IOException I am getting originates from native code and doesn't
>seem to tell me exactly what the problem is.  My suspicion is that
>the file descriptor was closed somehow, but thus far I am unable
>to prove this (and am not sure what I would do about it if I did
>prove this theory).  I modified a local copy of the log4j code to
>tell me if any "close()" method was being called, but--at least as
>far as I can tell--neither log4j, our Log wrapper class, nor our
>EJB code is intentially closing any file object.  This may be some
>"side effect" of using EJBs (or, particularly, session EJBs); I'm
>not yet knowledgeable enough in this area to know for sure and none
>of the document that I have access to indicates that this is standard
>behavior for EJBs.
>
>As a work-around, we can configure our XML file to send all of our
>log4j output to "Standard out", which means it will wind up in some
>Oracle trace file and be a tad bit difficult to locate, but we can
>live with that for now.  However, in the long run, we would really
>like our log output to wind up in a seperate data file like it does
>everywhere else we've been using it (log4j and our Log wrapper work
>fine everywhere else in our system).
>
>Any thoughts, comments, suggestions, or answers would be greatly
>appreciated.
>
>
> 
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org

----
Ceki Gülcü          Web:   http://qos.ch      
av. de Rumine 5     email: cgu@qos.ch (preferred)
CH-1005 Lausanne           ceki_gulcu@yahoo.com
Switzerland         Tel: ++41 21 351 23 15