Great, perhaps a qi4j root node? Regarding versions: I don't think its necessary as most applications can and will reuse the configuration of their predecessors. I'd go for the more complex mapping of ValueComposites.
Michael Rickard Öberg schrieb: > Hey, > > I have just committed a first version of an EntityStore based on the > Preferences API. It is added to the SPI, next to the MemoryEntityStore, > since the idea is that it should be used for all service Configuration > entities, i.e. quite often. > > The rules for storage are: > * Create a root node in the system preferences with the application name > * Under that root, create a node using the identity of the Entity (this > will be the Service identity for Service Configurations) > * Store properties as preferences, using the native Preferences types as > much as possible > * All properties which cannot be stored using native types are > serialized into byte arrays, and stored that way > > On my Mac the preferences are stored in the file: > /Library/Preferences/com.apple.java.util.prefs.plist > and can be edited using the regular Property Editor. This will vary > depending on OS of course. > > Issues: > * Is the naming convention ok? Should we include application version > also in the node path (e.g. "/PetClinic/0.3/JettyService") > * Would it be a good idea to map "Property<SomeComposite> someValue()" > in Jetty configuration (example only) so that it creates a node > /PetClinic/0.3/JettyService/someValue and then the SomeComposite > properties are stored under there? This would allow for more complex > configurations > > Other things to consider/improve? > > /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
