felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff McAffer <Jeff_McAf...@ca.ibm.com>
Subject Re: Re[2]: Fixed bug in class loading
Date Thu, 13 Apr 2006 20:59:13 GMT
To a certain degree we are off in the weeds here.  All I am saying is that 
there exist usecases where you cannot wrap or modify.  I'm not saying they 
are right, valid, desireable or anything other than real.  The folks with 
the usecases really really were not able to take those options.

Peter Kriens <Peter.Kriens@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.

Point of interest: If the metadata is separate then, depending on the 
change, it may not need updating.

> JM> - If the JARs are delivered as part of something else you may not 
have a
> JM> chance to modify
> But if you need to provide new metadata, you need to do something??

Only if things changed in interesting ways.  If it was just a bug fix for 
example, you might not have to.

> JM> - User permissions on the machine may not allow for modification (we 
> 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?

We have preinitializers that run and extract/cache the various files that 
must be extracted to run (e.g., dlls, ...).  None of our bundles use 
getDataFile().  Many of our bundles are able to function (perhaps with 
diminished capabilities) in environments that do not support writing. Even 
getDataFile is spec'd to return null if data files are not supported.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message