Hmm, sorry to say so, but...I think you actually are off-track... The reasons for the restrictions of file-I/O, threading, etc. is not there primarily because of security. They are there primarly because of resource-management and redundance. Or rather, giving the ejb-server-developer the freedom of implementing these features. The restriction for accessing static-fields is based upon the fact that "thou shalt not make any assumptions on which virtual machine your running". The ejb-server can choose to move you from one VM to the other at any time (probably not _in_ method-call, but close). Pretty much the same goes for using simple file-I/O. One cannot assume what actual server (and thus filesystem) you are on right now. You could actually be deactivated and reactivated from different host at any time (even, for example, from NT to Solaris). There are safe ways of using static-fields when implementing various kinds of caches and pools of resources, but is not recommended because of the other reason for these restrictions, namely resource-management. "Thou shalt not create thy own threads, thou shalt use the threads from the grand EJB-servers heavenly pools.", for example. The resources should be managed by the EJB-server and not by the bean itself. One reason is of course performance, the other reason is transaction-integrity, accessing a file will not be transactional and will thus break the ACID transactional-properties. Different J2EE-implementations uses these features (the bean-provider sees them as restrictions, the J2EE-implementor sees them as features :) at various degree. For example, WebLogic (if not using the clustering option) uses only one VM on one machine and it will therefor be safe to use File-I/O under WebLogic, this goes for Orion Server as well. Gemstone/J on the other hand is heavily clustered starting up some 5-10 VM's immediately at startup, on one host or on several, under Gemstone/J File-I/O is definitely not safe. Jon Tirs�n Chief Architect Itec Open Business Integrator AB PGP key lookup: http://certserver.pgp.com:11371/pks/lookup?op=get&search=0xE9032B9A > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg > Sent: Tuesday, November 30, 1999 12:36 PM > To: [EMAIL PROTECTED] > Subject: Re: EJB-Resource Bundles and I/O > > > Hey > > Alain Rogister wrote: > > > Generally speaking, I would not do this. Instead I would package this > > > kind of functionality in a separate library that is available to the > > > beans, but not through the classpath of the EJB-jar, but > rather through > > > the system classloader or similar. As has been noted in earlier posts, > > > the classloader is the key to avoiding the restrictions of EJB. > > > > I remember you've explained in earlier threads that the classloader was > > the key, but I couldn't ever find any confirmation of this either in the > > EJB spec or from the spec's authors. Could you please provide us with > > the source of your explanation ? > > Ok. The EJB restrictions rely on the Java2 Security API, which is based > on the concept of Permissions. So, to understand the restrictions, and > how to "avoid" them you need to understand that API first. This is not > trivial, and has taken me lots and lots of time to digest. The biggest > reason I looked this up in the first place is because I'm currently > implementing mobile agents on top of J2EE (really cool, and works well > too), which introduces a lot, no make that *A LOT*, of security issues. > Anyway, Permissions are given to classes by creating Policy objects, and > the default implementation is one that reads the > /lib/security/java.policy file. It would be a good idea for you to look > in it at this point. > > Done? > > As you can see there are a number of "grant" statements. The key to > getting around the EJB restrictions is to grant the permission that you > need, for example file I/O, to the classes doing the actual I/O. One way > to do this, as you can see in the policy file, is to simply put them in > the /lib/ext dir, as they will then be given the AllPermission > permission, which lets them do anything. > > This is where the classloaders come in. If a classloader loads the > classes from a place which has been granted the necessery Permissions, > through the Policy, then those classes may be used by EJB's (which do > not have those Permissions as they were loaded from elsewhere) and > perform any nasty tasks such as socket usage, file I/O or similar. > > But simply having the permission is not enough. Oh no, the security > permission checks are much tougher than that. They will check so that > *every class* in the stack has the needed permission. So even if the > class that does the call has a needed permission, it might be used by a > class that do not, and hence the security check will fail and throw a > SecurityException. > > This is where the doPrivileged actions come into play. You see the > security check looks at all classes on the call stack to see that > everyone has the required permissions, *unless* it encounters a > doPrivileged use, in which case it stops the check and permits the > desired action (provided that all classes up until the doPrivileged call > are ok). Hence, even if the class that invoked the class that used > doPrivileged does not have the required permission, the operation will > pass without error. > > And that's the whole story, or as close to it that I know.... *phew* R U > with me? :-) > > Conclusion: > Wanna use I/O or other restricted operations? > * Put those calls in a separate "library" class > * Wrap "dangerous" sections in doPrivileged calls > * Package the classes separately > * Put the library on the classpath somewhere, so that the server can > access the classes > * Grant the desired permissions (AllPermission works well :-) to the > library > * Call the library from your EJB's > > Or: > * Turn off security checks in the EJB-server if possible... not > recommended... > > Disclaimer: > As always, I'm a theoretical kind of guy so all of the above are only > logical deductions from the tons of documentation that I've read: I have > not tested any of it in practice, so it might be completely off track. > > /Rickard > > ps. Is it time for a EJB-INTEREST FAQ soon? >:-) > > -- > Rickard �berg > > @home: +46 13 177937 > Email: [EMAIL PROTECTED] > Homepage: http://www-und.ida.liu.se/~ricob684 > > ================================================================== > ========= > 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". >
BEGIN:VCARD VERSION:2.1 N:Tirs�n;Jon;;; FN:Jon Tirs�n ORG:Itec; TITLE:Chief Architect TEL;WORK;VOICE:+46 (8) 343431 TEL;CELL;VOICE:+46 (709) 306109 TEL;WORK;FAX:+46 (8) 343438 ADR;WORK:;;Box 23049;Stockholm;;104 35;Sweden LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Box 23049=0D=0AStockholm 104 35=0D=0ASweden ADR;POSTAL:;;Ynglingagatan 17;Stockholm;;104 35;Sweden LABEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Ynglingagatan 17=0D=0AStockholm, 104 35=0D=0ASweden URL: URL:http://www.itec.se EMAIL;PREF;INTERNET:[EMAIL PROTECTED] EMAIL;INTERNET:[EMAIL PROTECTED] REV:19990417T134712Z END:VCARD
