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.
Technical features such as class loaders snd protection domains are merely
tools.
Ian McCallion
Alexis Systems Limited
===========================================================================
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".
