a) sacrifice portability of the bean if the operating system is changed
b) clustering means that the file would need to be networked - JNDI looked up..blah blah blah...
The other problem is that the state of the file, transactionally, is not controlled by the container. Victor Langelo raised the idea of using a jdbc driver to other resource adaptor to provide the I/O access to the files. At least in this case the container would know what was happening. Personally I think that the spec prohibited the file i/o because EJB is so transactionally oriented and thus everyone thinks database. File handling (other than for property reasons) is more batch oriented. If the file is read only then the issue of transactional consistency is moot. Yes you can use file i/o in EJB but via the indirection method that Sourabh mentioned. However it is within the rules for the container vendor to release a new version of their container which did not support the file i/o and you would have absolutely no comeback...
My 2c worth,
Eddie
================================================================
At 12:43 AM 2001-09-29, you wrote:
Hi Sourabh:
Are you proposing the new layer be in a different process (e.g., in a RMI server)? If so, then I agree this solution satisfies the spec.
If you are proposing just a new logical layer (e.g., the bean references another class, which does the file i/o), then it seems to me this still violates the spec.
To Everyone:
As many others have noted, many app servers let you do file i/o, so in practice file i/o can often be done from within an EJB (directly by the bean or indirectly by the bean calling methods in other classes). This seems to indicate that in practice, there is a need for this.
Does anyone know the underlying reasons why the spec prohibits file i/o?
My impression is beans shouldn't access the local file system since such a solution may no longer work if clustering is used (but using a file on a networked drive might get around this), and also beans that make assumptions about the local file system might not be portable. These seem like weak reasons for prohibiting file i/o, however. I'm assuming there must be better reasons I haven't thought of.
Laurel
- -----Original Message-----
- From: Sourabh Ahuja [mailto:[EMAIL PROTECTED]]
- Sent: Thursday, September 27, 2001 11:28 PM
- To: [EMAIL PROTECTED]
- Subject: Re: EJB File I/O question
- Hi
- Introduce one more layer between your EJB and DB or file. Your EJB will call the write methods of that layer and those methods will be responsible for writing it to the file. In Short
- EJB( call write methods on the new Layer) -------> New Layer ( Contains methods for openning the streams for writing) ---------> Final file.
- Cheers,
- Sourabh
- -----Original Message-----
- From: Dinesh Sharma [mailto:[EMAIL PROTECTED]]
- Sent: Thursday, September 27, 2001 7:46 PM
- To: [EMAIL PROTECTED]
- Subject: EJB File I/O question
- Hello all,
- Am currently working on an application, which requires writing to a file, everytime some data is retrieved from the DB. It is a daily process, and the first transaction is a write, and then all the subsequent trasactions are appended to the file. I learnt that EJB specification 1.1 forbids "developers" from using the java.io.* package for doing file I/O. Is anyone aware of any alternative method/pattern or a stable workaround to around this? Thank you for your time in advance.
- I could compile a list of all the messages I receive and send it back to the list.
- Best,
- Dinesh
