Absolutely (wrt boot delegation)! It would be great if we could ship frameworks with no boot delegation (other than the implicit java.*). As you say, there are pragmatic concerns. An earlier observation about tooling was quite apt IMHO. I've never been a fan of solutions that require/rely on tooling but tools certainly can improve life. In this case things like Mangen really are the way to go. This is independent of the boot delegation setting. You can't rely on strict boot delegation settings because all it takes is one bundle in the system that really needs * and the problems in the other bundles are masked. It is a better strategy to produce correct bundles in the first place.
Can you clarify the spec point? . Jeff Peter Kriens <[EMAIL PROTECTED]> 04/14/2006 03:01 AM Please respond to [email protected] To Jeff McAffer/Ottawa/[EMAIL PROTECTED] cc [email protected] Subject Re[4]: Fixed bug in class loading I believe people are convinced they need special solutions and there is a very big chance they do. However, it is hard for me to understand (and learn) if I am confronted with a solution while the (exceptional) problems seem solvable with the existing mechanisms. For example, Richard could have easily caved in with the demand for boot path delegation * but we found that the manifest was wrong ... Allowing * delegation solves some short term problems because you get less errors but they inevitably create bigger problems down the line because the manifest is just wrong. I know that in a production environment you sometimes have to do dirty things to make things work. However, from a spec point of view I think it is important to remain pure because pollution and bloat is the greatest threat to a spec. Kind regards, Peter Kriens JM> To a certain degree we are off in the weeds here. All I am saying is that JM> there exist usecases where you cannot wrap or modify. I'm not saying they JM> are right, valid, desireable or anything other than real. The folks with JM> the usecases really really were not able to take those options. JM> Peter Kriens <[EMAIL PROTECTED]> wrote on 04/13/2006 03:05:51 PM: >> JM> - Updates also will force you to retweak. >> Yes, but that is true for any solution that requires additional >> metadata. JM> Point of interest: If the metadata is separate then, depending on the JM> change, it may not need updating. >> JM> - If the JARs are delivered as part of something else you may not JM> have a >> JM> chance to modify >> But if you need to provide new metadata, you need to do something?? JM> Only if things changed in interesting ways. If it was just a bug fix for JM> example, you might not have to. >> JM> - User permissions on the machine may not allow for modification (we JM> have >> JM> scenarios where we run off CDs and don't use any local storage) >> Well, then you can't support native code, getDataFile(), caching, how >> many bundles run in such a restricted env? JM> We have preinitializers that run and extract/cache the various files that JM> must be extracted to run (e.g., dlls, ...). None of our bundles use JM> getDataFile(). Many of our bundles are able to function (perhaps with JM> diminished capabilities) in environments that do not support writing. Even JM> getDataFile is spec'd to return null if data files are not supported. JM> Jeff -- Peter Kriens Tel +33870447986 9C, Avenue St. Drézéry AOL,Yahoo: pkriens 34160 Beaulieu, France ICQ 255570717 Skype pkriens Fax +1 8153772599
