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
