Re: [osgi-dev] bundle.getDataFile(string)
Thank you all! On Tue, Aug 12, 2014 at 1:10 PM, chris.g...@kiffer.be wrote: 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 fmesc...@adobe.com 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 raymond.a...@liferay.com: 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 osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile (@rotty3000) Senior Software Architect *Liferay, Inc.* http://www.liferay.com (@Liferay) ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] bundle.getDataFile(string)
Marcel wrote: 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. Hear hear. In fact if there are anti-patterns out there then this is one of them - and not just because of getDataFile. ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] bundle.getDataFile(string)
Hello, it might be a anti-pattern for some. For others it is a anti-pattern to have a persistent (corruptable) state location required and used by the framework when the actual application bundles deliverable try to need no state, persistence and low permission. The frameworks I have looked at (and Equinox is a particular unflexible example) make this hard for deployers. So deleting the directory (or starting with -clean) is not always an anti-pattern it is also a symptom for a unsatisfied need to trade startup speed against robustness. greetings Bernd -- http://bernd.eckenfels.net - Ursprüngliche Nachricht - Von: chris.g...@kiffer.be chris.g...@kiffer.be Gesendet: 13.08.2014 22:29 An: OSGi Developer Mail List osgi-dev@mail.osgi.org Betreff: Re: [osgi-dev] bundle.getDataFile(string) Marcel wrote: 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. Hear hear. In fact if there are anti-patterns out there then this is one of them - and not just because of getDataFile. ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] bundle.getDataFile(string)
Provided you aren't clearing your bundle cache and such, then I agree that getDataFile() works just fine. Otherwise, you could use an arbitrary file in the general file system, but getDataFile() is more portable. The choice of which depends on the nature of your program (e.g., internal usage, distributed for others to use, what hardware it runs on, etc.). On 10 August 2014 10:01, Marcel Offermans marcel.offerm...@luminis.nl wrote: Whoops, I used the wrong e-mail address appearantly, so this one bounced: On 10 Aug 2014, at 0:23 am, osgi-dev-ow...@mail.osgi.org 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 osgi-dev-ow...@mail.osgi.org. *From: *Marcel Offermans marcel.offerm...@luminis.eu *Subject: **Re: [osgi-dev] bundle.getDataFile(string)* *Date: *10 Aug 2014 0:22:57 GMT+2 *To: *OSGi Developer Mail List osgi-dev@mail.osgi.org Hello Raymond, On 09 Aug 2014, at 19:26 pm, Raymond Auge raymond.a...@liferay.com 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 osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
