The EJB spec says that enterprise beans are not allowed to access files through java.io. So what is the design pattern that is usually applied when an EJB has to read/write from/to a file? (I do NOT use a database)
Is a J2EE Connector (for files) something you would implement?
Is there such a thing as "file connection pooling" to avoid
opening/closing of files? (I don't know if this question makes any sense!)
The 'legal' way to do this would be
1) To use a JDBC driver that wrote to a file or
2) To use a JCA adapter that wrote to a file.
I dont know of either one existing but they couldnt be hard to write (esp the JDBC driver). Many people just screw the restriction and do the file I/O anyways. Another option is to read/write to a singleton but thats not persistant.
The question is why doesn't the EJB spec allow you to use Java i/o? Few reasons really,
1) Resource Management - It's the containers problem to manage the concurrency on the resource.
2) Location independence - If you connect to one server and write a file the next time you, for instance, call a stateless session bean to read from that file it could well be a different file. You want the appserver or database server to worry about replication, can't do that if it's a file.
conclusion: If you still don't mind writing non location independent code to access unmanaged resource just write the code, the approach of writing a JCA sounds the best to me though.
The blanket ban on the file system that the EJB specification proffers has always seemed artificial to me. Let's take a look at Max's both arguments, i.e., resource management and location independence.
1) Resource management. This is certainly important to get correct, because cluster-wide access is unpredictable, and you possibly wouldn't like to code concurrency management code yourself. However, there is a certain class of file that needs almost no concurrency management at all: the static read-only file. This is typically read in once and then refreshed periodically. Many applications can open the same file in the read-only mode simultaneously, so concurrency problems are pretty much nonexistent: when you want to update the file, just try to overwrite it with another file until the operation succeeds (no read locks are held).
2) Location independence. This is also important, but given that networked file systems exist, and that for static read-only data such file systems are quite sufficient, you can put your property file (or whatever) on a shared disk; it thus becomes location-independent.
Indeed, taking into account the cumbersomeness of XML as a property file format for simple property files, I have found it preferable to use simple Java property files for simple configurations. Similarly for static XML files and XSL stylesheets, etc., etc. Just make sure that you're only reading data, not writing it, because otherwise you'll be confronting the transactional problems that EJB designers apparently had in mind when introducing the blanket ban on the file system.
In light of these points, and the fact that many people choose to use the file system anyway, it is not surprising, then, that to my knowledge no container bans (through Java Security) the use of the file system in EJBs.