Quoting Mas�r Daniel <[EMAIL PROTECTED]>: > Thanks, > > This solution uses HTTP protocol to comunicate with servlet? >
no, this just delegates the log4j message to the context.log() method in the servlet api which ends up going to wherever the server is configured to store the log message. Nothing to do with HTTP communication. > Application services are available as web service so there is no GUI. But on > other side there are also remote GUI servers who calls web services methods. > If it is a web service, then you must have a webapp running. Whether you there is a GUI involved is irrelevant. When the webapp starts, all the logging stuff will be set up. I assume that the EJB stuff can get its logging setup info from that set up in the webapp. Is there another standard startup classes similar to servlet context listeners, but for EJB specifically? Not really sure about that. Does the EJB api provide a standard log() method like the servlet api does? How is that implemented? Maybe someone can verify how this works. Sorry to be of so little help with EJB specifics. Jake > Daniel Masar > > -----Original Message----- > From: Jacob Kjome [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 07, 2004 5:14 PM > To: Log4J Users List > Subject: RE: EJB and Log4J > > Another solution to this is using the log4j-sandbox > ServletContextLogAppenderListener which allows one to use the server's own > File (or other) logging, but your app still uses Log4j generically. it works > like this... > > Add the following to log4j.xml... > > <appender > name="ServletContext" > class="org.apache.log4j.servlet.ServletContextLogAppender"> > <param name="servletContextPath" value="/mycontext" /> > <layout class="org.apache.log4j.PatternLayout"> > <param name="ConversionPattern" value="[%-5p][%-8.8t]: %39.39c{3} > - %m"/> > </layout> > </appender> > > Add the following to web.xml... > > <listener> > <listener-class> > org.apache.log4j.servlet.ServletContextLogAppenderListener > </listener-class> > </listener> > > And, using Tomcat as an example, add the following to your <Context> > configuration file (or element in server.xml)... > > <Context path="/mycontext" docBase="mycontext"> > <Logger > className="org.apache.catalina.logger.FileLogger" > prefix="localhost_mycontext_servlet_log." > suffix=".txt" > timestamp="true" /> > </Context> > > > So, a logging statement such as logger.debug("a debugging statement") will > end up in CATALINA_HOME/logs/localhost_mycontext_servlet_log.2004-01-07.txt > (since Tomcat rolls its logs daily by default). > > So, now you have your logs going to file, but you aren't violating the J2EE > spec at all, since it is perfectly fine for the server itself to access the > file system, just not individual application running under the server. > > Of course, if your app doesn't have a web front end, I'm not entirely sure > how this would work? I really haven't done that much EJB work anyway. How > would one mirror this functionality with logging from within an EJB? I'm > sure there is a solution, but I don't have the answer to it at this time. > > Jake > > Quoting Lutz Michael <[EMAIL PROTECTED]>: > > > > > > > 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] > > > > > --------------------------------------------------------------------- > 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]
