It's a design issue - EJB components are intended to represent business objects or processes, and writing to the file system (directly) shouldn't be their responsibility, in theory. However, in practice, logging is a common concern of code in general so it's common practice to write to logs from EJBs.
Furthermore, I believe the intent of that part of the spec is to partially maximize portability of your EJBs. Theoretically, your beans should be able to run in a container that doesn't have access to the filesystem (or perhaps is running on a system without a real filesystem). However, in practice this is rarely the case. It shouldn't cause any problems, but use your best judgment. Ken > -----Original Message----- > From: Mas�r Daniel [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 07, 2004 11:37 AM > To: Log4J Users List > Subject: RE: EJB and Log4J > > > Hmm, so I can not corrupt container or some resources, or ... > when I ignore spec? > > -----Original Message----- > From: Lutz Michael [mailto:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > 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:[EMAIL PROTECTED] > Sent: Wednesday, January 07, 2004 9:20 AM > To: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -------------------------------------------------------------- > -------------- > --- > 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 [EMAIL PROTECTED] > Thank you > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -------------------------------------------------------------- > ----------------- > 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 [EMAIL PROTECTED] > Thank you > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
