Also consider, albeit poor practice, how much working EJB code you've seen that uses System.out and/or System.err. Clearly, these are (and must be) java.io.PrintStream instances. Furthermore, all implementations I've seen of PrintStream are internally synchronized to prevent output from multiple callers becoming commingled. IBM's WebSphere Best Practices document even cites this synchronization (and the resultant performance decrease) as a reason for avoiding the use of System.out. However, their balanced (italics mine :-) view is to "Avoid indiscriminate System.out.println statements".
The EJB spec section (23.1.2 in the EJB 2.0 Spec) states that the intent of the specification is to describe "the programming restrictions that a Bean Provider must follow to ensure that the enterprise bean is portable and can be deployed in any compliant EJB 2.0 Container." Thus, primarily portability -- not functional or operational concerns -- would seem to be at the heart of these restrictions. Restrictions which extend to the dependent classes used by an entity bean with CMP. The specific restriction on java.io is "An enterprise bean must not use the java.io package to attempt to access files and directories in the file system." The important bit for designers is the why: "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, to store data." File system characteristics vary widely between deployment environments and so effect the portability of a dependent application. File systems are not transactional so "data" stored to a file system cannot carry transactional guarantees. But are logs "data"? I mean, in the same way that user registration information is "data"? Or that your product catalog is "data"? Or that orders sent to a back-end fulfillment system are "data"? If you think yes, then definitely avoid using files for logs. If you think no, and portability is not an outstanding concern, then why not? Consider again thread synchronization. The restriction is: "An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances. This rule is required to ensure consistent runtime semantics because while some EJB Containers may use a single JVM to execute all enterprise bean's instances, others may distribute the instances across multiple JVMs. Synchronization would not work if the EJB Container distributed enterprise bean's instances across multiple JVMs." So thread synchronization isn't inherently a "bad thing". The reason has to do with sequencing the activities of bean instances across multiple JVMs. But that isn't what we are doing here. We want to limit the access to a particular shared resource within a single JVM. That resource is not transactional so it presents no deadlock issues. In this case, as in the case with java.io.PrintStream (aka System.out), there may be performance or scalability issues to consider (like there aren't with JDBC or JMS?) but not functional issues -- and I mean the application fails to function correctly when moved to a new environment. Certainly, adhering to the spirit of the restrictions set out in the EJB specification is beneficial and a recommended practice. However, intelligent application of each restriction requires understanding the intent behind it and the possible impact of violating it. Best regards, Jim Cakalic > -----Original Message----- > From: Steve Ebersole [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 29, 2002 7:50 PM > To: Log4J Users List > Subject: Re: Using Log4J in EJB server > > > Not to bemuse this point, but that is just not a complete > truth (as is true > for most generalizations). I'll give you two prime examples > (though there > are others) where not only is the use of classes from the > java.io package > used extensively in J2EE environments, but in fact validated > directly by Sun > in its tutorials and J2EE patterns: > > 1) A combination of java.io.StringWriter and > java.io.PrintWriter as a means > of maintaining stack trace information in inter-tier Exception classes > 2) A combination of > java.io.ByteArrayOutputStream/java.io.ObjectOutputStream > and java.io.ByteArrayInputStream/java.io.ObjectInputStream as > a quick way to > perform deep copies of server objects for serialization. > > And lets not even get into java.io.Serializable/Externalizable > > Is it a good idea to perform direct file IO from within a > J2EE app at all? > Generally no. However, the reason is usually not for the > first one you > mentioned; rather the fact that you would need to know > something of the > file-system layout in order to perform direct file IO is usually the > greatest concern. Although for me the new JMX implmentation > for log4j would > help alleviate that issue. And yes of course file IO has the > potential to > be a bottle neck (and you think database access won't). > > And FYI, the same holds true for thread synchronization. I > use TopLink > within J2EE containers. And while I haven't seen their > source cde, I'd be > more than willing to bet you that they are using thread > synchronization > internally? If so, would that mean that I am violating the > J2EE specs by > using TopLink from within my EJBs? > > > > ----- Original Message ----- > From: "Bellamy, Scot" <[EMAIL PROTECTED]> > To: "Log4J Users List" <[EMAIL PROTECTED]> > Sent: Wednesday, May 29, 2002 11:12 AM > Subject: RE: Using Log4J in EJB server > > > Whether the code is directly in the bean or is in another > class used by > the bean, the problem is the same. The problem is that there will > likely be multiple instances of the bean instantiated at the > same time. > This will cause a threading problem when attempting direct > file io. The > same section of the EJB spec (EJB.18.1.2) that prohibits use of the io > package, also prohibits explicit thread synchronization. > > The other problem is that direct file io will be a bottle-neck to your > system, preventing your system from scaling as usage increases. > > Scot. > > Scot Bellamy > Infrastructure & Architecture > eBusiness Technology > Cardinal Health, Inc. > > > -----Original Message----- > From: Steve Ebersole [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 27, 2002 11:31 AM > To: Log4J Users List > Subject: Re: Using Log4J in EJB server > > > The direct use of the java.io package is forbidden by the EJB spec. > That does not mean that your EJBs cannot use > classes/libraries which use > the java.io package. I use log4j in a J2EE environment with > no problems > (although i log to a JMS queue from within the app components). > > > ----- Original Message ----- > From: "Chris Naude" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, May 27, 2002 10:26 AM > Subject: Using Log4J in EJB server > > > > > > Hi > > > > I have been looking at the log4j archives regarding the use of log4j > inside an EJB. I am not quite sure what all the discussion is > about (as > usage of the java.io package is forbidden in the spec). > However, I have > the ff line in each of my EJB's: > > > > private static final Logger L = > Logger.getLogger(SomeEJBClass.class); > > > > The EJB server I am using (Borland Enterprise Server V5.0) does not > complain about anything in this regard. > > > > Can someone tell me if there are any hidden problems with this > > approach - > we have just started our project and I don't want to get any surprises > later on. > > > > Thanks in advance. > > > > Chris > > > > > > > > > > > > > > > > I > > > > > > > > --------------------------------- > > Sign up to watch the FIFA World Cup video highlights from your desk! > > > > http://fifaworldcup.yahoo.com/fc/en > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > -------------------------------------------------------------- > -------------- > ---- > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > <font size="1">Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
