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