Rickard,
I see this as a slippery slope. On the one hand, there is clearly the
opportunity to write a utility library, and to install that as part of
the "system", and thereby side-step the restrictions indicated in the
EJB specification. As you say, this is what JDBC drivers do.
But where does one draw the line? I have heard some people say that
the restrictions about what I can do in EJB only apply to the class
listed as the bean implementation class in the deployment descriptor.
So, I can do File I/O in a base class, or in a delegate, right? Well,
no. To me, a base class or a delegate object are still part of the
EJB.
For example, I have been debating with some engineers at Sun whether
it is valid to put SQL code into a data-access-object when using
CMP. They argue that the DAO is not part of the CMP bean. I argue
that the DAO is just a way of organizing (and possibly reusing) code,
and is therefore part of your CMP bean, and therefore should not
contain direct SQL code.
As I said, where to draw the line?
I would be curious to see anything definitive that drew the line between
what is part of an "object" and what is an external "library". In Java,
they all seem the same to me, modulo packaging issues.
-jkw
Rickard Oberg wrote:
>
> On Mon, 6 Nov 2000 11:23:02 -0800, Larry Liu <[EMAIL PROTECTED]> wrote:
> >It is well known statement quoted by your mail. Do you
> >think the move of the IO work to Web tier instead of the
> >EJB tire is the way out?
>
> I have already given a solution to how to do file I/O through EJB's, but
> here we go again. This seems to be hard for people to understand.
>
> There is Absolutely Nothing(tm) that prevent you from putting all the file
> I/O into a separate library which your EJB's then access. Period.
>
> Are these classes not covered by the EJB restrictions? No, not if they are
> considered part of the system.
>
> How do I make them part of the system? By installing them in the servers
> classpath, or as an installed extension in the lib/ext directory in the
> JRE/JDK.
>
> So, why does this work? Because the permission restrictions will not apply
> to system loaded classes. For example, the server itself is allowed to do
> file I/O, as do JDBC drivers etc. This would be no different.
>
> And it would just work? Almost. You need to wrap all dangerous code blocks
> in your library class with doPrivileged calls. For more information on this
> please see the security framework documentation at java.sun.com/security, or
> check the archives of this mailing list for posts on this topic by Rickard
> Oberg (i.e. me) covering the ins and outs of permissions, grants, call stack
> security checkings etc.
>
> /Rickard
>
> ===========================================================================
> 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".
