You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall (JIRA)" <ji...@apache.org> on 2007/08/16 22:39:31 UTC
[jira] Assigned: (FELIX-339) Ensure bundle identifiers never get
reused
[ https://issues.apache.org/jira/browse/FELIX-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall reassigned FELIX-339:
-------------------------------------
Assignee: Richard S. Hall
> Ensure bundle identifiers never get reused
> ------------------------------------------
>
> Key: FELIX-339
> URL: https://issues.apache.org/jira/browse/FELIX-339
> Project: Felix
> Issue Type: Improvement
> Components: Framework
> Affects Versions: 1.0.0
> Reporter: Marcel Offermans
> Assignee: Richard S. Hall
>
> The spec states about a Bundle Identifier (see 4.3.1 of the core spec): A long that is a Framework assigned unique identifier
> for the full lifetime of a bundle, even if it is updated or the Framework is restarted. Its purpose is to distinguish bundles in a Framework. Bundle identifiers are assigned in ascending order to bundles when they are installed. The method getBundleId() returns a bundle's identifier.
> Currently, there is a scenario in which an identifier might get reused. For example, say you install three bundles, they will get ID's 1, 2 and 3. You then uninstall bundle 3 and subsequently stop the framework. After a restart, you install another bundle. It will then also get an ID of 3. The reason for this is that Felix currently does not persist the highest ID it has used.
> The solution would be to persist this identifier. If somehow this persisted value gets corrupted, the framework should log at least a warning and could then use the same scheme it uses now to at least make an educated guess about the highest used number. A human might want to check out such a warning though.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused
Posted by Marcel Offermans <ma...@luminis.nl>.
On Aug 17, 2007, at 0:25 , Eric Swindell wrote:
> Thanks for the clarification. It's actually 6.1.4.8.
That probably depends on what version of the OSGi spec you're looking
at. In the latest release, 4.1, it is 6.1.4.12 but a couple of things
have been added to the Bundle interface so that might explain the
difference.
> Your quote of the spec still does not say anything about uninstall and
> restart.
Not directly, but if you look at 4.7 which describes the framework
startup and shutdown, you will see that essentially nothing should
change if you restart (stop and start) the framework. So actually,
restarting the framework should not matter, a bundle identifier
should never be reused regardless of that (and it is not if the
framework keeps running, the bug I reported only occurs when you
restart the framework at the right time).
Greetings, Marcel
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused
Posted by BJ Hargrave <ha...@us.ibm.com>.
Eric Swindell <er...@att.net> wrote on 2007-08-16 18:45:03:
> > It means forever. That is, that framework instance can never reuse a
> > bundle id. Regardless of the number of times the framework is
restarted.
> > The only conceivable way to reuse a bundle id would be to uninstall
ALL
> > the bundles (and any persistent storage owned by those bundles) and
then
> > you could restart at bundle id 1. But this is really no different than
> > throwing away the framework instance and starting with a fresh
instance.
>
> The spec never mentions "eternity" :) I mean, this isn't a religion. Or
is
> it :)
>
> By "throwing away the framework instance and starting with a fresh
instance",
> do you mean shuting down the framework instance and restarting it? If
the
> instance is gone, I'd consider it 'thrown away'. If thrown away, then
you're
> stating that it doesn't matter what the bundle ids are when restarting
and
> that they could restart at bundle id 1.
Perhaps instance is a poor term here. I mean the set of installed bundles
and their associated persistent information. I don't know what Felix calls
it, but Equinox calls it a configuration. I do not mean the runtime object
of the framework.
>
> >
> > > It also states "This method must continue to return this bundle's
unique
> > >
> > > identifier while this bundle is in the UNINSTALLED state."
> >
> > This means that if the Bundle object is still reachable and the bundle
it
> > represents is uninstalled, i.e. Bundle.getState() ==
Bundle.UNINSTALLED,
> > then the Bundle.getBundleId must return the bundle's id. Once the
Bundle
> > object is unreachable, it does not really matter what the method
returns
> > since no one can call it :-)
>
> Right! If the Bundle object is unreachable, then it doesn't matter.
It does not matter what that method returns. But it clearly matters that
the bundle id is consumed and is not to be reused.
> In other
> words, if I uninstall a Bundle and restart the framework ( 'throw
itaway' in
> your lingo ), then id consistency does not matter.
Per my statement above, restart framework != throwing away the framework's
installed bundle set.
>
> Seems like we both agree that it is not within the spec :)
No. Don't think we agree that. Like all specs, none are perfect. But it is
the intent of the spec authors that bundle ids are consumed and not reused
by a given framework bundle set.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused
Posted by Eric Swindell <er...@att.net>.
On Thursday 16 August 2007 05:34:41 pm BJ Hargrave wrote:
> Eric Swindell <er...@att.net> wrote on 2007-08-16 18:25:27:
> > Thanks for the clarification. It's actually 6.1.4.8.
>
> Uhhh, not in the latest version, 4.1, of the spec :-)
I stand corrected.
>
> > Your quote of the spec still does not say anything about uninstall and
> > restart. One question here is whether 'uninstalled' means existing with
>
> an
>
> > UNINSTALLED state or uninstalled as in it was uninstalled and the
>
> Framework
>
> > was restarted.
>
> It means forever. That is, that framework instance can never reuse a
> bundle id. Regardless of the number of times the framework is restarted.
> The only conceivable way to reuse a bundle id would be to uninstall ALL
> the bundles (and any persistent storage owned by those bundles) and then
> you could restart at bundle id 1. But this is really no different than
> throwing away the framework instance and starting with a fresh instance.
The spec never mentions "eternity" :) I mean, this isn't a religion. Or is
it :)
By "throwing away the framework instance and starting with a fresh instance",
do you mean shuting down the framework instance and restarting it? If the
instance is gone, I'd consider it 'thrown away'. If thrown away, then you're
stating that it doesn't matter what the bundle ids are when restarting and
that they could restart at bundle id 1.
>
> > It also states "This method must continue to return this bundle's unique
> >
> > identifier while this bundle is in the UNINSTALLED state."
>
> This means that if the Bundle object is still reachable and the bundle it
> represents is uninstalled, i.e. Bundle.getState() == Bundle.UNINSTALLED,
> then the Bundle.getBundleId must return the bundle's id. Once the Bundle
> object is unreachable, it does not really matter what the method returns
> since no one can call it :-)
Right! If the Bundle object is unreachable, then it doesn't matter. In other
words, if I uninstall a Bundle and restart the framework ( 'throw it away' in
your lingo ), then id consistency does not matter.
Seems like we both agree that it is not within the spec :)
>
> But the framework instance it still not allows to reuse the bundle id.
>
> > Seems like either
> > the language here could have been clearer or perhaps the requirementwas
>
> that
>
> > of UNINSTALLED state, e.g. if you uninstall a Bundle, that Bundle id is
>
> not
>
> > to be reused with the running Framework versus bundle ids are permanent
> > unique identifiers which remain unique even after a bundle is
>
> uninstalled and
>
> > the Framework instance is terminated.
>
> The latter.
>
> > Eric
> >
> > On Thursday 16 August 2007 05:05:07 pm BJ Hargrave wrote:
> > > See section 6.1.4.12 in the spec:
> > >
> > > "Its value is not reused for another bundle, even after a bundle is
> > > uninstalled."
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused
Posted by BJ Hargrave <ha...@us.ibm.com>.
Eric Swindell <er...@att.net> wrote on 2007-08-16 18:25:27:
> Thanks for the clarification. It's actually 6.1.4.8.
Uhhh, not in the latest version, 4.1, of the spec :-)
>
> Your quote of the spec still does not say anything about uninstall and
> restart. One question here is whether 'uninstalled' means existing with
an
> UNINSTALLED state or uninstalled as in it was uninstalled and the
Framework
> was restarted.
It means forever. That is, that framework instance can never reuse a
bundle id. Regardless of the number of times the framework is restarted.
The only conceivable way to reuse a bundle id would be to uninstall ALL
the bundles (and any persistent storage owned by those bundles) and then
you could restart at bundle id 1. But this is really no different than
throwing away the framework instance and starting with a fresh instance.
>
> It also states "This method must continue to return this bundle's unique
> identifier while this bundle is in the UNINSTALLED state."
This means that if the Bundle object is still reachable and the bundle it
represents is uninstalled, i.e. Bundle.getState() == Bundle.UNINSTALLED,
then the Bundle.getBundleId must return the bundle's id. Once the Bundle
object is unreachable, it does not really matter what the method returns
since no one can call it :-)
But the framework instance it still not allows to reuse the bundle id.
> Seems like either
> the language here could have been clearer or perhaps the requirementwas
that
> of UNINSTALLED state, e.g. if you uninstall a Bundle, that Bundle id is
not
> to be reused with the running Framework versus bundle ids are permanent
> unique identifiers which remain unique even after a bundle is
uninstalled and
> the Framework instance is terminated.
The latter.
>
> Eric
>
> On Thursday 16 August 2007 05:05:07 pm BJ Hargrave wrote:
> > See section 6.1.4.12 in the spec:
> >
> > "Its value is not reused for another bundle, even after a bundle is
> > uninstalled."
>
>
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused
Posted by Eric Swindell <er...@att.net>.
Thanks for the clarification. It's actually 6.1.4.8.
Your quote of the spec still does not say anything about uninstall and
restart. One question here is whether 'uninstalled' means existing with an
UNINSTALLED state or uninstalled as in it was uninstalled and the Framework
was restarted.
It also states "This method must continue to return this bundle's unique
identifier while this bundle is in the UNINSTALLED state." Seems like either
the language here could have been clearer or perhaps the requirement was that
of UNINSTALLED state, e.g. if you uninstall a Bundle, that Bundle id is not
to be reused with the running Framework versus bundle ids are permanent
unique identifiers which remain unique even after a bundle is uninstalled and
the Framework instance is terminated.
Eric
On Thursday 16 August 2007 05:05:07 pm BJ Hargrave wrote:
> See section 6.1.4.12 in the spec:
>
> "Its value is not reused for another bundle, even after a bundle is
> uninstalled."
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused
Posted by Eric Swindell <er...@att.net>.
Ok, since I've exhausted the patience of one of the responders, I'll end the
thread here :)
I think it benefits any community when such issues are openly debated, and
while I don't necessarily interpet the spec the way others have stated, at
least opinions on the 'intent' of the spec were made part of the discourse.
Like someone posted previously, no spec is perfect. However, we can learn
from this whenever a requirement is put into writing to ensure that there is
no ambiguity.
Eric
On Thursday 16 August 2007 05:54:09 pm Richard S. Hall wrote:
> While I understand Eric's point that it might not be 100% clear, it was
> always my understanding that the spec meant "no re-use of IDs
> forever"...there has been a comment in the code dating back to the
> Oscar days saying that this portion of the impl was non-compliant, it
> was just never an issue before Marcel started complaining about it. ;-)
>
> It is not too ugly to add this functionality, I just modified the
> bundle cache so that the system bundle has its own private data area,
> so now it just writes it to there. Up until this point, the framework
> never saved any data for itself...now it actually has the added benefit
> that system bundle activators passed into the Felix constructor can now
> also persist stuff to the system bundle private data area, so it is not
> all bad. :-D
>
> -> richard
>
> On Aug 16, 2007, at 6:34 PM, Eric Swindell wrote:
> > I figured there was a use case somewhere :) However, I'm still not
> > convinced
> > that it's in the spec. I'm not sure it is wise to rely on the
> > consistency of
> > the id in this case. Yes, while the bundles are running within a
> > Framework
> > instance and yes on restarts, but if a Bundle is uninstalled and the
> > Framework instance restarted, I'm not seeing the need nor the spec
> > requirement. I wouldn't even be concerned if the Bundle ids changed
> > after a
> > restart.
> >
> > Eric
> >
> > On Thursday 16 August 2007 05:23:03 pm Marcel Offermans wrote:
> >> On Aug 17, 2007, at 0:05 , BJ Hargrave wrote:
> >>> See section 6.1.4.12 in the spec:
> >>> "Its value is not reused for another bundle, even after a bundle is
> >>> uninstalled."
> >>
> >> Following up on Eric's question. Like BJ says, it's in the spec, and
> >> I actually have a use case for it too. We're tracking life cycle
> >> changes in the framework and in that context we're using the bundle
> >> identifier as an identifier. That means we actually rely on the fact
> >> that this identifier will only refer to one bundle (and describes its
> >> whole life cycle).
> >>
> >> Greetings, Marcel
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused
Posted by "Richard S. Hall" <he...@ungoverned.org>.
While I understand Eric's point that it might not be 100% clear, it was
always my understanding that the spec meant "no re-use of IDs
forever"...there has been a comment in the code dating back to the
Oscar days saying that this portion of the impl was non-compliant, it
was just never an issue before Marcel started complaining about it. ;-)
It is not too ugly to add this functionality, I just modified the
bundle cache so that the system bundle has its own private data area,
so now it just writes it to there. Up until this point, the framework
never saved any data for itself...now it actually has the added benefit
that system bundle activators passed into the Felix constructor can now
also persist stuff to the system bundle private data area, so it is not
all bad. :-D
-> richard
On Aug 16, 2007, at 6:34 PM, Eric Swindell wrote:
> I figured there was a use case somewhere :) However, I'm still not
> convinced
> that it's in the spec. I'm not sure it is wise to rely on the
> consistency of
> the id in this case. Yes, while the bundles are running within a
> Framework
> instance and yes on restarts, but if a Bundle is uninstalled and the
> Framework instance restarted, I'm not seeing the need nor the spec
> requirement. I wouldn't even be concerned if the Bundle ids changed
> after a
> restart.
>
> Eric
>
> On Thursday 16 August 2007 05:23:03 pm Marcel Offermans wrote:
>> On Aug 17, 2007, at 0:05 , BJ Hargrave wrote:
>>> See section 6.1.4.12 in the spec:
>>> "Its value is not reused for another bundle, even after a bundle is
>>> uninstalled."
>>
>> Following up on Eric's question. Like BJ says, it's in the spec, and
>> I actually have a use case for it too. We're tracking life cycle
>> changes in the framework and in that context we're using the bundle
>> identifier as an identifier. That means we actually rely on the fact
>> that this identifier will only refer to one bundle (and describes its
>> whole life cycle).
>>
>> Greetings, Marcel
>
>
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused
Posted by Marcel Offermans <ma...@luminis.nl>.
On Aug 17, 2007, at 0:34 , Eric Swindell wrote:
> I wouldn't even be concerned if the Bundle ids changed after a
> restart.
I would be! :)
PS: sorry for basically echoing what BJ said, I only saw his reply
after I sent mine.
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused
Posted by BJ Hargrave <ha...@us.ibm.com>.
Eric Swindell <er...@att.net> wrote on 2007-08-16 18:56:39:
> On Thursday 16 August 2007 05:47:37 pm BJ Hargrave wrote:
> > Use case: A bundle like Preference Service manages persistent storage
for
> > other bundles based upon a bundles identity. This bundle needs to know
> > when a bundle for which it managing storage has permanently gone. If
> > bundle ids can be reused, the Prefs bundle would not be able to
destroy
> > the original bundle's information and would provide it to the new
bundle.
> > The Prefs bundle might not be running at the time the original bundle
is
> > uninstalled and thus would not receive the UNINSTALLED event. So it
must
> > rely on the fact that the framework guarantees that bundle ids are
never
> > reused.
>
> Your premise implies that the implementation requirement takes higher
> precedence than the spec.
Huh? I am giving you an actual use case. Which is supports by the fact
that bundle ids are not reused.
> Seems like the tail is wagging the dog :) I
> thought that symbolic name was added to the spec for bundle identity.
Bundle symbolic name is NOT identity. Bundle ID is identity. Hence the
ID. Multiple bundles can have the same symbolic name (with different
versions).
>
> >
> > In any case, you can take my word for it, since I was there when all
this
> > was first conceived. From the R1 spec:
> >
> > "Once its value is assigned to a bundle, that value must not be reused
for
> > another bundle, even if the original bundle is uninstalled."
>
> If you read your prior posting and my prior reply, you'll see that
> we agree on
> the spec's interpretation. You said that if the framework instance
> was 'thrown away', then id consistency is not relevant. I agree with
this.
I do NOT agree with this based upon my previous clarification of what I
meant by framework instance.
>
> Eric
>
You can either take my word (as a spec author) that bundle ids are not to
be reused. Or you can choose to believe otherwise. In any case I am tired
of this thread.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused
Posted by Eric Swindell <er...@att.net>.
On Thursday 16 August 2007 05:47:37 pm BJ Hargrave wrote:
> Use case: A bundle like Preference Service manages persistent storage for
> other bundles based upon a bundles identity. This bundle needs to know
> when a bundle for which it managing storage has permanently gone. If
> bundle ids can be reused, the Prefs bundle would not be able to destroy
> the original bundle's information and would provide it to the new bundle.
> The Prefs bundle might not be running at the time the original bundle is
> uninstalled and thus would not receive the UNINSTALLED event. So it must
> rely on the fact that the framework guarantees that bundle ids are never
> reused.
Your premise implies that the implementation requirement takes higher
precedence than the spec. Seems like the tail is wagging the dog :) I
thought that symbolic name was added to the spec for bundle identity.
>
> In any case, you can take my word for it, since I was there when all this
> was first conceived. From the R1 spec:
>
> "Once its value is assigned to a bundle, that value must not be reused for
> another bundle, even if the original bundle is uninstalled."
If you read your prior posting and my prior reply, you'll see that we agree on
the spec's interpretation. You said that if the framework instance
was 'thrown away', then id consistency is not relevant. I agree with this.
Eric
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused
Posted by BJ Hargrave <ha...@us.ibm.com>.
Use case: A bundle like Preference Service manages persistent storage for
other bundles based upon a bundles identity. This bundle needs to know
when a bundle for which it managing storage has permanently gone. If
bundle ids can be reused, the Prefs bundle would not be able to destroy
the original bundle's information and would provide it to the new bundle.
The Prefs bundle might not be running at the time the original bundle is
uninstalled and thus would not receive the UNINSTALLED event. So it must
rely on the fact that the framework guarantees that bundle ids are never
reused.
In any case, you can take my word for it, since I was there when all this
was first conceived. From the R1 spec:
"Once its value is assigned to a bundle, that value must not be reused for
another bundle, even if the original bundle is uninstalled."
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
Eric Swindell <er...@att.net>
2007-08-16 18:34
Please respond to
dev@felix.apache.org
To
dev@felix.apache.org
cc
Subject
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get
reused
I figured there was a use case somewhere :) However, I'm still not
convinced
that it's in the spec. I'm not sure it is wise to rely on the consistency
of
the id in this case. Yes, while the bundles are running within a
Framework
instance and yes on restarts, but if a Bundle is uninstalled and the
Framework instance restarted, I'm not seeing the need nor the spec
requirement. I wouldn't even be concerned if the Bundle ids changed after
a
restart.
Eric
On Thursday 16 August 2007 05:23:03 pm Marcel Offermans wrote:
> On Aug 17, 2007, at 0:05 , BJ Hargrave wrote:
> > See section 6.1.4.12 in the spec:
> > "Its value is not reused for another bundle, even after a bundle is
> > uninstalled."
>
> Following up on Eric's question. Like BJ says, it's in the spec, and
> I actually have a use case for it too. We're tracking life cycle
> changes in the framework and in that context we're using the bundle
> identifier as an identifier. That means we actually rely on the fact
> that this identifier will only refer to one bundle (and describes its
> whole life cycle).
>
> Greetings, Marcel
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused
Posted by Eric Swindell <er...@att.net>.
I figured there was a use case somewhere :) However, I'm still not convinced
that it's in the spec. I'm not sure it is wise to rely on the consistency of
the id in this case. Yes, while the bundles are running within a Framework
instance and yes on restarts, but if a Bundle is uninstalled and the
Framework instance restarted, I'm not seeing the need nor the spec
requirement. I wouldn't even be concerned if the Bundle ids changed after a
restart.
Eric
On Thursday 16 August 2007 05:23:03 pm Marcel Offermans wrote:
> On Aug 17, 2007, at 0:05 , BJ Hargrave wrote:
> > See section 6.1.4.12 in the spec:
> > "Its value is not reused for another bundle, even after a bundle is
> > uninstalled."
>
> Following up on Eric's question. Like BJ says, it's in the spec, and
> I actually have a use case for it too. We're tracking life cycle
> changes in the framework and in that context we're using the bundle
> identifier as an identifier. That means we actually rely on the fact
> that this identifier will only refer to one bundle (and describes its
> whole life cycle).
>
> Greetings, Marcel
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused
Posted by Marcel Offermans <ma...@luminis.nl>.
On Aug 17, 2007, at 0:05 , BJ Hargrave wrote:
> See section 6.1.4.12 in the spec:
> "Its value is not reused for another bundle, even after a bundle is
> uninstalled."
Following up on Eric's question. Like BJ says, it's in the spec, and
I actually have a use case for it too. We're tracking life cycle
changes in the framework and in that context we're using the bundle
identifier as an identifier. That means we actually rely on the fact
that this identifier will only refer to one bundle (and describes its
whole life cycle).
Greetings, Marcel
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused
Posted by BJ Hargrave <ha...@us.ibm.com>.
See section 6.1.4.12 in the spec:
"Its value is not reused for another bundle, even after a bundle is
uninstalled."
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
Eric Swindell <er...@att.net>
2007-08-16 17:53
Please respond to
dev@felix.apache.org
To
dev@felix.apache.org
cc
Subject
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get
reused
I'm not sure I understand the issue. The spec says that the framework is
supposed to assign a unique identifier for the 'lifetime' of a bundle,
"even
if it is updated or the Framework is restarted." The example provided in
the
issue is that of 'uninstalling' a Bundle and restarting the framework.
My interpretation is that if the Bundle is uninstalled, then its
'lifetime'
with respect to that framework has ended. The spec uses the terms
'update'
and 'restart' and does not explicitly state a requirement that bundle ids
are
to be considered permanent long after those bundles are uninstalled.
Therefore, I don't see a need to complicate the numbering scheme with
unnecessary complexity. Is the reasoning for this issue due to the
reliance
on id consistency by external systems outside the framework? Am I missing
something here?
Eric
> [
>
https://issues.apache.org/jira/browse/FELIX-339?page=com.atlassian.jira.plu
>gin.system.issuetabpanels:all-tabpanel ]
>
> Richard S. Hall reassigned FELIX-339:
> -------------------------------------
>
> Assignee: Richard S. Hall
>
> > Ensure bundle identifiers never get reused
> > ------------------------------------------
> >
> > Key: FELIX-339
> > URL: https://issues.apache.org/jira/browse/FELIX-339
> > Project: Felix
> > Issue Type: Improvement
> > Components: Framework
> > Affects Versions: 1.0.0
> > Reporter: Marcel Offermans
> > Assignee: Richard S. Hall
> >
> > The spec states about a Bundle Identifier (see 4.3.1 of the core
spec): A
> > long that is a Framework assigned unique identifier for the full
lifetime
> > of a bundle, even if it is updated or the Framework is restarted. Its
> > purpose is to distinguish bundles in a Framework. Bundle identifiers
are
> > assigned in ascending order to bundles when they are installed. The
> > method getBundleId() returns a bundle's identifier. Currently, there
is a
> > scenario in which an identifier might get reused. For example, say you
> > install three bundles, they will get ID's 1, 2 and 3. You then
uninstall
> > bundle 3 and subsequently stop the framework. After a restart, you
> > install another bundle. It will then also get an ID of 3. The reason
for
> > this is that Felix currently does not persist the highest ID it has
used.
> > The solution would be to persist this identifier. If somehow this
> > persisted value gets corrupted, the framework should log at least a
> > warning and could then use the same scheme it uses now to at least
make
> > an educated guess about the highest used number. A human might want to
> > check out such a warning though.
Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused
Posted by Eric Swindell <er...@att.net>.
I'm not sure I understand the issue. The spec says that the framework is
supposed to assign a unique identifier for the 'lifetime' of a bundle, "even
if it is updated or the Framework is restarted." The example provided in the
issue is that of 'uninstalling' a Bundle and restarting the framework.
My interpretation is that if the Bundle is uninstalled, then its 'lifetime'
with respect to that framework has ended. The spec uses the terms 'update'
and 'restart' and does not explicitly state a requirement that bundle ids are
to be considered permanent long after those bundles are uninstalled.
Therefore, I don't see a need to complicate the numbering scheme with
unnecessary complexity. Is the reasoning for this issue due to the reliance
on id consistency by external systems outside the framework? Am I missing
something here?
Eric
> [
> https://issues.apache.org/jira/browse/FELIX-339?page=com.atlassian.jira.plu
>gin.system.issuetabpanels:all-tabpanel ]
>
> Richard S. Hall reassigned FELIX-339:
> -------------------------------------
>
> Assignee: Richard S. Hall
>
> > Ensure bundle identifiers never get reused
> > ------------------------------------------
> >
> > Key: FELIX-339
> > URL: https://issues.apache.org/jira/browse/FELIX-339
> > Project: Felix
> > Issue Type: Improvement
> > Components: Framework
> > Affects Versions: 1.0.0
> > Reporter: Marcel Offermans
> > Assignee: Richard S. Hall
> >
> > The spec states about a Bundle Identifier (see 4.3.1 of the core spec): A
> > long that is a Framework assigned unique identifier for the full lifetime
> > of a bundle, even if it is updated or the Framework is restarted. Its
> > purpose is to distinguish bundles in a Framework. Bundle identifiers are
> > assigned in ascending order to bundles when they are installed. The
> > method getBundleId() returns a bundle's identifier. Currently, there is a
> > scenario in which an identifier might get reused. For example, say you
> > install three bundles, they will get ID's 1, 2 and 3. You then uninstall
> > bundle 3 and subsequently stop the framework. After a restart, you
> > install another bundle. It will then also get an ID of 3. The reason for
> > this is that Felix currently does not persist the highest ID it has used.
> > The solution would be to persist this identifier. If somehow this
> > persisted value gets corrupted, the framework should log at least a
> > warning and could then use the same scheme it uses now to at least make
> > an educated guess about the highest used number. A human might want to
> > check out such a warning though.