[
http://jira.amdatu.org/jira/browse/AMDATU-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=10176#comment-10176
]
Marcel Offermans commented on AMDATU-131:
-----------------------------------------
Ok, so the simplest solution for a service that needs to store things is to
simply use the bundle storage. That makes sense, let's keep it simple.
Then you state if we want to give a bundle a pluggable storage, the bundle
should use the Preferences Service, instead of designing its own specific
service API? I don't really see how that would work. Let's use a simple
example, where we have a bundle A and bundle B that each have some storage
need. Let's also say that for bundle A want to use the default storage
mechanism, embedded in the bundle, and for bundle B we want to have it use the
Preferences Service. So, we install the Preferences Service. What happens next
is that both bundles will probably start using the Preferences Service since
they are all designed to use that as a storage mechanism when it's available.
Of course you can then add more explicit configuration information to each
bundle to allow you to configure if it even should use the Preferences Service
if it's around, but that needlessly complicates things IMHO.
Also, what you achieve with the Preferences Service might not what you expect.
Yes, it does provide you with a centralized storage model. No, any storage for
a specific bundle will still not survive beyond the life cycle of the bundle
(ie, if you uninstall the bundle, or clear the bundle cache, you will
immediately loose all data).
I still say that creating a specific storage mechanism for each bundle that
needs a pluggable implementation of its (by default) bundle storage specific
implementation makes the most sense. That way any custom storage mechanism
directly targets a specific bundle. Still, if most bundles use some form of a
persistent Map, bridging from a specific storage API to a generic
Map/Preferences API will be easy.
Regarding point 4: I would say everything should always be usable through its
service interface only. That's how we build, test and deploy our components.
Storage is an implementation detail which I'm certainly going to test very well
(through the service interface of the component) but that's it. That does not
invalidate the point I make above, that a component can certainly have a
pluggable storage implementation.
> Implement Simple persistent storage for Amdatu core
> ---------------------------------------------------
>
> Key: AMDATU-131
> URL: http://jira.amdatu.org/jira/browse/AMDATU-131
> Project: Amdatu
> Issue Type: Task
> Components: Platform - Persistence
> Affects Versions: 0.0.6
> Reporter: Ivo Ladage - van Doorn
> Assignee: Ivo Ladage - van Doorn
> Fix For: 0.0.6
>
>
> Some simple storage engine needs to be used to store roles for UserAdmin,
> configuration for ConfigurationAdmin and tenants for the tenant service.
> There are a lot of (open source) options, most of them described on this
> page: http://java-source.net/open-source/database-engines
> The main question however is I think; what do we require from this storage?
> Requirements:
> -1- Very lightweight; small in size, low memory footprint, etc.
> -2- Low software/hardware requirements (i.e. supports Java 1.3)
> -3- The storage engine must be open source and provide a Java API
> -4- A simple web-based GUI would be nice, though not required
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
