+1 as well.
Allowing java.io.* is a first step I guess. It will provide more consistency
regarding Servlet at least..
Jean-Louis
2011/9/28 Carlo de Wolf <cdewolf_at_redhat.com>
> **
> 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>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.iopackage 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>
>
>
>