And quickly, before anyone jumps in and says "but I want to do it myself,
and I want to do it as a library (or whatever)", let me respond: fine.
The point here is not to say what the AppServer should or should not let
you do. We don't enforce these rules, and neither do most other products
(and as Rickard points out, in some cases enforcement is not even possible).
I am not saying what to do, or not to do. I am just trying to explain
the rules as I understand them. Follow them, or not, at your discretion.
-jkw
"Jonathan K. Weedon" wrote:
>
> 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".
