+1
On 9/28/2011 5:43 AM, Carlo de Wolf wrote:
> 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>
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2012.0.1809 / Virus Database: 2085/4523 - Release Date: 09/27/11
>