Thanks Simon, that did the job.
Ali.
Simon J Archer wrote:
Your problem lies in the use of the
ConfigurationAdmin's getConfiguration(String pid) API. This method
returns a Configuration for the bundle you're in. You should be using
ConfigurationAdmin's getConfiguration(String pid, String location)
method
instead. The second parameter is the location of the target bundle, but
I suggest that you create an anonymous Configuration by passing null as
the second parameter. An anonymous Configuration gets automatically
bound
to the bundle that owns the PID when it is registered.
Other comments:
- The ManagedService's
updated(Dictionary)
method might get passed null, so you must account for that. Check
the Javadoc.
- If you're using the Equinox 3.5
your
component class' activate method should NOT require a ComponentContext.
If you're not using, don't specify it in the declaration of the method.
Since you have bind/unbind methods for the ConfigurationAdmin service I
would guess that you don't need it.
I hope this helps,
Simon
Hi Simon.
Thanks for you detailed help, very much appreciated. I managed to get
around
that and now I am running into a different problem when I am trying to
update teh configuration in my managed service. I see the following in
my log:
Warn [4] Configuration for service.pid=test.bundle could not be bound
to
file:LogTest2_1.0.0.jar
initial@reference:file:org.eclipse.equinox.cm_1.0.100.v20090520-1800.jar/
What are the possible causes of this and where should I start looking
for
the issue? I have a simple Managed Service, LogTest2 bundle:
------- Activator of LogTest2 Bundle ------------------------
(snippet)
public void start(BundleContext context) throws Exception {
......
Properties properties = new Properties();
properties.put(Constants.SERVICE_PID, "test.bundle");
registration =
context.registerService(ManagedService.class.getName(),
this, properties);
.......
}
public void updated(Dictionary properties) throws
ConfigurationException
{
System.out.println("Configuration is being
updated...");
Integer newLogLevel = (Integer) properties.get("log-level");
String newLogLocation = (String) properties.get("log-location");
........
}
---------------------------------------------------------------------------------
And I have a bundle (called LogConfigurator) to update configuration
for
LogTest2 bundle:
-------my main Component for LogConfigurator -------------
public void setConfigAdmin(ConfigurationAdmin admin) {
this.admin = admin;
}
public void unsetConfigAdmin(ConfigurationAdmin admin) {
this.admin = null;
}
public void activate(ComponentContext context) {
try {
config = admin.getConfiguration("test.bundle");
if (null != config) {
Dictionary properties
= config.getProperties();
// this prints
out the location for LogConfigurator instead of LogTest2!
// which I guess
it means it hasn't found the LogTest2 bundle
System.out.println(config.getBundleLocation());
if (null == properties)
{
properties
= new Properties();
}
properties.put("log-level",
3);
config.update(properties);
System.out.println("Updated
configuration to log level 3");
}
} catch (IOException e) {
// TODO Auto-generated catch
block
e.printStackTrace();
}
}
--------------------------------------------------------------
The order in which I do these is that first I install and activate
Logtest2
and then I install and enable LogConfigurator. The println at the top
of
the "updated()" method is never called when LogConfigurator is
installed, which is consistent with the wrong bundle location that I
get
in LogConfigurator.
Thanks,
Ali.
P.S. the warning message that I mentioned earlier is when I reverse the
order of installations.
Simon J Archer wrote:
Ali,
I think the problem you're having is one of ordering. If your bundle
starts before the ConfigurationAdmin service is registered then you're
not going to find it. This is not a problem and is part of how OSGi
works.
There are a number of solutions:
1. Use Declarative Services (DS). This is by far the easiest approach
since
it removes the ordering problem entirely. I strongly recommend that you
use DS.
2. Use the ServiceTracker to track the ConfigurationAdmin service.
This
works in theory, but in practice is way harder to get right than you
might
imagine.
3. Register a ServiceListener to track the ConfigurationAdmin service.
This also works in theory, but in practice is more work that you'd care
to do. It's debatable whether this is easier or harder than using
the ServiceTracker.
See the attached zip that shows how to use DS to acquire a
ConfigurationAdmin
service.
I hope this helps,
Simon
Hello everyone.
I am trying to write a few simple examples with ConfigurationAdmin
service to familiarize myself with it but have a difficulty obtaining a
pointer to the service. I am running Equinox 3.5 and have deployed
org.eclipse.equinox.cm_1.0.100 bundle in my framework but still when I
try to get a reference to the ConfiguartionAdmin (via
context.getServiceReference(ConfigurationAdmin.class.getName()) ), I
get
a null pointer. Do I need to set any particular security settings?
Many thanks,
Ali.
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
|
