I would disagree with the assessment that getResourceAsStream() relies
on java.io.FilePermission. If you were to say that, then why shouldn't
the following cause a permission violation:
new Foo();
Class.forName("foo.Bar");
The "resource" mechanism uses a classloader, just like loading a class
through new or Class.forName. It is not up to the programmer to dictate
how the classloader does its job (be it files, socket, database, etc.).
The classloader should make available the class and resource files under
its control.
$.02
-eric
James Cook wrote:
>
> The spec I'm looking at, "1.1 final" has no mention of either getResource()
> method, so it certainly does not specifically "allow" this method.
>
> In fact, if one was to infer, the spec will prohibit this action. The
> getResource() methods rely on java.io.FilePermission which the spec states
> should be set to "deny". BTW, these are Java 1.2 permissions, but I think
> most servers are already based on 1.2.
>
> jim
>
> ----- Original Message -----
> From: Emmanuel Pirsch <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, February 15, 2000 10:13 AM
> Subject: Re: EJB restrictions and Class.getResourceAsStream()
>
> Resource access with Class.getResource() and
> Class.getResourceAsStream() are allowed by the specification. They go
> through the ClassLoader and the EJB server can easily handle this.
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
