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]>
