3 Replies Latest reply on Mar 10, 2004 5:39 AM by stefanfreyr

    EJB Logging and the "delegate pattern"

    stefanfreyr

      I'm very sorry for cross posting this here and in the "User questions" forum... I always meant to put it here but somehow managed to screw that up.

      Anyways... I have two pretty general questions about EJBs and in a way, JBoss.

      1) I'm curious if there is some standard way of performing logging in EJBs (or if there is some specific JBoss way)? I've read the (minimal) chapter on "The JBoss Logging Framework" in the JBoss book and it fails to explain how to go about using the framework. It does explain to some extent how it is built up but not much more than that. So my question is: How do I log something in an EJB in JBoss? I'd of course want my application specific logging to go to a seperate file(s) and it should be as scalable as possible (for example, what happens if I'm writing to a file and decide to create a JBoss farm? Will all logging from the many different instances of bean Y go to the same file? Hardly.). Any explanation on the subject and references to some good reading material would be very well appreciated.

      2) I read in an article that was a part of an IBM serie "EJB Best Practices" - http://www-106.ibm.com/developerworks/java/library/j-ejbcol.html ) how you could use static validation methods in seperate classes to validate data for a session EJB - http://www-106.ibm.com/developerworks/java/library/j-ejb01213.html. Now, this article series also talks about something called the "business delegate pattern" that I assume (I haven't read the whole series yet) is that there is a Java class that actually performs the work that the session bean provides the interface for.
      I've been using classes with static methods to perform the work of session beans (because many of the methods that are in my session beans are doing the same thing). I always ment to go through those things and change them to a "Factory pattern" so that the worker will actually be an instance with instance (not static) methods. What I was thinking when I decided that I should do that was that a static method wouldn't be thread safe when many clients would be accessing the app server and calling various session bean methods that might be using one of the static "delegate" methods. In other words, I'd possibly get more than one calls to the same static method at the same time (originating from one or even more session beans). But when I saw that "static method way" was done for validating data in one of these articles, I had second thoughts. I know that you shouldn't write into a static field in an EJB but you can use a final static field (read only). So my question is: should I avoid using "helper/worker/delegate" classes with static methods? If the answer is yes I pretty much know why... but if the answer is no... then why do they work??? Two things that I'm curious about: a) if the static method is not declared with the synchronized keyword, is there a possibility that two or more beans might be calling the same method at the same time? How exactly would that work (or fail... depending on how you look at it)?

      Any and all information about the above two questions would be very much appreciated.

      Kind regards, Stefan.

        • 1. Re: EJB Logging and the "delegate pattern"
          bman917

          EJB Logging

          JBoss uses log4j for its logging. I havent yet seen or fund its configuration but i'm prety sure that jboss uses log4j to display its output to the console and also to write its logs into a file.

          log4j is a logging mechanism developed in the apache.commons project. However i just checked the site http://commons.apache.org/ and its not there anymore.

          Anyway, here's an overview of how log4j works and how you might configure it to log to another file.

          Basically, i see log4j as a high tech replacement for System.out.println. That is, instead of using system.out.println to debug my code, i use log4j instead.

          Two of the important things in log4j is the Logger and the Appender.

          Think of the Logger as a category. For example, we might have a Logger1 for bean1 and a Logger2 for bean2. Now these loggers may use different Appenders. An Appender determines where your log messages will go. So following the example, we can have three Appenders: Appender1 appends logs to a text file, Appender2 appends logs to an html file and Appender3 writes to the console.

          Loggers needs appenders in order for them to work. So, we assign Appender1 and Appender3 to Logger1 and Appender2 and Appender3 to Logger2. So what would happen is Logger1 will log its messages to a text file and to the console while Logger2 will log its messages to an html file and the console as well.

          • 2. Re: EJB Logging and the "delegate pattern"
            peejay

            I think if you use java classes with static methods and you use them to validate some stuff its ok. But you should be aware that many threads executing this method at the same time.

            Using static methods is not the business delegate pattern. The business delegate pattern reduce coupling between client and EJB tiers.

            See: http://java.sun.com/blueprints/patterns/BusinessDelegate.html

            • 3. Re: EJB Logging and the
              stefanfreyr

              An update to this post regarding the static methods contemplation:

              A static method is allocated memory space on the stack for each call to the method. This is best demonstrated by the fact that static methods can be recursive which would of course be impossible if all calls to that method used the same memory space.

              Therefore it is thread safe to use classes with static methods!

              Kind regards, Stefan Freyr.