Here here. I think of it this way. Its illegal for me to commit a crime.
It is also just as illegal for me to convince someone to commit that crime
on my behalf. To me repackaing an illegal act into a helper class is just
as illegal an call. The vast majority of these requirements are set for
WORA reasons. For instance,
No static members (containers may use multiple vm's)
No singletons (containers may use ClassLoaders)
No File I/O (Underlying OS may have no file system)
Moving into libraries affects none of these WORA issues. You can say, well,
I can rewrite the helper classes, but this ISNT WORA. Heck, I can rewrite
my C++ code too.
As well, no one says the police have to watch every move I make to prevent
me from commiting a crime, but eventually the odds are Ill be punished for
it. Can you commit a crime and get away with it (file I/O)? Yup. Doesnt
mean its less of a crime.
Dave Wolf
Internet Applications Division
Sybase
----- Original Message -----
From: "Jonathan Weedon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 07, 2000 1:49 PM
Subject: Re: Writing files with EJBs
> 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".
>
>
===========================================================================
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".
