Actually Ron, I agree. Which was my point that I dont think the container
should be stepping in here and enforcing this. A rule is a rule. Break it,
and you may get away with it. Doesnt make it less of a rule however. Now,
when you dont get away with it however, you dont have anyone to whine to.
You broke a rule.
But, I do NOT think in most cases, such as File I/O it is the job of the
container to enforce this. Back to the school analgy. The school might
have metal detectors to check for guns, a serious rule which affects over
all stability of a system. I would see re-entrant calls in this way. And
containers should step in here. But File I/O is as you say, not alot worse
in many cases then a nail file in school. Shoudl they search every kid?
Absolutely not. Should the app server enforce this? In my personal
opinion, no.
But Ron, if the kid falls down, and gets stabbed by their own nail file, it
tragic, but thats why the rule existed.
I know Im stepping into a grey area, but isnt that what a baord like this is
about?
Dave Wolf
Internet Applications Division
Sybase
Its a fine line. Back to the school analagy.
----- Original Message -----
From: "Ron Yust" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 07, 2000 2:34 PM
Subject: Re: Writing files with EJBs
> 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".
>
>
===========================================================================
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".
