You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Peter Kriens <Pe...@aQute.se> on 2006/04/14 09:01:49 UTC
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 <Pe...@aQute.se> 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
Re: Re[4]: Fixed bug in class loading
Posted by Jeff McAffer <Je...@ca.ibm.com>.
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 <Pe...@aQute.se>
04/14/2006 03:01 AM
Please respond to
felix-dev@incubator.apache.org
To
Jeff McAffer/Ottawa/IBM@IBMCA
cc
felix-dev@incubator.apache.org
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 <Pe...@aQute.se> 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