+1
On 09/27/2011 08:28 AM, Stefan Heldt wrote:
> +1
>
> -----Ursprüngliche Nachricht-----
> Von: Richard [mailto:richardhightower_at_gmail.com]
> Gesendet: Montag, 26. September 2011 19:52
> An: jsr345-experts_at_ejb-spec.java.net
> Betreff: [jsr345-experts] Re: java.io.File
>
> +1
>
> Sent from my iPad
>
> On Sep 26, 2011, at 5:31 AM, Reza Rahman<reza_rahman_at_lycos.com> wrote:
>
>> +1
>>
>> On 9/25/2011 8:04 PM, David Blevins 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
>>>
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2012.0.1809 / Virus Database: 2085/4519 - Release Date: 09/25/11
>>>
>>>
>>>