Hi all,

I'm developing an application right now that frequently needs access to some information not contained in the environment itself. It's all about security stuff that needs to be updated once in a while. To do this I thought of a file (place in a certain directory) but since the EJB specs do not permit the use of the java.io package, I was wondering if anybody has a solution for this. How do other people solve this one.

The same problem also comes up when meeting the log requirements. Of course the vendors themselves implement their logging, but I do not want to rely on that. That's why for logging (referring to the discussion some time ago) I use Log4J. It's quite a good package that in the meantime has been integrated in the Jakarta Project.

But for the loaded of for instance security related information? Anybody has a solution?

Thnx,

Alef

1. using java.io

Create a simple class to read from the file and provide a set of methods to access the data read from the file. Use this class instead of directly using java.io in your EJBs.

2. Logging

I use my custom loggers; which provide a set of static methods. I haven't used Log4J but did run up a few problems with JLog which uses threads.

Regards,

Arjun

Whats wrong with storing the information in a database rather then in a flat file? Whats the security advantage of a flat file? Doing I/O in a helper class DOES NOT make the I/O legal, just like paying someone to kill a person doesnt make it more legal then killing them yourself.

Can you give us an idea what you are trying to accomplish and we may be able to help you find a legal, safe and well performing way to do it.

Dave Wolf
Internet Applications Division
Sybase

1. We are trying to read certain properties from a file.
2. We are trying to log runtime exceptions.

I don't see any point in using a Database for this. Of course any better ideas are always welcome.

Regards,

Arjun

If you simply need to read properties, why couldnt you use JNDI environment variables? As for logging, why is the containers logging unacceptable?

Dave Wolf
Internet Applications Division
Sybase

The JNDI environment variables seem to be a good solution. I did read one of the earlier threads on this and I guess most of the pros and cons were discussed.

The containers logging doesn't work for us cause 1. we have no access to production boxes; 2. the logging has to be done in particular format to a file which would be integrated with CA Unicenter for production support.

Thanks & Regards,

Arjun

Hi Alef,

I previously posted a soultion to a very similar problem
at
http://theserverside.com/discussion/thread.jsp?thread_id=3437.
Of course my friend Dave, will want to tell you it is "illegal", so I'm telling you this on his behalf, you can also read the arguments there.
Though it is certainly more "illegal" to write files than to read files, so as to what regards the logging stuff, I have to totally agree with you break away with J2EE spec.
After all you have to choose the lesser of the two evils (let's say several evils)
:
  A. use log4j. Chances are more than 90% that the security part of the J2EE spec is not strictly enforced by the app server due to obvious performance limitations. You'll get the job done, but you won't be "portable" (10% chances that your app will not function in other app server).
  B. Use container logging, that is vendor specific packages. You'll be "compliant" with J2EE, but not "portable" as well. Also the vendor logging solutions may not feet your needs.
  C. Provide a solution totally compliant with the J2EE "bible".

     Option c1: According to specs, blueprints and other UFOs we shouldn't use files, instead place all this information into database - log into tables, read config info from tables, eventually some configuration can be put in JNDI entries. You can imagine what a bad design that is.

     Option c2: Isolate your non-portable code, making it run outside the app server, and using RMI or CORBA to call your code for logging, reading information, JNI stuff, and whatever breaks the J2EE bible. This is better design , but of course, it still is overkill from a practical point of view, especially in what regards deployment and production configuration. Log4j does support this solution very well though.

So , these are in general your options, there may be other too.
Hope this helps you.

Its the bad design and overkill that bothers me. Guess I will go ahead and commit a few sins:)) Anyways my code has to run only on a appserver from a single vendor and/or newer versions from them. As long as my stuff works. I'm happy and so is the client.

Thanks Costin for the pointers.

Regards,

Arjun