Restriction on the usage of File IO APIs? I think it would be a benefit to the platform to have the EE spec. require an impl. of a JCA Adapter for flat files.
-Noah
On Nov 9, 2011, at 1:53 PM, Marina Vatkina wrote:
> EJB 3.2 will have this restriction removed.
>
> -marina
>
> Laird Nelson wrote:
>> Hello; I've been having a very interesting conversation with Jean-Louis Monteiro over on Twitter (http://twitter.com/chuggid). It centers on the interaction between the EJB and Java EE 6 specifications in the area of classloading and what the two specifications permit and deny. Since Glassfish is the reference implementation for both specifications I wanted to ask some of the questions here.
>>
>> Briefly: I want to read a resource on the classpath from library code used by an EJB's business method. May I?
>>
>> The EJB specification as everyone knows goes to great length to prohibit file access. I understand that. Such IO is not transactional or "cloud friendly". But it seems to tread very carefully in the area of ClassLoader#getResource(String). Despite being very clear about what is prohibited, it does not single out this very common operation as one that is prohibited.
>>
>> Section 21.2.2 says, among other things, this:
>>
>> * An enterprise bean must not use the java.io <http://java.io>
>> package to attempt to access files and directories in the
>> file system.
>>
>> (Bullet point #4, numbered starting with 1.)
>>
>> That's fine; I'm not interested in using java.io <http://java.io> to access files and directories.
>>
>> Then it says this:
>>
>> * The enterprise bean must not attempt to directly read or
>> write a file descriptor.
>>
>> (Bullet point #10.)
>>
>> That's fine; I'm not doing that either.
>>
>> But it also says this:
>>
>> * The enterprise bean must not attempt to create a class
>> loader; /obtain the current class loader/; set the context
>> class loader; set security manager; create a new security
>> manager; stop the JVM; or change the input, output, and
>> error streams.
>>
>> Note the "obtain the current class loader" bit. I am assuming that the "current class loader" is /not/ the ClassLoader returned by Thread.currentThread().getContextClassLoader(), but is, instead, the ClassLoader that is returned by this.getClass().getClassLoader(). In any event this seemed kind of surprising. I would appreciate clarification here. May I really not call getClass().getClassLoader() from within an EJB?
>>
>> Then I read the EE 6 specification, section EE.6.2.4.7:
>>
>> This specification requires that Java EE containers provide a per
>> thread context class loader for the use of system or library
>> classes in dynamically loading classes provided by the
>> application. The EJB specification requires that all EJB client
>> containers provide a per thread context class loader for
>> dynamically loading system value classes. The per thread context
>> class loader is accessed using the Thread method
>> getContextClassLoader. [...]
>>
>>
>> So that seems like I should be able to get the context ClassLoader in this fashion just fine.
>>
>> Then section EE.8.2.5 says:
>>
>> ...libraries that need to dynamically load classes that have been
>> provided as a part of the application need to use the context
>> class loader to load the classes. Access to the context class
>> loader requires RuntimePermission(“getClassLoader”), which is not
>> normally granted to applications, but should be granted to
>> libraries that need to dynamically load classes. Libraries can use
>> a method such as the following to assert their privilege when
>> accessing the context class loader.
>>
>>
>> So that sounds like in a Java EE 6 application it should be legal to obtain a ClassLoader via Thread.currentThread().getContextClassLoader(), and--reading the Java EJB specification section 21.2.2 very carefully--legal to call getResourceAsStream() on it, provided that--again, conforming to the EE specification--my library actually doing this resource access has been granted the appropriate RuntimePermission and has performed the class load as a privileged action.
>>
>> Is that correct?
>>
>> Best,
>> Laird
>>
>> --
>> http://about.me/lairdnelson
>>