EJB and Filesystem

[pants]

The EJB spec (1.1 and 2.0) states that...

"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."

This is fine most of the time, you just load files from the classpath...but...sometimes you REALLY need to access files in the file system. (e.g. An API that expects a config file as a parameter).

Is there a recommended way to deal with this issue in JBoss? (Should I just ignore the EJB spec?).

Thanks in advance.

[raja05]

AFAIU, the reason why the spec dictates that is because any changes made to external file system will not obey transactional properties. For e.g. if the app writes to a file and then the Tx is rolled back, there is no way to undo changes to teh file Automatically by the ejb container..
I guess its okay to override that and use the file system. Hey, if you are using a logging mechanism from ur EJBs, you break the ejb contract at that point ;-)

-Raj

[adrian.brock]

And File IO is a blocking operation.

At least with log4j you can configure
aynchronous logging.

I don't think you need transactional logging,
how would you log a transaction rollback? :-)

Regards,
Adrian

[stephenrbenson]

Transactional behaviour is not an issue here.

pants is describing a situation I'm dealing with -- where 3rd party java (DataCash credit card gateway) insists on accessing filesystem based resources, in particular binary files containing card information (bin ranges etc to work out what bankk/country issued a card). We have no control over how this accesses these two files; it insists on a filesystem based path location like "C://Java//DataCash-Java-2.0.10//cardinfo".

Just feeding it a package location doesn't work, nor has using the classloader to point to the actual location to derive something like: "jar:file:/C:/Java/jboss-3.0.4/server/betex/tmp/deploy/blahblah/blah.ear/81.blah/blah.jar!/com/ourpackage/blah/blah" (even if I strip off the jar:file:/ bit)

All we know about the client code is that the reference to the file is initialised using the File(String pathname) constructor of the java.io.File object.

I'm currently looking at the jakarta commons VFS package for a solution, but without success so far (I have an odd compilation issue to resolve).

So any tips/pointers greatly appreciated.

[pants]

So.....after asking around a bit...

The spec seems to be more of guide than a hard and fast rule. Sometimes you need to the ability to read files.

You just need to bear in mind that you won't get transactional behaviour, nor will your application scale if you need to read some huge file every time a bean gets called.