> I consider getDataFile an intrinsic part of OSGi since it is the only > reasonable way for a bundle to have some persistent data. The optionality > was only there for embedded devices that did not have a file system. Any > reasonable implementation today has no real excuses not to support it.
Some of us have even gone so far as to emulate a filesystem on a device which didn't really have one, just to support getDataFile ;-). For the use case at hand it seems like the right tool for the job, so long as due care is taken wrt race conditions, imperfect data from some OS's, etc.. >From the point of view of an "way for a bundle to have some persistent data" though, wouldn't that be more a job for Preferences Service? Kid regards, Chris Gray > As a clarification, even with a SecurityManager you should be able to > getDataFile, the framework must automatically provide the proper > permissions. > > Kind regards, > > Peter Kriens > > > > > On 10 aug. 2014, at 07:24, Felix Meschberger <[email protected]> wrote: > >> Hi Ray >> >> Not sure, whether the getDataFile method is an anti-pattern. I surely >> hope not :-) >> >> We use it here and there as well for bundle-private state information. >> The nice thing is that it survives bundle updates and automatically >> cleaned up when the bundle is uninstalled. To me it falls into the >> category of features: If you know exactly what you are doing, it is a >> useful thing. >> >> I think the only caveat is that getDataFile may not be implemented (and >> of course that it is protected if a SecurityManager is active) on >> certain platforms. >> >> Regards >> Felix >> >> Am 09.08.2014 um 19:26 schrieb Raymond Auge <[email protected]>: >> >>> Hey All, >>> >>> Over the years osgi has identified a few anti-patterns in it's initial >>> design (such as activators, etc.) >>> >>> I'm wondering if >>> >>> core/org/osgi/framework/Bundle.html#getDataFile(java.lang.String) >>> >>> is still considered to be a useful pattern. >>> >>> 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. >>> >>> Another option would be checking if the bundle has just been installed. >>> Is this possible? (I believe not). >>> >>> -- >>> Raymond Augé (@rotty3000) >>> Senior Software Architect >>> Liferay, Inc. (@Liferay) >>> >>> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
