Do you mean the 'old' UserAdmin also does implement the OSGi UserAdmin service spec? Then yes, this would be the simplest way to do migration. But IMHO we also should provide a way for other (non OSGi UserAdmin) implementations to migrate their data, ... this would lead to a command like:
copyUserAdminData <source> <target> e.g.: # import from XML copyUserAdminData file://<xml-file> bundle://<useradmin bundle symbolic name or ID> # import from another UserAdmin implementation copyUserAdminData bundle://<old useradmin bundle symbolic name or ID> bundle://<new useradmin bundle symbolic name or ID> # export to XML copyUserAdminData bundle://<useradmin bundle symbolic name or ID> file://<xml-file> Ok like that? Other suggestions? BTW: does PaxRunner provide a way to start up a framework, run a OSGi shell command and then shutdown the framework? On Fri, Jul 31, 2009 at 1:02 PM, David Leangen <op...@leangen.net> wrote: > > I'll start thinking about a migration tool - maybe a shell command that >> imports from/exports to an XML file would be appropriate ... WDYT? >> > > Yeah, that would be nice. > > An XML file could work. Mine is persisted using prevayler / xml, so I could > just transform my XML file. > > Another possibility would be to provide some kind of a command-line tool > that will do the migration. The command-line tool would create an OSGi > container and start up both the "old" UserAdmin as well as the "new" one. > The script would then get all the information from the old bundle and > populate the new bundle with it. > > That would probably be my preferred approach. That way, all the user needs > to do is identify the new and old bundles, and all the rest is done > automagically by your script. > > wdyt? > > > > > > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general >
_______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
