Now I've got to jump in. I have to side with Rickard somewhat.
Dave, your comments remind me of the "no tolerance" policy at some schools
that suspend students for bringing an aspirin (no drugs) or nail file (no
weapons) to school. Although the intent of the policy is admirable and
needed, each case needs close examination.
Previous threads on this newsgroup have provided instances where static
members and singletons would work perfectly fine in any EJB container
without any problems whatsoever. I think file I/O also can fit in. Yes,
the specs are there for a reason and are designed to prevent the problems
many have discussed with inappropriate use of static members, singletons,
and I/O. But what about those instances where no harm is done and the
developer is perfectly aware of where not to cross the line? Goodness,
should we be looking over our shoulders for the J2EE police?
Better hope you never have an innocent child found guilty due to a rigid
non-tolerant school board. You'd have to tell him/her that it "doesn't mean
its less of a crime".
-Ron
>
> 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".
>
>
===========================================================================
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".
