In my opinion, for this EG it goes too far.
I'm assuming that we would also allow java.nio(.file) enhancements from
http://download.oracle.com/javase/7/docs/technotes/guides/io/enhancements.html
Carlo
On 09/28/2011 09:19 AM, Antonio Goncalves wrote:
> Or could we go further ? In this era of cloud, distribution and so on,
> why not create a file system layer that could be used by the entire
> platform (EJB, servlets...) in a distributed way ? JCR goes too far
> because it can use several storage systems, have versionning and so
> on. What we would like if to be able to read/write on the file system
> in an abstract way. Would that be too much ?
>
> Antonio
>
> On Mon, Sep 26, 2011 at 02:04, David Blevins <david.blevins_at_gmail.com
> <mailto:david.blevins_at_gmail.com>> wrote:
>
> I've always disliked this restriction and would love to see the
> language reduced to that of a recommendation or caution and not
> phrased as a rule.
>
> People say the most ridiculous things about this, such as "i need
> to access the file system but I can't do that with an EJB so we're
> using a Servlet instead." You try and explain that running that
> there is zero difference as both models are practically identical;
> same resource environment, both have passivation/clustering
> concerns, container callbacks (events), asynch support, etc. As
> well, nowadays you have everything in the .war file. Does that
> make it suddenly safe for EJBs to access the file system or now
> suddenly unsafe for Servlets to do so? What if we have a CDI bean
> that accesses the file system, is it safe for a Servlet to call
> it, but not safe for an EJB to call it?
>
> Bottom line, unless there is just one user on your server the file
> access will potentially be multi-threaded regardless of what you
> choose to call the component.
>
> The EJB EG has in the past been more conservative than the Servlet
> EG when it comes to the same concept and situations where it was
> perceived users could hurt themselves. Files are not
> transactional and that's likely the thing that tipped them onto
> the forbidden list on the EJB side.
>
> It would actually be really great to see some clarification of
> this historical "no-no" at the platform level. The file system is
> simply an unmanaged resource that should be used with great care.
>
>
> -David
>
> On Sep 25, 2011, at 12:08 PM, 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 <http://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 <http://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 <http://javai.io> package within
> the EJBContainer and the java.io <http://java.io> package in a
> running environment.
> >
> > Any thoughts ?
> >
> > --
> > Antonio Goncalves
> > Software architect and Java Champion
> >
> > Web site | Twitter | Blog | LinkedIn | Paris JUG
>
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | Blog
> <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Paris JUG <http://www.parisjug.org>