As I understand the problem(s), it really comes down to the container is not managing these resources for you. Guess what: regardless of what technology you use, JMS Queues or what-have-you, it does not get around it. And I might add, all of the options you threw out were mentioned in our team meetings.

I’ve seen some creative ways to get around this that I’m not sure are any better. One project someone had wrote a java client that connected to a Queue and processed a ReadFile message by writing the file back to another JMS Queue/Topic. Essentially it was an MDB but ran outside of the container. The same thing could probably be accomplished with Spring’s new JMS Listener beans (name escapes me).

I’ve also seen people use a DAO-type object to read/write to the file. But I don’t think this technically gets around the EJB restriction, since the DAO is still called from within the EJB.

So I totally agree that this is a shady area in the spec that nobody seems to have a solid solution to, but the JCA idea sounds promising. I believe that WLS 9.0 will have a MDB-type bean that can watch a file or directory for changes instead of a JMS Queue, which would work for us in many cases…

As for transactional support, it makes sense to use the JCA when you need to make sure things are properly handled in that scenario. But in my case, all I am doing is reading files from another server/service and storing them in my database. The transactional piece is taken care of by the JDBC layer, for which, I might add, I will need to use an java.io.InputStream to get my binary content into the system…

I would also like to point out that portability is generally not an issue for the enterprise applications developer. We are running WebLogic (sorry) and there is nothing on the road map that indicates this will change. If it does, things will break. Part of the problem with portability in the J2EE spec is that J2EE is designed to allow vendors to provide extensions, which breaks portability. So, I feel that portability is a poor arguement for this situation.

Also, I have never seen, on all the seven or so OS’s and the 4 or 5 containers I have worked in, a problem specifically with java.io. Sure, there have been Socket issues, and there is always the damned threading issues, but not specifically java.io issues.

The “spec” portable and correct way to say open up a socket, read/write a file, etc is to create a JCA component. A JCA component has a portable way of defining “work” and the underlying transactional semantics of that work. Again there are some rhymes and reasons (and even counterarguments) for this, such as lets say you write a file, then attemt to send a JMS message “file written name”+name but the JMS server is down (must not be using JBoss ) and so the transaction roles back but now you have a file sitting around that no one knows about (that you would like to have “never written” or “undo” aka “delete”). A JCA component gets proper notification. A counter argument to this is the ability to use the SessionSyncronization (SFSB) to pull this off.

However, a rule of thumb is that the core spec tries to draw a line between the system and application programmer (one of those lines is resource management), and favors portability in some places over empowerment. stateless session beans are REALLY inapporpriate for threading (cause they are pooled any your lock on any given instance is method invocation long), and um putting that in an “entity” would probably be pretty ill advised. If you’re willing to step outside the spec a little and are in JBoss’s EJB3 container (which there is probably pretty close to a 1 in 3 chance that this is the case) then you could use ServiceBeans. Service Beans essentially have the same thread model as a default thread model servlet (all threads by same instance…). They look smell and feel like SLSBs and you can also give them an MBean name (they are a little fatter than model JMX MBeans). Same annotation semantics, etc. MBeans have tradtionally been how a lot of people did potentially non-portable code in JBoss that they wanted to control (for instance). This is really a revision of that.

So use good judgement and do what makes sense for your app. Also I strongly suspect the nio was just a cut and paste error. I don’t know if it can be corrected at this stage, but I’ll mention it.