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>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 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
>
>
>
--
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>