On Fri, 7 Jul 2000 10:05:51 -0400, Laird Nelson
<[EMAIL PROTECTED]> wrote:
>> If they are
>> loaded by any other
>> classloader they are free to do whatever they want, as long as they obey
>> the standard rules of
>> the security API framework (i.e. use doPrivileged blocks appropriately).
>
>(Which I'm still having trouble grokking; my homework.)
Yes, there is a certain amount of pain associated with taking the red
pill. ;-) No shortcuts AFAIK.
>> As above: if Frobnicator is loaded as a part of the component -> no
>> threads may be created. If it
>> is not created as part of the component -> any number of threads may be
>> created.
>
>Good. Thanks for the explicit answer. So this rules out an
>interface-driver approach, kinda: that is, if I want the guts of my
>stateless session bean to actually be implemented by a "driver" that
>conforms to that session bean's interfaces, and if the driver is
>supplied by a third party, then I must call the tech. support department
>of the vendor of that product and determine from them whether or not
>their product uses threads or file I/O (or, I suppose, I could load
>their product up and see if the SecurityManager barfs... :-)).
Nope. All you need to determine is if their driver implementation plays
nice and does doPrivileged at appropriate times.
And if it doesn't you could easily add a layer on top of their driver
which always does it on all calls. A bit of extra code, which could
easily be automatically generated.
>...and assume that an instance of ComplicatedDriver is loaded. I'd like
>to have bits of my session or entity beans pluggable so that my project
>can take advantage of competing third-party products that provide some
>of this functionality already. It looks like if any of these products
>use threads I have to ensure that they're loaded by a different
>classloader and available (via JNDI, I guess?) to my beans instead of
>simply creating new instances of them and loading them up via the
>context class loader.
No, using "new" would work just fine *as long as the classloader being
used to load the driver implementation is NOT the EJB-classloader*.
I would suggest that you add the JDK 1.2 classloader delegation model to
your list of homework. :-)
Brief explanation:
If you do "new" you will use the classloader of the current objects
class. If this classloader is the EJB-classloader (which is the case if
the object doing "new" is an EJB), then two things can happen:
1) If the driver implementation is a part of the EJB then the
EJB-classloader is used
2) If the driver implementation is NOT a part of the EJB then the
EJB-classloader will delegate to its parent classloader, which is
typically the system classloader (or similar), which loads the class
without the restricted set of permission.
It doesn't matter *who* does "new". The ONLY thing that matters is
*which classloader* is used to load the class being instantiated.
> Or, more briefly:
>
> Implementations of interfaces that could be provided by unknown
>vendors must be loaded by a non-EJB classloader.
Exactly. Which is trivial if you simply:
1) Don't package the implementation with your EJB (i.e. don't put it in
the EJB-jar)
2) Add it to the system classpath or similar
Let the classloader delegation model do the rest.
>
>> Does this answer your query? If it does not I suggest that you:
>> 1) Check the archives
>> 2) Read up on the Security API framework (java.sun.com/security I think)
>
>#2 is definitely on the list (again).
Indeed. And if memory serves me right I told you to do this ages ago.
;-)
regards,
Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
===========================================================================
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".
