On Mon, 6 Nov 2000 12:55:14 -0800, Jonathan Weedon <[EMAIL PROTECTED]>
wrote:
>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.
Exactly.
>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.
Exactly. To me as a container implementor it boils down to which classloader
is used to load the class, and I think this is the right way to approach it:
if it is part of the component or application it is largely untrusted, and
if it is part of the system it is trusted. I always think of how it would
work in a webhotel situation where the sysadmin != app developer. In that
case the sysadmin definitely wants to restrict what the components can do
without having to ask for specific permissions to do more.
>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.
Hm.. don't quite follow. The DAO class would still be loaded by the EJB
classloader and thus be affected by the EJB restrictions. As you say.
Again, I think using the webhotel metaphor makes it easier to determine what
should be allowed and what should not be allowed.
>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.
And they are. The packaging *is* the holy grail IMNSHO.
To me there are two main reasons where the restrictions are useful:
1) If it's an EJB it is portable. Period. No "well, if it does this or that
it needs.." crap. By refactoring everything that would be potentially
dangerous to external libraries we have the simple rule that EJB's
themselves are always portable.
2) For actual security reasons in a webhotel scenario where the hosting
party and the application party are not the same.
This is the mindset that is useful IMO when thinking about these things.
Would you agree?
/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".
