logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <dan...@etrak-plus.com>
Subject Re: EJB and Log4J
Date Wed, 07 Jan 2004 18:11:11 GMT
Websphere commerce suite 4.5 (last time i worked with it) wrote log files
from ejb's also.
So you should be fine with Websphere app server.
----- Original Message ----- 
From: "Masár Daniel" <dmasar@gratex.com>
To: "Log4J Users List" <log4j-user@logging.apache.org>; "donald
larmee|ALTERthought" <dlarmee@alterthought.com>
Sent: Wednesday, January 07, 2004 1:01 PM
Subject: RE: EJB and Log4J


Our EJBs are hosted in IBM WebShere 5.02 app. server

-----Original Message-----
From: donald larmee|ALTERthought [mailto:dlarmee@alterthought.com]
Sent: Thursday, January 08, 2004 6:57 AM
To: log4j-user@logging.apache.org
Subject: Re: EJB and Log4J

As Michael indicated, it is generally an accepted practise to ignore this
aspect of the J2EE spec (for example, jboss usese log4j and regularly writes
flat log files...)


However, it is usually fairly trivial to write a simple appender that wraps
the containers 'native' logger... similiar to the ServletContextLogAppender.

What Container are you running in?  I have written one for WebLogic (in fact
I believe that a variant of it may have been donated back to the project by
Andreas Bothner) and can send it to you if you are interested....

-don


On Wed, 7 Jan 2004 17:36:32 +0100 log4j-user@logging.apache.org wrote:
> Hmm, so I can not corrupt container or some resources, or ...  when I
> ignore spec?
>
> -----Original Message-----
> From: Lutz Michael [mailto:michael.h.lutz@siemens.com]
> Sent: Wednesday, January 07, 2004 5:27 PM
> To: 'Log4J Users List'
> Subject: RE: EJB and Log4J
>
>
>
> To answer your question directly, my understanding is that although
> the spec says not to do this it's often done anyway.  (the same goes
> for calling native code from within a container).
>
> So, some people may not particularly recommend this approach, but it
> will probably work for any container.
>
> (I'm not an expert on this topic, hopefully others will chime in)
>
>
> -----Original Message-----
> From: Masár Daniel [mailto:dmasar@gratex.com]
> Sent: Wednesday, January 07, 2004 11:09 AM
> To: Log4J Users List
> Subject: RE: EJB and Log4J
>
>
> I have done logging solution I developed for win32 services.
> If there is possibility to port it to Java/EJB it is simplest for me.
>
> This solution is file based and Key point of this solution was to
> don't serialize client calls during log write operation.
>
> HTTP/Socket Appneder - maybe I need dedicated server ... security ...
> SPOF ... how to implement it - not EJB because of i/o restriction ....
>
> JMS Appender - have to study
> JDBC - I can access only DB2 and DB2 places tablock on insert...
>
> So can I use FileAppender on EJB?
>
> Thanks
>
> Daniel Masar
>
> -----Original Message-----
> From: Lutz Michael [mailto:michael.h.lutz@siemens.com]
>
> Sent: Wednesday, January 07, 2004 4:35 PM
> To: 'Log4J Users List'
> Subject: RE: EJB and Log4J
>
>
>
> One idea - there are myriad other appenders that don't write to flat
> files you may want to consider.
> For instance: JMS Appender and Socket Appender.  There is also a JDBC
> appender, although there has been talk of it being rewritten.
>
> Mike
>
> -----Original Message-----
> From: Masár Daniel [mailto:dmasar@gratex.com]
> Sent: Wednesday, January 07, 2004 9:20 AM
> To: log4j-user@logging.apache.org
> Subject: EJB and Log4J
>
>
> Hi,
>
> I am new in Java and EJB world and I have to create logging
> infrastructure component for EJB application.
>
> I am inspecting wheter log4j can meet my requirements.
>
> When I use log4j and FileAppender form enterprise bean am I in
> collision with following ?:
>
>
> The EJB 1.1 Specification, section 18.1.2 (Programming Restrictions)
> states the following:
>
> An enterprise bean must not use the java.io package to attempt to
> access files and directories in the file system.
>
> The file system APIs are not well-suited for business components to
> access data. Business components should use a resource manager API,
> such as JDBC API, to store data.
>
>
> Thanks
>
> Daniel Masar
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
> ----------------------------------------------------------------------
> ---
> ---
> ---
> This message and any included attachments are from Siemens Medical
> Solutions
>
> USA, Inc. and are intended only for the addressee(s).
>
>
> The information contained herein may include trade secrets or
> privileged or
>
> otherwise confidential information.  Unauthorized review, forwarding,
> printing,
>
> copying, distributing, or using such information is strictly
> prohibited and may
>
> be unlawful.  If you received this message in error, or have reason to
> believe
>
> you are not authorized to receive it, please promptly delete this
> message and
>
> notify the sender by e-mail with a copy to CSOffice@smed.com.  Thank
> you
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
> ----------------------------------------------------------------------
> ---
> ------
> This message and any included attachments are from Siemens Medical
> Solutions
>
> USA, Inc. and are intended only for the addressee(s).
>
> The information contained herein may include trade secrets or
> privileged or
>
> otherwise confidential information.  Unauthorized review, forwarding,
> printing,
>
> copying, distributing, or using such information is strictly
> prohibited and may
>
> be unlawful.  If you received this message in error, or have reason to
> believe
>
> you are not authorized to receive it, please promptly delete this
> message and
>
> notify the sender by e-mail with a copy to CSOffice@smed.com.  Thank
> you
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.559 / Virus Database: 351 - Release Date: 1/7/2004


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message