On Tue, Jul 20, 2010 at 4:26 AM, Mark Derricutt <[email protected]> wrote: > Interesting, I just noticed that with having the <configuration> > blocks inside the feature file, they reset/overwrite any changes made > via the GUI when restarting. So I think I'll go away from sticking > default settings in there. > > I understand where you're coming from with the features being rather > static - I was then wondering what method people are generally using > for deploying applications into their runtimes. OBR? > Deployment-Packages?
Since 2.0, features can leverage OBR so that OBR will be used to compute the transitive closure based on the list of bundles listed in the feature. It can be done by simply adding resolver="obr" to the feature element. The problem with DeploymentAdmin is that you are limited to a single version of a given bundle. > I like the idea of the deployment-package, having a single versioned > .dp file that contains all of our apps bundles for version X which > could be dropped into the ./deploy directory, but I had read somewhere > in the compendium that if you deploy via a deployment-package, then > the individual bundles can only be updated ALSO via a deployment > package ( I've not yet tested this method tho ). Yeah, DeploymentAdmin is too limited. We're working inside the OSGi alliance on something called composite bundles / subsystems that would allow a nice deployment. Features could then be mapped to subsystems in the future and slowly deprecated. That said, I'm not opposed to make features evolve and add some lifecycle management / update and all other kind of new stuff, quite the opposite. > It seems there's several options all with pros/cons - would be nice to > see a "current best practice" doc... > > Mark > > > -- > Pull me down under... > > On Mon, Jul 19, 2010 at 6:33 PM, Guillaume Nodet <[email protected]> wrote: >> For the configuration, I'm not sure how to handle the changes, as the >> configuration in the feature is mostly an initial configuration but it >> could be changed by users afterward, so I'm kinda tempted to say that >> we would only register new properties and let existing ones as they >> are. > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
