> Rickard �berg wrote:
> >
> > But we're then back to the (seemingly eternal) question:
> > if a bean uses a JDBC connection, is that JDBC driver considered part of
> > the bean? If not, what is the differentiating factor that makes it *not*
> > part of the bean? Is it the classloader? Is it the protection domain? Is
> > it the interface it is implementing? Or what?
> >
> > Thoughts? :-)
>
> It seems to me that this is not a technical issue but a management one. if
you
> manage a piece of code as though it is part of the EJB that uses it (as
you
> would tend to do for a class implementing a dependent object) then it is
part of
> the EJB. It you manage it as a separate item (as you would tend to do for
a JDBC
> driver - where "management" consists of obtaining, remaining current on
and
> getting support on code written by someone else) then its not part of the
EJB.
> Other "helper classes" could be one or the other depending on how you
organise
> your development and support of the application.
Correct, but irrelevant. Can you please translate the above into an
expression that tells whether a given I/O operation will throw a security
exception or not? Coz that's all that matters.
> Technical features such as class loaders snd protection domains are merely
> tools.
Correct, but oh so very important in determining the above. ;-)
/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".
