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.
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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
