Hi, Richard S. Hall schrieb: > On 7/4/09 3:43 AM, Marcel Offermans wrote: >> Still not a big fan of having to manually upgrade caches when >> upgrading the framework. At the very least, framework 2 should detect >> that a bundle cache is old and refuse to start. Better would be a >> process that transparently upgrades it. Even better would be an >> official way to upgrade a running framework without manual intervention. >> >> Especially when used in embedded scenarios, having to manually access >> the system can be very "unpractical" so I was wondering how difficult >> it would be to support automatic upgrade (and maybe even downgrade, >> but that's far less common). > > Likewise, I am not a big fan of keeping legacy support around forever. > We've been silently supporting the legacy cache for quite a while now. > If moving to 2.0 is not an opportunity to break compatibility, then I > don't know when is. > > In truth, I am not even sure this will be an issue. I just tested it and > it looks like it just extracts an extra copy into the new directory. So, > worst case scenario is people will end up with two extracted copies of > an embedded JAR file.
Sounds like a good option to me. Regards Felix > > -> richard > >> >> Greetings, Marcel >> >> >> On Jul 3, 2009, at 21:31 , Felix Meschberger wrote: >> >>> Hi, >>> >>> Cool, yes, this is pretty straight-forward. Thanks. >>> >>> Regards >>> Felix >>> >>> Richard S. Hall schrieb: >>>> On 7/3/09 2:18 PM, Felix Meschberger wrote: >>>>> Hi, >>>>> >>>>> This worries me a bit, since we have a few bundles with embedded jar >>>>> files on the class path... >>>>> >>>>> Will look into this when it becomes an issue for us. >>>>> >>>> >>>> I do think someone could create a script for this fairly easily. The >>>> old >>>> cache format is typically like this: >>>> >>>> felix-cache/ >>>> bundleN/ >>>> versionX.0/ >>>> bundle.jar >>>> embedded/ >>>> embedded.jar >>>> bundle.../ >>>> >>>> The only thing that needs to happen is the above "embedded/" directory >>>> needs to literally be renamed to "bundle.jar-embedded/". The >>>> "bundle.jar" name is a constant, so that won't change. We would end up >>>> with: >>>> >>>> felix-cache/ >>>> bundleN/ >>>> versionX.0/ >>>> bundle.jar >>>> bundle.jar-embedded/ >>>> embedded.jar >>>> bundle.../ >>>> >>>> So if you have a cache with lots of embedded JAR files, at least we >>>> will >>>> have a good test case to verify if renaming the embedded directory >>>> works. :-) >>>> >>>> -> richard >>>> >>>>> Thanks for the clarification. >>>>> >>>>> Regards >>>>> Felix >>>>> >>>>> Richard S. Hall schrieb: >>>>> >>>>>> On 7/3/09 2:06 PM, Richard S. Hall wrote: >>>>>> >>>>>>> On 7/3/09 1:59 PM, Felix Meschberger wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> What does this mean for my framework bundle cache created with a >>>>>>>> current >>>>>>>> framework when upgrading to framework 2 ? Will the bundle cache be >>>>>>>> migrated or just be used as is ? >>>>>>>> >>>>>>> If you have an existing cache you want to use with Felix 2.0, it >>>>>>> will >>>>>>> need to be migrated if and only if your bundles have embedded JAR >>>>>>> files on their bundle class path. >>>>>>> >>>>>> To be more clear, *you* will need to migrate it by renaming the >>>>>> directories to which embedded JARs are extracted. >>>>>> >>>>>> -> richard >>>>>> >>>>>> >>>>>>> -> richard >>>>>>> >>>>>>> >>>>>>>> Thanks and Regards >>>>>>>> Felix >>>>>>>> >>>>>>>> Richard S. Hall (JIRA) schrieb: >>>>>>>> >>>>>>>>> Remove legacy bundle cache support when extracting embedded JAR >>>>>>>>> files >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> Key: FELIX-1300 >>>>>>>>> URL: >>>>>>>>> https://issues.apache.org/jira/browse/FELIX-1300 >>>>>>>>> Project: Felix >>>>>>>>> Issue Type: Improvement >>>>>>>>> Components: Framework >>>>>>>>> Affects Versions: felix-1.8.1 >>>>>>>>> Reporter: Richard S. Hall >>>>>>>>> Assignee: Richard S. Hall >>>>>>>>> Priority: Minor >>>>>>>>> Fix For: felix-2.0.0 >>>>>>>>> >>>>>>>>> >>>>>>>>> A while ago we modified IContent so we could use that interface to >>>>>>>>> extract JAR files, which was necessary for fragment support >>>>>>>>> where we >>>>>>>>> needed to be able to access embedded content to construct the host >>>>>>>>> class path. The approach is actually more powerful than what is >>>>>>>>> necessary, since we allow JAR files to be extracted from embedded >>>>>>>>> JAR files and JAR files embedded in the embedded JAR files to be >>>>>>>>> extracted and so. As a result of this, you can end up with >>>>>>>>> situation >>>>>>>>> where embedded JAR files in different embedded JAR files may have >>>>>>>>> the same name, so to avoid name clashes, we extract embedded JAR >>>>>>>>> files into a directory named after the bundle. This was >>>>>>>>> problematic >>>>>>>>> at the top-level, since it would not be backwards compatible with >>>>>>>>> existing caches. As a result, we special case the top-level and >>>>>>>>> just >>>>>>>>> use the name "embedded" for the directly as was done in the past. >>>>>>>>> With the move to 2.0, I want to remove this legacy since there >>>>>>>>> isn't >>>>>>>>> much point to keeping it. >>>>>>>>> >>>>>>>>> >>>> >> >
