In addition, the EJB spec-writers don't want you doing anything transactional outside the scope of the app-server's control. And a user who talks directly to sockets (say via a SocketAppender) or writes directly to the filesystem (say via some FileAppender) could be doing something transactional which the app-server would not be automatically commit or rollback. Thus sockets and filesystem access, among other things, are disavowed by the spec-writers. But generally logging is not transactional from the app-server's point of view. You wouldn't want to rollback your log-file if your transaction fails -- in fact, quite the opposite, you'd like your logs to help you diagnose where and why your transaction failed. As such, although logging to a file or to a SocketAppender may be a violation of the letter of the spec, but I don't see it as a violation of the spirit of the spec. And, like several other posters, I haven't seen or heard of a single app-server that's bothered by you logging to a file or a socket. FYI my experience is primarily with WebLogic, JBoss, and JRun. Note that if you have multiple app-servers running (e.g. load-balancing) on multiple machines, then you probably want to write to a centralized log server via a SocketAppender rather than each server on each machine writing to a log-file on its filesystem.
--Ian Haggard --- Paul Smith <[EMAIL PROTECTED]> wrote: > On Thu, 2004-01-08 at 03:59, [EMAIL PROTECTED] wrote: > > 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. > > I agree, and given that the choice of appender is done at runtime (or > at > configuration/deployment time), you can safely choose any appender > you > want that suits the particular environment the bean is running > within. > > cheers, > > Paul Smith > > > --------------------------------------------------------------------- > 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]
