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.
-> 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.
