Whoops, I used the wrong e-mail address appearantly, so this one bounced: On 10 Aug 2014, at 0:23 am, [email protected] wrote:
> You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > [email protected]. > > > From: Marcel Offermans <[email protected]> > Subject: Re: [osgi-dev] bundle.getDataFile(string) > Date: 10 Aug 2014 0:22:57 GMT+2 > To: OSGi Developer Mail List <[email protected]> > > > Hello Raymond, > > On 09 Aug 2014, at 19:26 pm, Raymond Auge <[email protected]> wrote: > >> Over the years osgi has identified a few anti-patterns in it's initial >> design (such as activators, etc.) > > Maybe an anti-pattern is a bit strong, I would rather say that some APIs that > OSGi exposes tended to be a bit too low-level for most people. Anyway, that's > not the point of your message... > >> I'm wondering if >> >> core/org/osgi/framework/Bundle.html#getDataFile(java.lang.String) >> >> is still considered to be a useful pattern. > > If you ask me, it definitely is. I know a lot of people kill the bundle cache > on every startup and re-install all bundles each time, but I would advocate > that that is bad practice in OSGi. That bundle specific data area is a great > place to persist information that needs to survive restarts. > >> My use case is to prevent multiple attempts to perform a DB upgrade process. >> >> Now, this operation is idempotent. However, it's also rather expensive and >> could slow initialization considerably so I'd like to persist the fact that >> the operation was completed successfully with some sort of stored flag. > > That sounds just fine. > > Do you also need to take into account "downgrading" or maybe even updating > from an arbitrary version X to Y (or Y to X)? > >> Another option would be checking if the bundle has just been installed. Is >> this possible? (I believe not). > > Not as far as I know. You could listen to events, but I would not go that > road for this use case. > > Greetings, Marcel > > >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
