Rickard �berg wrote:
> >Is it correct that a "separate library" or "helper class" means, an
> >installed JAR-File on the app-server?
>
> Correct. That way it would be loaded by the system classloader, and
> since permissions are either granted depending on which classloader they
> use or where they come from this is ok. For jBoss (and I think/hope all
> others behave similarly) all classes loaded by system classloader gets
> all permissions, whereas classes loaded by the EJB classloader only get
> the permissions defined in the EJB spec.
>
> >Therefore I MUST NOT use IO/Threads or something like that AS LONG AS I
> >pack it with the EJB and I MAY use it IF I install the IO library on the
> >app server.
>
> Correct, *AND* that library behaves properly in terms of using
> doPrivileged at the right times. If you call a library that has been
> properly installed in your system, and it throws a SecurityException
> because it does something an EJB may not do, then it is clearly a bug in
> the library.
>
> /Rickard
Rickard,
Hold on there, big guy. It would be helpful if you made it clear that this
is your interpretation of the spec, and that there are different (and conflicting)
interpretations. If I were to answer the above questions, I would say "Incorrect"
and "Incorrect". As I argued previously, how you package your EJBs is not
relevant (whether into a system Jar file, or in an EJB Jar file). The fact that
an AppServer cannot enforce the various requirements on a system Jar file is not
relevant. The rules are the rules (IMO) and you can't subvert them by repackaging
your code (in my reading of the spec, mind you).
In my reading, the only correct way to introduce File I/O, or similar functionality
into an AppServer, is using Sun's Connector architecture (or using JDBC, which is
sort of a poor man's Connector). This specification provides the requisite hooks
for the AppServer and "resource" to cooperate in terms of providing transactional,
security, and pooling capabilities.
Anything less is simply a hack (IMO).
Again, let me point out that Rickard could be right. Or I could be correct. Or
neither. Or both. It is all a matter of interpretation. Caveat emptor.
And now could one of the EJB architects help us all out by disambiguating, please.
-jkw
===========================================================================
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".
