Discussions

EJB design: Logging Mechanism for EJBs...

Bookmark and Share Get thread feed

  1. Logging Mechanism for EJBs... (101 messages)

    • Posted by: Ash Parikh
    • Posted on: November 21 2000 15:06 EST
    Hi,
    Does anyone have any sample code to log messages to a file from an EJB event, such that the log file contains the name of the class, the warning level and warning name, and the exact error message?

    As per the EJB 2.0 Spec (Public Draft), an EJB must not use the java.io package to attempt to access files and directories in a file system.

    I am thinking of using the JAXP API provided by Sun to write logs to an xml file and then parse and retrieve information.

    Any sample code available?

    Thanks.

    Ash
    Reply to this

    Threaded Messages (101)

  2. Logging Mechanism for EJBs...[ Go to top ]

    We use log4j (www.log4j.org) for application logging without any problem -- despite the EJB specification. That section of the spec describes limitations which are supposed to ensure that your EJB is portable. As long as you take precautions like use file.separator and don't make any platform-specific assumptions about your file system you should be fine. You may have to update the security policy of your EJB container to allow the use of java.io. We use Weblogic and this works fine.

    You should *not* use the file system for persistence of business entities. If you do then the container will not be able to control your persistence operations within the scope of a transaction.

    Such a sweeping limitation (no use of java.io, period) is going a little overboard, in my opinion. Using JDBC for an application log is a little absurd for most production environments.


    Reply to this Reply to original

  3. Logging Mechanism for EJBs...[ Go to top ]

    Hi,
    I have tested the "log4j" application and it seems like it is a bit too complex for simple purposes of basic logging. I noticed that it uses an heirarchial Category model and then the Appender class by which one can specify what type of format the log should be written in.

    Is there a way to get all the functionality provided by "log4j" otherwise? How have you used "log4j"? Have you made some modifications?

    Thanks.

    A
    Reply to this Reply to original

  4. Logging Mechanism for EJBs...[ Go to top ]

    Your requirements for "Basic logging" will not remain basic for very long. Simply wrap a facade class around log4j to expose a simpler interface to your application. You can always expose more functionality if your app needs it.

    Regarding categories, we just use the fully qualified class name of the instance which writes to the log. We have a facade pattern that uses a singleton Log instance internally. The facade exposes a number of static methods to write out various types of log messages: debug, info, warn, error, emerg. The methods are overloaded to take an optional Throwable instance as an argument in addition to a simple String message.

    Reply to this Reply to original

  5. Logging Mechanism for EJBs...[ Go to top ]

    I understand that using JDBC for this purpose might not make sense in most cases but I am not so sure if we could ignore the EJB spec about not using IO in EJB app's...

    What I am not sure is if you are logging messages into physical files how would the container handle the situation if it distributed the bean's instances accross multiple JVMs?

    Probably I am missing something or I am wrong but I would really appreciate your input on this..

    Thanks,

    Kiran
    Reply to this Reply to original

  6. Logging Mechanism for EJBs...[ Go to top ]

    Presently I am writing the logs to an XML file using the JAXP API provided by Sun. An EJB or a set of EJBs will be the callers for this logging mechanism, which will then write to the XML-based log file. The logging mechanism will be re-written as an EJB itself.

    Hope this answers your question.

    Ash
    Reply to this Reply to original

  7. Logging Mechanism for EJBs...[ Go to top ]

    Presently I am writing the logs to an XML file <

    What resource is used to persist your XML document? File system? Database? Something else?

    We use XML for data interchange but an XML document can be stored in any number of ways. Using XML doesn't directly address the issue of using java.io within EJBs.

    Reply to this Reply to original

  8. Logging Mechanism for EJBs...[ Go to top ]

    Hi,
    What is the point in writing messages to an XML file instead of writing directly to an ordinary file?

    Adnan
    Reply to this Reply to original

  9. Logging Mechanism for EJBs...[ Go to top ]

    Haii Ash,

    U r concept is correct. I have the same concept. All the best.

    Mail me : kgjawahar@yahoo.com
    Reply to this Reply to original

  10. Logging Mechanism for EJBs...[ Go to top ]

    Ashish,
    I am working on a similar project, writing to an XML-based log file. The log entries consist of individual nodes, which need to be placed in a specific part of the tree. Using DOM, I reference the log file as a Document, check to see if the needed elements exist, and append the log entry as a child node in the correct part of the tree. I then serialize the Document back to file.

    The issue I am trying to solve now involves performance. Some of the log files can become extremely large. If I have to serialize the Document every time I add a log entry, and the file is 50 MB ... well, you know how bad that would hurt performance on the server.

    I've done a lot of research, but haven't found a way to insert the node in the correct place without fully serializing the entire file. Any suggestions?

    Thanks.
    Reply to this Reply to original

  11. Logging Mechanism for EJBs...[ Go to top ]

    <p>
    It is possible to use log4j without having to access the filesystem directly from the VM the app. server is running in.<br>
    By using the org.log4j.net.SocketServer & SocketAppender you can send your logging requests over the network.
    </p>
    <p>
    I have not tried to do this myself yet, but I have to do this soon. Anyone who have tried this?
    </p>

    Reply to this Reply to original

  12. Logging Mechanism for EJBs...[ Go to top ]

    Check out JLog Toolkit from IBM Alphaworks
    http://alphaworks.ibm.com [search for JLog]
    It enables you to write logs thro a TCP socket stream..

    Reply to this Reply to original

  13. Logging Mechanism for EJBs...[ Go to top ]

    I have made a Logging tool which can log in a File (allways open or closed on every logging), TCP, UDP or to an URL.
    The tool is logging activity in an EJBServer with lots of EntityBeans and SessionBeans. It logs time, threadId, Class.method, Userdefined info, userId and optional stackTrace.

    With full trace on it eats almost 35-50% of the performance, which isn't abnormal, but notice that the fastes way of logging is to write to an open file.
    The next "slowest" is to close the File on every logEvent. On third place comes TCP and the slowest is UDP!

    So my advice is to write to an open File (XML or what ever format needed).
    Reply to this Reply to original

  14. Logging Mechanism for EJBs...[ Go to top ]

    JMS is an the perfect answer to logging, providing asynchronous messaging capabilities. Just send your log message on a queue and that's it. On the other end of the queue you can have low priority listeners handling the log messages. These listeners can write to any destination (database, file, screen etc) in any format (XML, plain text, CSV etc) you like. Using MessageDrivenBeans (EJB2.0) as queue listeners really makes this architecture elegant.
    Reply to this Reply to original

  15. Logging Mechanism for EJBs...[ Go to top ]

    Great idea! Is there any limitation in doing this?(concerning the ejb spec)
    Reply to this Reply to original

  16. Logging Mechanism for EJBs...[ Go to top ]

    Never mind the above question. There is a whole thread
    discussing this same issue :)
    Reply to this Reply to original

  17. Logging Mechanism for EJBs...[ Go to top ]

    I am looking for the discussion thread which discusses about JMS and logging. If anybody has a link to that please reply to this message.
    Reply to this Reply to original

  18. Logging Mechanism for EJBs...[ Go to top ]

    Hi all,
    When I started this thread, the concept of Message Driven Beans was not completely clear in the industry. It seems like a likely solution that if I use Message Driven Beans as a logging mechanism, not only will I be able to send messages to the EJB, but also have the EJB send out messages, and thus log the output from the EJB. This is the fine-grained control that I was looking for. But there is also the asynchronousity of the concept that one needs to remember, especially if you are using this paradigm for logging level 1 (extremely serious) logs, and they arrive asynchronously into the log.

    Ash
    Reply to this Reply to original

  19. Distributed logging is bad, bad, bad![ Go to top ]

    I know the concept of distributed logging and/or a central "logging service" is all the rage these days. But I've experienced such a system in production, and all I can tell you is that it's not a good idea.

    First and foremost, when logging at high levels from lots of services and/or lots of hosts, you'll just kill your network bandwidth. This is based on real, personal, first-hand experience where 70+% of our bandwidth was being consumed by logging activity.

    Second, it's difficult enough trying to wade through the log entries for a single process in its own file / source, let along if multiple processes go to the same file / source.

    IMHO, the correct solution is in-process logging (a la log4j - a godsend) to a file for that particular process. For collation, etc., post-process these files with tools/scripts. Interestingly, that's pretty much the way logging works for most of the web server world.

    FWIW...

    Donnie
    Reply to this Reply to original

  20. Distributed logging is bad, bad, bad![ Go to top ]

    Hi,
    I agree with you that an in-process logging mechanism is the way to go, which is why I proposed that sending the log messages to an XML file would be ideal.

    J2EE gives the developer the flexibility and the range of technologies to glue together a scalable solution for mechanisms such as caching, logging etc., By this I mean that we can easily take advantage of technologies such as JMS, Message-driven EJBs, Java Cryptography Edition, serialization and the up-and-coming Java XML APIs such as JAXM, JAXR, JAXP and JAX-RPC. It is encouraging to see how tightly all these concepts come together when you use a single paradigm such as J2EE.

    Performace v/s convenience and RAD is always something to consider...

    Ash
    Reply to this Reply to original

  21. Logging Mechanism for EJBs...[ Go to top ]

    Very true....

    Finally, I implemented JMS logging facility for our app and seems to be working great....We did not need any configuration properties, did not need to access the file system, do have asynchronous messaging, could easily support logging for multiple clients on the same app server instance...Most of all it does not violate the spec without loosing any capabilities..since this seems to be the main concern with any logging facility in EJB apps....

    Thanks to all...

    Kiran.
    Reply to this Reply to original

  22. Logging Mechanism for EJBs...[ Go to top ]

    Hi!!

      I am new to EJB, but i really liked the JMS logging
      functionality. Can anyone point me to some code
      that I can look at to do the same.

    Thanks
    Anjali Gupta
    Reply to this Reply to original

  23. Logging Mechanism for EJBs...[ Go to top ]

    jLog has this logging capacity, you should be able to get their source code....

    http://www.javalogging.com/
    Reply to this Reply to original

  24. Logging Mechanism for EJBs...[ Go to top ]

    Thanks Kiran!!
    Reply to this Reply to original

  25. Logging Mechanism for EJBs...[ Go to top ]

    Hi Kiran,

       I read your message and downloaded Jlog from the site. But it seems there are quite a few classes to take care of. If I wish to use JMS to log messages, could you give me a starter please.

    thanks,
    Reply to this Reply to original

  26. Logging Mechanism for EJBs...[ Go to top ]

    Hi Kiran,

       I read your message and downloaded Jlog from the site. But it seems there are quite a few classes to take care of. If I wish to use JMS to log messages, could you give me a starter please.

    thanks,
    Reply to this Reply to original

  27. Logging Mechanism for EJBs...[ Go to top ]

    Hi Kiran,

    Can you please provide me with some starter information using JMS for logging?

    Thanks

    Hara
    Reply to this Reply to original

  28. Logging Mechanism for EJBs...[ Go to top ]

    Kiran,

    Would you like to share your implementation detail using JMS for logging?

    Regards,
    -ramanand
    Reply to this Reply to original

  29. requirement[ Go to top ]

    we like to have JMS APPENDER properties so please send the jms properties to my mail id ch_ramgopal at yahoo dot co.in
    Reply to this Reply to original

  30. Logging Mechanism for EJBs...[ Go to top ]

    I'm using the same architecture for logging. Since I'm new to EJB. What should I do to enforce concurrent logging when the EJB has more than one instance? Should I made the destination to be a static variable or a singleton object? Or other way? I'm really interested in What your logging work in the server site.

    I really appreciate your help.

    Carey
    Reply to this Reply to original

  31. Logging Mechanism for EJBs...[ Go to top ]

    Hi,
    I did research using JNS for logging, but as far as I understood the concept, there is no way to make sure that the log has been written. All that happens is that a log is submitted to a queue. After this, it is not certain when it will be serviced. Correct?

    Thanks.

    A
    Reply to this Reply to original

  32. Logging Mechanism for EJBs...[ Go to top ]

    look at persistent JMS. It ensures that the message is written at least once to the file of db being used.

    manish.
    Reply to this Reply to original

  33. Logging Mechanism for EJBs...[ Go to top ]

    I've been using my own JMS logging tool in WebLogic for quite a while and it works well except for the following problems.

    1. JMS when called from an EJB picks up the current transaction from the EJB. If the ejb encounters an error and rolls back, so do all the log msgs. My workaround for this is to suspend and resume the trx around the call to the jms session.

    2. I find publishing a JMS msg to be really slow. It is the single slowest thing the logger does. The "publish" call is not asynchronous so it slows down the processing of the whole system. Writing directly to a file is about 3x faster although it is not asynchronous.

    Any thoughts on these issues and possible solutions?

    Thanks, Jon Wynett
    Reply to this Reply to original

  34. Logging Mechanism for EJBs...[ Go to top ]

    Atlast there is access to the logging API's from Sun/JavaSoft themselves. This should be a shot in the arm while developing applications that need simple or complex logging functionality.

    http://java.sun.com/j2se/1.4/docs/guide/util/logging/overview.html

    Reply to this Reply to original

  35. Logging Mechanism for EJBs...[ Go to top ]

    In response to the Sun logging APIs being a "shot in the arm", that can only be asserted in the context of anyone currently able to use JDK 1.4.

    The Java Logging API (aka JSR47) requires JDK 1.4. Efforts to backport JSR47 to earlier JDKs are doomed to fail because the java.util.logging package is located under the java namespace. This will cause backported code to systematically throw a SecurityException under JDK 1.3.

    Secondarily, if you are developing in anything other than a "stand-alone" application environment, how long will it be before your container vendor gets around to integrating JDK 1.4? By way of measurement, how long did it take many container vendors to migrate from JDK 1.1.x to JDK 1.2? And then to 1.3? In many cases, it will be months after the GA release of JDK 1.4 by Sun before J2EE developers will see the benefit.

    As for any remaining differences between log4j and the JSR47 implementation, I recommend you consult http://jakarta.apache.org/log4j/docs/critique2.html.

    Best regards,
    Jim Cakalic
    Reply to this Reply to original

  36. Logging Mechanism for EJBs...[ Go to top ]

    [JMS logging: JMS when called from an EJB picks up the current transaction from the EJB.]
    how about wrapping that call into a method (e.g. a singleton)? Would that work?

    ["publish" is about 3x slower than writing to a file]
    Would it be ok to use an asynchronous producer/consumer queue (see http://www.javaworld.com/javaworld/jw-05-1999/jw-05-toolbox.html)? It uses an extra thread to consume the message and "publishes" it. I'm aware that extra threads are a no-no in EJB context, but I recently had a EJB training and the instructor told me he'd think it would be ok if I started the consumer thread at startup time of the server. Any idea if this is true?
    Reply to this Reply to original

  37. Logging Mechanism for EJBs...[ Go to top ]

    Using SocketAppender in log4j might work and probably in future they might come up with JMSAppender and stuff but as I see you got be careful because you would be accessing the filesystem to configure log4j.
    Reply to this Reply to original

  38. Logging Mechanism for EJBs...[ Go to top ]

    Hi Kiran,
    could you give me a pointer to any existing examples using the SocketAppender for servlets/ejb logging, or provide me with some example code to be able to log messages using SocketAppender.

    Could you relay ur message to Bhargav at consultant dot com

    thanks again for ur time Kiran

    regards
    Bhargav
    Reply to this Reply to original

  39. Logging Mechanism for EJBs...[ Go to top ]

    I think the limitation is that the *EJB* should not use java.io. That makes perfect sense to me. Instead, you could have a class like "Logger" or whatever you want to call it. Use static methods or make it a singleton and do all logging like this:

    Logger.write(classname, severity, text);

    XML would be a great idea for the log file. I'd never even thought of that. You can parse for severity, easily convert to HTML for browsing, etc.
    Reply to this Reply to original

  40. Logging Mechanism for EJBs...[ Go to top ]

    The problem with XML as a log file is that it is much more complicated to do even simple searches on ad hoc basis.
    With simple flat files you could use grep type of stuff etc. on even huge files to filter out necessary lines and get some preliminary results fast. With XML you need a parser and an approach for ad hoc queries (XQL or something).
    Haven't found a good tool yet besides importing into database and running queries there.
    Reply to this Reply to original

  41. Logging Mechanism for EJBs...[ Go to top ]

    I have done a simmilar thing (Logger Class) for a project last month. The best thing about this is that ramp up time to using this against using JLog et al. is much less. Best of all it works:))

    I saw in an earlier thread somebody mentoining using JLog with WAS 3.5 (specifically EJB). FYI JLog uses threads.
    Reply to this Reply to original

  42. Logging Mechanism for EJBs...[ Go to top ]

    The log4j package, mentioned previously, also permits logging to a Socket. It includes a SocketAppender, a SyslogAppender (which writes using Sockets to a Syslog daemon), a JMSAppender, an SMTPAppender, and a recent contribution of a JDBCAppender. Incidentally, the package has now been adopted by the jakarta project of Apache.org.

    Being involved in J2EE, I always have to look a bit askance at the oft-repeated "restriction" on use of java.io APIs by J2EE applications. The EJB spec says:

    "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, to store data."

    What is the real point of this restriction? It is that file systems are not typically transactional in nature. If your transaction is to have ACID properties, then resource managers that can be coordinated for commit or rollback by the container should govern all the resources utilized by your transaction. Since files cannot do this, they should not be used for storage of information that is critical to the success or failure of a business process. Consider too that securing files can be problematic. Files limit the portability of an application because they introduce potential encoding concerns, hardcoded path problems, etc. And file systems are not considered highly available network accessible resources that can be located by using JNDI.

    But that doesn't mean there might not be valid uses of files for other purposes. What about property files? What about resource bundles? What about XML documents? Where do you put images? How do you think the container does it's logging?

    On the project that I am currently leading (WebSphere 3.5.2), we use files for read-only resources (non-transactional) as well as for logging. It isn't that files are somehow _evil_. It is that unrestricted use of files can lead to the problems I've enumerated. Unless your container absolutely prevents the use of the java.io APIs, I wouldn't so readily dismiss using files for logging. Writing a log to a local file has been, in my experience, much more performant than either JMS or JDBC solutions and doesn't require nearly the infrastructure of these and other (SMTP and Socket server) options. When it comes to logging, you want it to be pretty darn simple because it is going to be most valuable to you when everything else is going wrong.

    Best regards,
    Jim Cakalic
    Reply to this Reply to original

  43. Logging Mechanism for EJBs...[ Go to top ]

    We are moving from a net-centric environment to a EJB-based
    environment. In the net-centric world all the logging was done within the JVM for a particular client (normal file i/o). Now in a distributed environment where the EJB's are on different servers than the client (in fact it could be on any server since the container could move EJB's around to perform load-balancing or on a fail-over), how would you ensure that the log information is generated on the client side rather than on the server?
    Reply to this Reply to original

  44. Logging Mechanism for EJBs...[ Go to top ]

    Could you please tell me how to update the security policy of Weblogic 6.0
    Reply to this Reply to original

  45. Logging Mechanism for EJBs...[ Go to top ]

    I have been trying to use Log4j with IBM websphere for a webbased application.My first problem is it doesn't recognize the Properties file for Log4j
    . My second problem(to overcome the first i had to hardcode the Path for properties file..) is after it restarts the server everytime it encounters PropertyConfigurator class(its a log4j class..) can anybody tell me whats happening???
    Reply to this Reply to original

  46. Logging Mechanism for EJBs...[ Go to top ]

    Hi Mahesh,
    can you suggest me a starter for log4j, i am trying to run the examples provided with the package and i am able to run the examples, but need to explore further into this logging package.
    i would greatly appreciate if you can provide me with some info.
    My email is Bhargav at consultant dot com, once again ur help will be greatly appreciated

    thanks for your time
    Bhargav
    Reply to this Reply to original

  47. Logging Mechanism for EJBs...[ Go to top ]

    But what happens when a logging message pops up that you didn't write, for example, where a nullpointerexception is thrown; that gets written to the weblogic log file; how would you get those to go to some other special log file or to a JMS queue?? The JMS queue sounds like a great idea, but I wonder how you would get exceptions to go to it. cya
    Reply to this Reply to original

  48. Logging Mechanism for EJBs...[ Go to top ]

    Getting your exceptions to go the JMS queue means catching the right exceptions in the right places.

    Of course, you may very well not want to catch RuntimeException and its children, precisely because you don't know what to do with them in any case!

    We have been using LOG4J with WebLogic with great success, although we have the same problem, that the exceptions we deliberately don't catch end up in the weblogic.log file.

    I don't know if WebLogic allows you to install your own Exception handler. You can over-ride default behavior of a ThreadGroup by sub-classing it and over-riding the uncaughtException(Thread, Throwable) method. If there is any way in WebLogic to override the default thread group (or plug in your own exception handler to whatever ThreadGroup sub-class they may have written) then you are sorted. You can simply put the call to your JMS logger in there.

    Of course, the default handler will simply dump the stack trace to System.out. To do anything more _might_ be unpredictable. For instance, if the Throwable in question is an OutOfMemoryError then do you have sufficient resources to send a message to JMS?

    Chz

    Tony
    Reply to this Reply to original

  49. Logging Mechanism for EJBs...[ Go to top ]

    What is the advantage of using Log4J instead of the facilities provided in weblogic? It seems like wls6.0 is robust enough to handle most logging needs. I'm trying to decide whether to include Log4J or just wrap the logging in wls.
    Reply to this Reply to original

  50. Logging Mechanism for EJBs...[ Go to top ]

    Well, if I can't get "all" of the logging to go to one place, I wouldn't want to use something like log4j or a jms queue (as cool as that sounds; what a neat idea!), because it would make it harder to decipher problems, and you'd have to bounce back and forth.

    No, I think I'll continue using the weblogic log file. cya
    Reply to this Reply to original

  51. Logging Mechanism for EJBs...[ Go to top ]

    Hello,

    I'm pretty new to ejb and unsuccessfully tried to implement the log4j API for logging messages.
    I think i miss something about the proper way to initialize the Categories.
    Could anyone send me some example of login with log4j in an entity bean?

    Artediane at isuisse dot com

    Thank you
    Regards
    Reply to this Reply to original

  52. Logging Mechanism for EJBs...[ Go to top ]

    This ought to get you started:

    to create a category:

    ...
        private static Category _cat = Category.getInstance(TestSQLOrderFetch.class.getName());
    ...

    initialize log4j:

    BasicConfigurator.configure();


    log some stuff!!
    _cat.error ( "This is an error" );
    _cat.debug ( "This is a debug" );

    See log4j docs for more samples....

    Reply to this Reply to original

  53. Logging Mechanism for EJBs...[ Go to top ]

    Why are you making that static? If you're using it in an EJB, isn't that discouraged?
    Reply to this Reply to original

  54. Logging Mechanism for EJBs...[ Go to top ]

    I agree.
    My question is:

    Is it correct to declare the Category static final? (which is allowed in an EJB AFASK ).

    Where is the right place to set the configurator. Is the singleton pattern a solution ( a sort of configurator class which is a singleton?)

    In this case, including the fact that there might be n AS instances,does this singleton should lived in jndi in order to be sure that only one instance lives in the whole network?

    Sorry
    Reply to this Reply to original

  55. Logging Mechanism for EJBs...[ Go to top ]

    Is it correct to declare the Category static final? (which is allowed in an EJB AFASK ).


    That's my understanding...

    >>Where is the right place to set the configurator. Is the singleton pattern a solution ( a sort of configurator class which is a singleton?)

    That's what I did for our logging... cya
    Reply to this Reply to original

  56. Logging Mechanism for EJBs...[ Go to top ]

    Oops. I'm sorry-- I posted some log4j code that didnt make a lot of sense-- I forgot we were talking about EJBs, and just posted some plain 'ol log4j code.

    For our logging for log4j inside of WLS, we used a line like this:
      PropertyConfigurator.configure(..)

    inside of a Weblogic Startup class. that way, the log4j to weblogic "bridge" is started up before anybody can access the server ( we mark this startup class such that if it fails, server startup is aborted).

    Inside of the EJBs we use to the code as it was posted. The static final category may not be the recommended approach, but it works well and is very fast....
    Reply to this Reply to original

  57. Logging Mechanism for EJBs...[ Go to top ]

    hi Dave,

     ur code gives error on line::::::::
    _wlogger = new NonCatalogLogger(source );


    it is not getting class NonCatalogLogger

    What do I need to do?
    Reply to this Reply to original

  58. Logging Mechanism for EJBs...[ Go to top ]

    Is there some performance decline by doing lookup on every appending message to queue?
    Does log4j support JMS well?
    Reply to this Reply to original

  59. Logging Mechanism for EJBs...[ Go to top ]

    Greg,

    You seem to have acquired some savvy with log4j and EJB's,
    could you possibly give me some advice?

    I am currently creating a logging API for a 3 tier architecture. The requirements are the following:

    1) Central logging for all parts of the system.
    2) All messages contain an application context identifier
       for the purpose of grouping the log messages.(Application
       context is just an identifier issued for each request from the browser by the webserver. This would then be
       passed in the parameters through each layer. Then all
       messages could be grouped by this ID and timestamp in order to construct the execution sequence.)
    3) Static methods for all login activity.

    We are using log4j and WLS6.0 and will want to migrate to
    WebSphere. I've been building an API to test what is possible and have found some success but I am unsure if I
    am on shaky ground with regards to the appservers.

    In order to share the current context between the webserver and appserver I added the context to the method call parameters. In order to minimize the passing of the application context id within the classes that perform the work in our EJB's, I have been setting a ThreadLocal variable with the context. On the webserver side, I am fairly sure that a given request will be satisfied within a single thread of execution. But I have found that within WLS6.0 that all subsequent calls from the initial EJB execute within the same thread. But I fear that this behavior is strictly a function of our current app server configuration and will not be the case with other app servers or when we set up clutering.

    Do you know how the appserver thread model works? Is it just a plain bad idea to rely on all calls for an initial re
    Reply to this Reply to original

  60. Logging Mechanism for EJBs...[ Go to top ]

    If you use the JBoss server all you have to do is call System.out or System.err and the message will be logged in the server logs with extra information (such as bean name, timestamp, type).

    You can add custom filters that extract bean logs into separate log files.

    If you want you can also use our proprietary log API for more control over the logging.

    For more info on JBoss see www.jboss.org
    Reply to this Reply to original

  61. Logging Mechanism for EJBs...[ Go to top ]

    sys.outs kill performance ...
    Reply to this Reply to original

  62. Logging Mechanism for EJBs...[ Go to top ]

    JBoss 2.1 (maybe already in 2.0) also contains Log4J in its extensions. So those who are familiar with it or do not fear to learn it (despite the more complex structure) may also use Log4J inside JBoss.
    Reply to this Reply to original

  63. Logging Mechanism for EJBs...[ Go to top ]

    I wrote a singleton class to do it with debugging levels and it derives the calling method from a stack trace...
    Reply to this Reply to original

  64. Logging Mechanism for EJBs...[ Go to top ]

    Another way would be to have a separate central service which listens on the corba orb (or rmi or whatever).
    It can receive messages from your beans and write them to a central file. This seems to be at least a standard way to do this, I think Inprise even has some sample code for this somewhere..

    greetings,
     jochen
     jochent@poet.de
    Reply to this Reply to original

  65. Logging Mechanism for EJBs...[ Go to top ]

    I am interested to know how the an EJB can talk to
    an Orb service. Could you give me some hint?

    Please also relay your reply to my email
    james-zhao at excite dot com

    Thanks!

    James
    Reply to this Reply to original

  66. Logging Mechanism for EJBs...[ Go to top ]

    well...this all depends how ur appserver implements iiop.

    By and large they use extension mechanism of the JVM.

    just start the orb service at background , change the properties file.....and replace the jars with ur ORB jars .

    btw which appserver r u using ?

    .net
    Reply to this Reply to original

  67. Logging Mechanism for EJBs...[ Go to top ]

    sure! Log4J is too complex for logging "administration messages"

    I hope that JSR "Java Logging API" would be adopted very quickly and that J2EE products would support that. (The only problem with threads is that AS doesn't want "foreign" threads that are not managed by its )
    Imagine an AS integrating this API , and no more fears...

    Althought, I am not sure that XML in logging messages are very usefull... I know, I know, XML is a BuzzWord !
    Reply to this Reply to original

  68. Logging Mechanism for EJBs...[ Go to top ]

    For a prototype, I ve used JMX API for logging. but It is not very good. the JMX implementation (adventnet) uses threads ...

    and J2EE Management API is still in JSR!
    Reply to this Reply to original

  69. Logging Mechanism for EJBs...[ Go to top ]

    If you think log4j is "too complex", you're aren't going to be pleased with the results of the JSR-0047 implementation. That specification details a design that shares many of the same principles as log4j. Unfortunately, they maintain the notion of a Singleton logger which log4j has eliminated. And I don't recall it being as flexible with respect to external specification of log event format. But it is by no means as simple as System.out.println -- nor should it be.

    Jim Cakalic
    Reply to this Reply to original

  70. Logging Mechanism for EJBs...[ Go to top ]

    The project I am working for has EJBs that call native methods. I know it is against EJB specs and we are trying to find an alternative. But till that happens, which may not be too soon, I need to do logging on both the ejb end and at the native end. Do you or anyone has any suggestions as to how this can be accomplished?
    My concerns are ...
    How can I achieve synchronized logging between native code and java code?
    Can JMS help in this case?
    Can tools like Log4j be useful at all or should I resort back to simple singleton logger class approach? But then also can I use it with multiple beans and their multiple instances and the native code?

    Any help is appreciated.
    Thanks
    Reply to this Reply to original

  71. Logging Mechanism for EJBs...[ Go to top ]

    vaishali jain wrote:

    The project I am working for has EJBs that call native methods. I know it is against EJB specs and we are trying to find an alternative. But till that happens, which may not be too soon, I need to do logging on both the ejb end and at the native end. Do you or anyone has any suggestions as to how this can be accomplished?
    My concerns are ...
    How can I achieve synchronized logging between native code and java code?
    Can JMS help in this case?
    Can tools like Log4j be useful at all or should I resort back to simple singleton logger class approach? But then also can I use it with multiple beans and their multiple instances and the native code?

    -------

    My reply:

    Generally speaking, if you need to access native code from an EJB, you don't <smile>. Instead, you create some other 'remote' interface for the invocation of that native code as a service. So, for example, you could create an RMI server that would invoke that native code, then call that RMI server from your EJB. If the native code is one way, (i.e. you don't require a synchronous response), then you can do things like send a JMS message.

    God bless,
    -Toby Reyelts
    Reply to this Reply to original

  72. Logging Mechanism for EJBs...[ Go to top ]

    SuperLogging from Super is a centralized logging. You
    can log from native code. It is very simple, just
    call a SQL satement.

    Of course, you will not get all the features that are
    available for Java.

    I can provide detailed informtion about native code
    access if you want.



    Try SuperLogging of Super from www.acelet.com.
    The next release will be free for open source (Jonas, jboss and
    j2ee-ri).

    SuperLogging is a full-featured logging tool:

     * It is a centralized logging, guaranteed tobe chronolotical.
       It supports distributed computing and works well in any
       clustering environment. all log messages are recorded in
       one central place regardless which EJB runs on which
       server.

     * It is platform neutral and EJB vendor neutral.

     * All log statements used in the source code do not need be
       removed for production releases. Log messages can be
       dynamically filter out and the performance penalty will be
       minimum.

     * An open source wrapper com.acelet.opensource.logging.Alog is
       provided for preventing vendor lock in. Source code of EJBs
       is not required for any modification if another logging
       packages is chosen. In that case, the only modification
       needed is this wrapper, which is just a few lines of code.

     * It is fully dynamically configurable by a Swing tool. The
       configurable attributes include the following:

     * Choice of configuration scope: Global Dynamic, Global Static
       and Singleton.

     * Choice of mode: Quiet, Verbose and Conditional.

     * Class registration: log messages will be printed out for
       registered classes only.

     * Log level: lower level log requests will be filtered out.

     * It provides Tracing facilities which show both log messages
       and source code with marked line in question.

     * It provides built-in email alert method and alert interval
       control.

     * It provides email methods which allow sending email by a
       simple method call.


    Reply to this Reply to original

  73. Logging Mechanism for EJBs...[ Go to top ]

    Could you not write an application that connects to the EJB via sockets, then connects to the native code using named pipes and JNI? WOuld this work? I am new to EJB's and just a little less new to JAva.
    Reply to this Reply to original

  74. Logging Mechanism for EJBs...[ Go to top ]

    Brian Heisler wrote:

    Could you not write an application that connects to the EJB via sockets, then connects to the native code using named pipes and JNI? WOuld this work? I am new to EJB's and just a little less new to JAva.

    ------

    My response:

    As long as it was the EJB opening the socket connection and the native code was the one accepting it. (This is essentially what I was saying in my previous message). EJBs are not allowed to run 'socket servers'.

    God bless,
    -Toby Reyelts
    Reply to this Reply to original

  75. Logging Mechanism for EJBs...[ Go to top ]

    Could you not write an application that connects to the EJB via sockets, then connects to the native code using named pipes and JNI? WOuld this work? I am new to EJB's and just a little less new to JAva.
    Reply to this Reply to original

  76. Logging Mechanism for EJBs...[ Go to top ]

    You can connect to an ORB with Borland Application Server this allows the EJB to be a java object and a corba object at the same time.

    Reply to this Reply to original

  77. Logging Mechanism for EJBs...[ Go to top ]


    Take a look at this:

    http://protomatter.sourceforge.net/1.1.2/index.html

    The package "com.protomatter.syslog" contains a robust logging system suitable for use with EJBs. I'm biased towards it because I'm the author ;-) Read the whitepaper referenced in that document for an introduction to use. Version 1.1.3 will be out in the next couple of weeks, and has JMS integration, remote logging (via RMI or other protocols), a logger that sends email, and lots of performance improvements.

    If you want to peek at the next release, there's a beta available from http://www.protomatter.com/software/beta

    -nate
    Reply to this Reply to original

  78. Logging Mechanism for EJBs...[ Go to top ]

    Hi,
    I'm working on this project where we are using a cocoon framework. We have four applications, hence four producers that interact with EJBs (that reside on an Inprise app. server, a different JVM). I have a question:
    how can I pass the config file for Syslog (config.xml) for cocoon ? Do I pass it in, in the init() method of each producer individually or is there any better way ?
    Also, could you suggest a neat way of configuring syslog on the EJB side?
    Reply to this Reply to original

  79. Logging Mechanism for EJBs...[ Go to top ]

    G'Day Nate,

    I'm a Java Developer currently working with JBuilder and Borland App server environment.We're developing a small proof of concept project work.In my project i want to implement this Syslog mechanism in both client side as well as server side programming.I tried to implement the package by giving the two jar files(protomatter.jar and jdom.jar)into the project classpath settings.Then i tried to use the logging codes in my programme during execution its working fine, but its not generating any log file in my local m/c.

    Can u help me in this regard, and send me some code sample so that i can evaluate ur product in a better way.

    Thanks in advance

    Cheers
    rajat.

    E-mail:rajat_k_patro at yahoo dot com
    Reply to this Reply to original

  80. Logging Mechanism for EJBs...[ Go to top ]

    Try looking at "Super" which you can download for free from the http://www.acelet.com website. It not only provides you with logging capability but also the ability to do a peek or poke of the variables to help you in the debugging process.
    Reply to this Reply to original

  81. Logging Mechanism for EJBs...[ Go to top ]

    Try SuperLogging of Super from www.acelet.com

    Try SuperLogging of Super from www.acelet.com.

    SuperLogging is a full-featured logging tool:

     * It supports distributed computing and works well in any
       clustering environment. It is guaranteed that all log
       messages are recorded in one place and in the order of
       actual happening, regardless which EJB runs on which server.

     * It is platform neutral and EJB vendor neutral.

     * All log statements used in the source code do not need be
       removed for production releases. Log messages can be
       dynamically filter out and the performance penalty will be
       minimum.

     * An open source wrapper com.acelet.opensource.logging.Alog is
       provided for preventing vendor lock in. Source code of EJBs
       is not required for any modification if another logging
       packages is chosen. In that case, the only modification
       needed is this wrapper, which is just a few lines of code.

     * It is fully dynamically configurable by a Swing tool. The
       configurable attributes include the following:

     * Choice of configuration scope: Global Dynamic, Global Static
       and Singleton.

     * Choice of mode: Quiet, Verbose and Conditional.

     * Class registration: log messages will be printed out for
       registered classes only.

     * Log level: lower level log requests will be filtered out.

     * It provides Tracing facilities which show both log messages
       and source code with marked line in question.

     * It provides built-in email alert method and alert interval
       control.

     * It provides email methods which allow sending email by a
       simple method call.


    By the way, there are other SuperComponents on Super:
    PeekPoke and SuperStress.
    Reply to this Reply to original

  82. Logging Mechanism for EJBs...[ Go to top ]

    You might want to check out JSR000047. This details logging APIs currently under review. "The Java Logging APIs will be delivered as part of J2SE 1.4 "Merlin". Beta will be around March 2001 and FCS will be around October."
    Reply to this Reply to original

  83. Logging Mechanism for EJBs...[ Go to top ]

    Yes, it is for J2SE, not J2EE. It is a standard
    API. You still need a logging engine in J2ee server.
    Reply to this Reply to original

  84. Logging Mechanism for EJBs...[ Go to top ]

    I just wrote a simple wrapper around Weblogic's logging facility that does the trick for me (for now !).
    Weblogic 6.0 logging works for both I18N and L10N messages, and can integrate with JMS as well.


    Reply to this Reply to original

  85. Logging Mechanism for EJBs...[ Go to top ]

    I'm trying to find a way of doing this (reading syslogs from the appserver aswell) on IBM Websphere Enterprise Edition. - Trouble is that the logfiles (error.log / activity log) are not textfiles - WSEE uses some binary file format for logging. This format can then be parsed using the showlog utility. This sucks, as there is no way to get a continuous feed of log messages. Has anyone had experience of gettig some logtool to continually parse the binary logfiles - or does anyone know of another way around it?
    /m
    Reply to this Reply to original

  86. Logging Mechanism for EJBs...[ Go to top ]


    Does anyone have a simple wrapper to WebLogic's logging framework?

    Yvon Lavoie
    Reply to this Reply to original

  87. Logging Mechanism for EJBs...[ Go to top ]

    We have used Log4J for all of our logging, with tremendous success.

    We also use Weblogic 6.0 for our application server, and found that we wanted much of our code to be portable and testable without any weblogic specific code in it.

    To take advantage of the benefits of the weblogic framework, and to allow our code to work outside weblogic when we run our unit tests, we wrote a Log4J Appender that maps events from log4j to the weblogic event log. We write all of our classes ( yes, including EJBs) to the Log4J API, which in turn uses our Weblogic appender to send the messages to the weblogic logs. Voila-- code can be portable ( no lockin to BEA), will run outside the app server, yet avoids the File IO restriction of EJBs....

    If anybody is interested in the source code, I'll be happy to send it. Send email to thebluedirt at yahoo dot com.
    Reply to this Reply to original

  88. Logging Mechanism for EJBs...[ Go to top ]

    But, the problem with that is, isn't it true that any uncaught exception goes to the weblogic log, but NOT to your log4j output??

    Reply to this Reply to original

  89. Logging Mechanism for EJBs...[ Go to top ]

    Yes, that's true. Actually anything that weblogic logs will use its log directly. ( For example, startup logs, shutdown logs, administrative events, etc. ).

    We use the Log4J as a logging mechanism to allow our EJBs to log without using fileIO _and_ without writing to weblogics logging framework. Uncaught exceptions would go into the weblogic log, but its pretty easy to make sure that never happens by catching all exceptions and handling them appropriately ( which should be done anyway, right? )

    Reply to this Reply to original

  90. Logging Mechanism for EJBs...[ Go to top ]

    Uncaught exceptions would go into the weblogic log, but its pretty easy to make sure that never happens by catching all exceptions and handling them appropriately ( which should be done anyway, right? )


    Good luck catching every single possible point in a system where a nullpointer exception could possibly occur.

    Also, if you have some of your logging going in one place and the rest of it in another, it seems like it would make it harder. The way our logging is set up, if an error occurs, we see a "history" of logging messages behind it that led up to that. If all our logging were going to our log file except some weird exception that happened in the weblogic log file, it would make it hard to tell what happened and what caused it. cya
    Reply to this Reply to original

  91. Logging Mechanism for EJBs...[ Go to top ]

    Tracy Milburn wrote:

    Good luck catching every single possible point in a system where a nullpointer exception could possibly occur.

    Also, if you have some of your logging going in one place and the rest of it in another, it seems like it would make it harder.

    -----------

    Well, that's about as easy as writing:

    try {
    }
    catch ( Throwable t ) {
    }

    Every good application should make sure that no exceptions escape unhandled.

    Since no uncaught exceptions will be thrown, they won't be sent to the weblogic log file.

    God bless,
    -Toby Reyelts
    Reply to this Reply to original

  92. Logging Mechanism for EJBs...[ Go to top ]

    Every good application should make sure that no exceptions escape unhandled.


    What if the container throws an exception? We get socket reset by peer exceptions all the time in the logs, how would you catch those? They just appear. And what if the container throws an exception you have no control over; what if you get an exception because someone re-deployed an EJB? Not sure where you'd catch things like that.

    Although the goal is to catch all exceptions, I've yet to see an application that did.
    Reply to this Reply to original

  93. Logging Mechanism for EJBs...[ Go to top ]

    looks like we're a bit off topic now, so this will be my last post on this exception topic.

    Of course, you are correct. In addition to container exceptions, there are all sorts of weblogic "INFO" types of things that show up there too. I just meant that all of the code that _we_ write doesnt throw any uncaught exceptions. Running WLS for a while, it does throw log some exceptions ( but it catches them and prints stack traces to the logs ). None of these exceptions are "uncaught" either. That sort of stuff is why we chose to re-direct log4j logging events into the weblogic log instead of trying to send our events to a separate log file and somehow move the weblogic events into it.

    BTW, we've been running a production application on WLS for a couple of months now-- we dont see any uncaught exceptions at all. The worst case is that the very top level handlers catch the exception and then print a stack trace out. Keep in mind that there is a big difference between "handling" and exception and "catching" an exception. Our application _never_ throws uncaught exceptions to its container ( whether that container happens to be standard VM or an appserver). The worst possible case is that they bubble up to the last level, which catches Throwable and then logs the stack trace.


    Reply to this Reply to original

  94. Logging Mechanism for EJBs...[ Go to top ]

    Luck doesnt have much to do with it-- it's part of writing good software ;)
    Reply to this Reply to original

  95. Logging Mechanism for EJBs...[ Go to top ]

    Tracy:

    I think you may misunderstand how our setup works. I agree that having multiple log files would be a pain. We use Log4J as the API that we write our code to, but when Log4J accepts logging events, all of them are re-directed to the weblogic logs. Thus, _all_ of our messages end up in a single log, the weblogic log. The real benefit is that we accomplish this without having to pollute all of our code with Weblogic-specific api references ( which is really handy when running test cases outside the app server ).

    Dave
    Reply to this Reply to original

  96. Logging Mechanism for EJBs...[ Go to top ]

    I agree that having multiple log files would be a pain. We use Log4J as the API that we write our code to, but when Log4J accepts logging events, all of them are re-directed to the weblogic logs.


    Ah, ok! I see, that makes sense. So, it isn't a matter of getting weblogic exceptions to go to your log, but rather that you send your exceptions to the webogic log.

    What was set up here when I came, and i haven't bucked it so far, is that when we start the server, we nohup the output to a file, so that all exceptions, whether they're weblogic or our logging messages, go to the same file. Of course, a weblogic.log is still being built but we don't even need to look at it.

    For logging I wrote a singleton that does that and various other things.

    Take care, cya
    Reply to this Reply to original

  97. Logging Mechanism for EJBs...[ Go to top ]

    we nohup the output to a file, so that all exceptions, whether they're weblogic or our logging messages, go to the same file


    I'm interested in what you mean here. does this mean that you redirect output of the console to a file with the > operator? Where would your logging messages go if you did not "nohup the output to a file"?

    I'm always interested in learning new ways to skin a cat.

    Thanks
    Dave
    Reply to this Reply to original

  98. Logging Mechanism for EJBs...[ Go to top ]

    we nohup the output to a file, so that all exceptions, whether they're weblogic or our logging messages, go to the same file


    >I'm interested in what you mean here.

    Right, there's a script that starts the weblogic.Server and we nohup that script to a file so that all output, stack traces etc. go there. As far as I can tell it works pretty good. Although I made changes to the script the idea was in place when I got here. cya
    Reply to this Reply to original

  99. Logging Mechanism for EJBs...[ Go to top ]

    Oh, ok. I gotcha.
    Reply to this Reply to original

  100. Logging Mechanism for EJBs...[ Go to top ]

    Per popular request, here is a very basic Log4J to Weblogic
    bridge. <cya>This code is offered as is with no warranty, support, or any of that stuff, implied or expressed. That means I wont support it, take any responsibility for your system messing up if you choose to use it, etc.</cya> that said, we've been running it in a production system for a couple of months without any problems.

    You need to have the log4j and weblogic jars in your classpath for it to compile...

    Hope this helps some folks-- Enjoy!
    Dave


    <!-- Begin Code -->

    package util.log;

    import org.apache.log4j.*;
    import org.apache.log4j.spi.LoggingEvent;
    import org.apache.log4j.Layout;
    import org.apache.log4j.TTCCLayout;

    import weblogic.logging.NonCatalogLogger;

    import java.io.PrintWriter;
    import java.io.StringWriter;

    /**
     * This class is a wrapper to bridge between
     * apache log4j and weblogic NoCat Logger.
     * Colinx classes generally use log4j logging instead of using
     * weblogic logging this appender allows classes to be configured
     * to use weblogic events while still preserving code generality.
     *
     * In order to use this appender, log4J should be configured to
     * use this appender in the configuration.
     * This is most easily done using a startup Class that will
     * do the basic configuration and include this appender.
     *
     */
    public class WeblogicLogAppender extends AppenderSkeleton
    {

      //store the weblogic logger object
      private NonCatalogLogger _wlogger = null;
      /**
       * Create a new appender with default layout and source
       */
      public WeblogicLogAppender()
      {
         this( null,null );
      }

      /**
       * Create a new appender with default layout and source
       */
      public WeblogicLogAppender(String source)
      {
          this ( source, null );
      }

      /**
       * Create a new appender with default layout and source
       */
      public WeblogicLogAppender(Layout layout)
      {
          this ( null, layout );
      }

      /**
       * Create a new appender by specifying a layout
       */
      public WeblogicLogAppender(String source, Layout layout)
      {
          //if no source is provided, supply one.
          if ( source == null )
          {
              source = "Log4JBridge";
          }

          //store the layout-- create a new one if necessary
          if (layout == null)
          {
            this.layout = new TTCCLayout();
          }
          else
          {
            this.layout = layout;
          }

          //create the weblogic logger
          _wlogger = new NonCatalogLogger(source );

      }

      /**
       * This appender requires a layout
       */
      public boolean requiresLayout()
      {
        return true;
      }

      /**
       * Actually do the logging. Note that at this point the Log4J framework
       * has ensured that we should be acutally logging this item, so all we
       * have to do is normalize the Log4J levels to the weblogic logger
       * levels.
       */
      protected void append(LoggingEvent event)
      {
        // First, format the log string so we can send it to NT.
        StringWriter sw_writer = new StringWriter();
        PrintWriter pw_writer = new PrintWriter(sw_writer);
        pw_writer.print(layout.format(event));

        pw_writer.close();

        // Normalize the log message priority into the supported categories
        if ( event.priority.equals(Priority.DEBUG ) )
        {
            if ( event.throwable != null )
              _wlogger.debug(sw_writer.toString() , event.throwable);
            else
              _wlogger.debug(sw_writer.toString() );
        }
        else if ( event.priority.equals(Priority.INFO))
        {
            if ( event.throwable != null )
              _wlogger.info(sw_writer.toString() , event.throwable);
            else
              _wlogger.info(sw_writer.toString() );
        }
        else if ( event.priority.equals(Priority.WARN ))
        {
            if ( event.throwable != null )
              _wlogger.warning(sw_writer.toString() , event.throwable);
            else
              _wlogger.warning(sw_writer.toString() );
        }
        else if ( event.priority.equals(Priority.ERROR) ||
                  event.priority.equals(Priority.FATAL ) )
        {
            if ( event.throwable != null )
              _wlogger.error(sw_writer.toString() , event.throwable);
            else
              _wlogger.error(sw_writer.toString() );
        }
        else //should not happen...
        {
            if ( event.throwable != null )
              _wlogger.warning(sw_writer.toString() , event.throwable);
            else
              _wlogger.warning(sw_writer.toString() );
        }

      }

      /**
       * Close resources-- for the weblogic appender there are none.
       */
      public void close()
      {
        /** Nothing needed here... */
      }
    }
    Reply to this Reply to original

  101. Logging Mechanism for EJBs...[ Go to top ]

    I have written a logging mechanism called JLogger which is a JDK1.2+ implementation of the new java.util.logging classes. I have also written a SwingConsoleHandler so you can view log records as they happen.

    It is FREE for licence and distribution and can be found at: -

    http://www.javelinsoft.com

    We are currently using it on a couple of projects, for example, a Free UK recruitment website at: -

    http://www.jobshive.com

    Reply to this Reply to original

  102. Logging Mechanism for EJBs...[ Go to top ]

    I am Using Weblogic 6.0 sp1, I use the weblogic NonCatalogLogger... like so:

    <pre>
    //Weblogic.Logging
    import weblogic.logging.NonCatalogLogger;

    public final class Test implements EntityBean {
       // This is the logging object
       private NonCatalogLogger log;

       // Create the logger
       log = new NonCatalogLogger("TEST-LOG");

       // log to it - info, warn, debug, error
       log.error("This is a test of the error level");

       /*
        *
        * Your code in here - with logging..
        *
        */

    }
    </pre>

    Will produce the output:<br>
    <4/10/2001 10:23:59> <ERROR> <TEST-LOG> <This is a test of the error level><br>
    under the logging console...<br>
    Hope this helps..
    Reply to this Reply to original