logging in EJB components through JMS

[Paul Prusko]

Hi Ranchers,

I've been searching through the posts to find some answers/ways to go with logging
approches in EJB components and in general throughout J2EE environment. As the specification
denies writing directly to files from EJB components I'm close to base the solution on JMS messaging. However
I still wonder if this is a good and reasonable approach for large projects. First of all:
1. would the performance significantly degrade in face of the load with JMS messages and the need to process them?
2. if I collect the messages from the queue inside message driven bean (MDB) based message listener what choice do
I have to persist the log messages? I can think of writing to the database, sending emails, anything else?
3. is there any safe way to do it with MSB to finally end up with log files? The point is I need to do it all inside the
J2EE application server.

I'd appreciate your thoughts and a helping hand.
Cheers,
Paul.

[Prabhakar Reddy Bokka]

You can use log4j for logging.

go through the below article if you face any problems in configuration.

log4j in a J2EE

[Paul Prusko]

Thanks for your reply, Prabhakar.
It's nice article which can be useful at configuration stage.
However, I'm not facing configuration or class-loading issues at the moment but looking for design approaches to realize logging mechanism. Indeed, log4j is what I consider to make use of but first I need to be sure that my solution is compliant with J2EE specification in terms of persisting to file or DB and that it performs well as a JMS messaging scheme.

Could anyone point out some suggestions, considerations?
Thanks,
Paul.

[Prabhakar Reddy Bokka]

1. would the performance significantly degrade in face of the load with JMS messages and the need to process them?

You can use MDB for consuming messages. MDB will create a thread for each message it consumes. How ever if your message frequency is very high you can go for clustering of your application server for load balancing. I worked with an application which consumes messages @ 15 messages per second.

2. if I collect the messages from the queue inside message driven bean (MDB) based message listener what choice do
I have to persist the log messages? I can think of writing to the database, sending emails, anything else?

For logging you can use log4j which writes to log file. For storing any business data use database.

[Paul Prusko]

Thanks again,
Indeed, using MDB is my intention. Regarding storage approach writing to file from EJB component is my major concern because as we know it, J2EE specification restricts any IO operation from within EJB. Even though J2EE container providers usually do not prevent you from realizing this approach and in most cases it will work I would not like to break this restrictions and pose problems with distributability of components. Does this mean that the only thing I'm left with is writing logs to the database? There are some other solutions like using resource adapters for writing to the local file system or JDBC driver for writing to flat file but do they come at a reasonable expense?

Regards,
Paul.

[Prabhakar Reddy Bokka]

Writing logs to database doesn't make sence. How the support people look into the logs when somthing happened in system? Do they need to fetch from database?
Do you think its managable? I think managing logs this way is a nightmare.

Coming to using IO in EJB, specification denies to using IO. The reason is.. EJB is meant for serving the needs of Portable, Remote service components.
When you are using IO, it depends on local resources( i.e. files), So its not adviced.

However there are times where you need to use the IO in EJB. In that case you have to put the resources in the server's application root directory(i.e. root directory of the deployments). That means the resources will become local to the applications. All the externalized configurable parameters will go to this directory, also log files. Using IO this way will not cause for any performance reasons. That is the reason why EJB doesn't restrict you from using IO even though the spec denies.

Look into the EJB spec and reference deeply.

[Paul Prusko]

The specification clearly says that:

An enterprise bean must not use the java.io package to attempt to access files and directories
in the file system.

There is no mention about its internal directory structure to use as a trusted location or work around but rather a suggestion to use resource manager like JDBC. You are right that the deployment should not rely on local machine resources and storing a file in server's root directory solves only a part of the problem because you still have to deal with writing a stream to a destination which is not transactional - unless you use a resource adapter.

Writing logs to database doesn't make sence. How the support people look into the logs when somthing happened in system? Do they need to fetch from database?

Indeed I think it can make sense because you can easily query the database and filter only those entries that you might be interested in. You can also sort them or put in the order you wish to extract logs of given invoker. Moreover it is a step towards making a dump of the logs to a file system by the rdbms on a daily basis so that you have an archive. This gives you an alternative but at the same time does not violate the specification. What do you think?

Cheers,
Paul.