[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [virgo-dev] Configuration of bundles
|
Hi Peter
The *ERROR* below looks like a bug. If you would kindly raise a bugzilla and attach a properties file and steps to reproduce, that would be very helpful.
Virgo only scans the config directory on startup, so I don't understand the behaviour you are seeing in steps 6 and 7. Did you restart Virgo before each of these steps?
Regards,
Glyn
On 3 Nov 2010, at 06:05, Peter Lauri wrote:
Hi Dmitry and all :)
The thing that should simply work doesn't work for me :)
1. Stop virgo
2. No config anywhere
3. Start virgo (ManagedService.update was triggered with NULL, as expected)
4. Put configuration into VIRGO_HOME/pickup (ManagedServices.update was NOT triggered, WebUI configuration artifact visible, configuration reflected in Configuration Admin)
5. Modify config (ManagedServices.update was NOT triggered, WebUI configuration artifact visible, configuration reflected in Configuration Admin)
So, by just putting the configuration to pickup will not trigger the ManagedService.update method.
Each time I modify the configuration in the pickup directory I get the following:
[2010-11-03 07:56:10.479] Configuration Updater System.err *ERROR* Cannot use configuration pjotr.configtest for [org.osgi.service.cm.ManagedService, id=146, bundle=36]: Configuration bound to bundle file:lib/kernel/org.eclipse.virgo.kernel.deployer-2.1.0.RC1-incubation.jar
After that I played around a bit, and then I get it to work by doing this:
1. Stop virgo
2. Put the config into VIRGO_HOME/config
3. Start virgo (ManagedService.update was triggered with proper configuration, config visible in WebUI Configuration Admin)
4. Modify config file in VIRGO_HOME/config (ManagedService.update was NOT triggered, changes NOT reflected in WebUI Configuration Admin
5. Move config to VIRGO_HOME/pickup (ManagedService.update triggered, changed reflected in WebUI Configuration Admin)
6. Modify config file in VIRGO_HOME/config (ManagedServices.update triggered 2 TIMES, changes reflected in WebUI Configuration Admin)
7. Modify config file in VIRGO_HOME/config (ManagedServices.update triggered 2 TIMES, changes reflected in WebUI Configuration Admin)
However, this requires that I would need to restart virgo for each time I deploy a service that needs configuration.
Using the ConfigurationListener and ConfigurationAdmin worked fine, but that is not as "neat" as using ManagedService.
/Peter
On 2 nov 2010, at 21.02, Dmitry Sklyut wrote:
Simple answer is "Yes".
With the code sample that you provided, your config properties file must be named: "my_unique_pid.properties".
Drop that file into pickup and it will be deployed as ConfigurationAdmin configuration and your ManagedService will be updated with correct configuration.
You can also use a ConfigurationListener and postone publishing your service (not ManagedService) till configuration that you are looking for is available.
Dmitry
On Tue, Nov 2, 2010 at 2:56 PM, Peter Lauri <peter.lauri@xxxxxx<mailto:peter.lauri@xxxxxx>> wrote:
Hi,
I have a bundle that is providing a service that needs to be configured before it starts. As I have understood it there are two approaches, one is to use the ManagedService and one is to use the ConfigurationAdmin. However, how do this map to Virgo? If I put a properties file to "pickup" that will be deployed as a configuration artifact. Should that map directly to the ManagedService.update() call?
Hashtable<String, String> prop = new Hashtable<String, String>();
prop.put(Constants.SERVICE_PID, "my_unique_pid");
this.managedServiceRegistration = bundleContext.registerService(ManagedService.class.getName(), this, prop);
/Peter
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/virgo-dev
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/virgo-dev
<ATT00001..txt>