Well, Configurations are not a 'service' and by treating it as entities, it will be so much easier to make GUI/web driven configuration tools instead of the primitive properties files, xml files and what have you among the 'competition'. The downside is ES config is a bit trickier, but still totally possible. My take is that you either use the Preferences ES (now in sandbox) or an upcoming Null ES where the properties will remain the source of config and can't change.
-- Niclas On Aug 22, 2009 9:39 PM, "philippe van dyck" <[email protected]> wrote: > > Without knowing your details, I suspect that you have a common setup problem, namely that an ES... Definitely ! But using different modules to store the config sounds complicated to me. I plan to ignore any ES request originating from the Configuration service until the Configuration service is itself activated. It is not the best solution but, it is quite logical that a Configuration cannot be stored in an ES using the same Configuration service! Thanks Niclas phil > > -- Niclas > > >> On Aug 22, 2009 9:00 PM, "philippe van dyck" < [email protected]> wrote: >> >> H... _______________________________________________ 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
