Hi Antonio,
+1 for the recommendation instead of restriction.
But: then EJB will be less "cloud-friendly". Not being able to access local resources is a popular restriction across all cloud providers.
cheers!,
adam
On 25.09.2011, at 21:08, Antonio Goncalves wrote:
> Hi all,
>
> I have on concern about EJBs not being allowed to use files. Under section 16.2.2- Programming Restrictions, you can read :
>
> "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."
>
> But in projects, I see that all the time : EJBs reading and writing files. I haven't tried all the containers but I really wonder if this restriction is really taken into account. With the new EJBContainer, the nicer EJBTimer and asynchronous calls we could think EJBs are the perfect match for batch processing... but there is the java.io package restriction.
>
> Is this restriction too hard ? Could we smooth it ? I can understand that accessing files in a distributed environment without a shared disk is problematic, but why don't we encourage batch processing with embedded EJBContainer ? We could maybe do some distinction between javai.io package within the EJBContainer and the java.io package in a running environment.
>
> Any thoughts ?
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site | Twitter | Blog | LinkedIn | Paris JUG