Rickard Oberg wrote:
>
> Ian McCallion wrote:
> >
> > 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. ;-)
It's the other way round. Once you've decided which pieces of code belong in an
EJB (for "EJB" in this context, read "component" - as it doesn't matter whether
the code groups are EJBs or not) then we can decide whether and how to use the
tools at our disposal for enforcing the groupings. Small projects will probably
not use the tools and will rely on the self-discipline of the programmers. Large
projects will (should) set up separate protection domains for each part of the
project.
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".
