Le 29 déc. 08 à 06:35, Trejkaz a écrit :
Hi all.
I was attempting to follow the tutorial here:
http://felix.apache.org/site/combining-ipojo-and-configuration-admin.html
I'm using the latest release of Felix though, and it seems like the
current bundles available in OBR have a few problems...
From a clean install of felix-1.4.1...
$ java -jar bin/felix.jar
-> obr start "Apache Felix Configuration Admin Service"
Target resource(s):
-------------------
Apache Felix Configuration Admin Service (1.0.4)
Required resource(s):
---------------------
Servlet 2.1 API (1.0.0)
Apache Felix Declarative Services (1.0.6)
OSGi R4 Compendium Bundle (4.0.0)
Apache Felix Web Management Console (1.2.0)
Optional resource(s):
---------------------
Apache Felix Web Management Console (1.0.0)
(Immediate thoughts here... why is it forcing me to install the web
console when I really only wanted/needed the shell commands mentioned
in the tutorial? And why is it listing v1.0.0 of the web console as
optional when v1.2.0 is already required? And why is it installing
v1.0.0 despite having called it optional?)
I agree, there is an issue. The configuration admin bundle is
described as follows:
Requires:
service : (service=org.osgi.service.log.LogService)
service : (service=org.osgi.service.cm.ManagedService)
service : (service=org.osgi.service.cm.ManagedServiceFactory)
service : (service=org.osgi.service.cm.ConfigurationListener)
service : (service=org.apache.felix.cm.PersistenceManager)
package : (&(package=org.apache.felix.cm)(version>=1.0.0))
package : (&(package=org.apache.felix.cm.file)(version>=1.0.0))
package : (&(package=org.osgi.framework)(version>=1.3.0))
package : (&(package=org.osgi.service.cm)(version>=1.2.0))
Capabilities:
{service=org.apache.felix.cm.PersistenceManager,
service.description=Platform Filesystem Persistence Manager,
service.pid=org.apache.felix.cm.file.FilePersistenceManager,
service.vendor=Apache Software Foundation}
{service=org.osgi.service.cm.ConfigurationAdmin,
service.description=Configuration Admin Service Specification 1.2
Implementation, service.pid=org.apache.felix.cm.ConfigurationAdmin,
service.vendor=Apache Software Foundation}
{manifestversion=2, presentationname=Apache Felix Configuration
Admin Service, symbolicname=org.apache.felix.configadmin, version=1.0.4}
{package=org.apache.felix.cm.file,
uses:=org.osgi.framework,org.apache.felix.cm, version=1.0.0}
{package=org.apache.felix.cm, version=1.0.0}
{package=org.osgi.service.cm, uses:=org.osgi.framework,
version=1.2.0}
So despite that some requirements are optinal, OBR tries to revolve
them. I will try to understand from where comes the trouble.
Granted, it is quite possible I'm doing something wrong, as I only
started looking into OSGi less than a week ago. But it seems to me
the bundles in the repository might be a bit flaky.
Does anyone here have this working on the current version?
I have something close to you. But there is a not clean solution for
the time beeing:
obr deploy "Apache Felix Configuration Admin Service"
And then start the config admin bundle.
A side-question, since I'm making a post anyway (and most of this post
is stack traces...) I'm trying to make a system where I have a
Connection class with multiple implementations for different chat
protocols. I figured I would use @ServiceProperty on each of the
properties I care about for the service (host, port, username,
password, ...), ship no instances out of the box (thus removing the
need to use the XML metadata file at all) but have the user create
them through Configuration Admin. I am led to believe that such
configurations will be persistent, so next time the container starts
up, it should automatically call my @Validate method which will make
the connection connect.
Am I on the right track here?
Yes, you're on the right track.
There sure are a lot of hoops to jump
through just to get something working without having to use the actual
(awful, and inconvenient) OSGi API... though I'm glad I did the
tutorials for the native OSGi API, as it gives me an appreciation for
what iPOJO allows me to skip coding.
No, there is no OSGi-code, except for pushing configuration in the
configuration admin. But this service is quiet easy to use and with an
iPOJO dependency, you can avoid tracking the configuration admin
service.
Regards,
Clement
PS: I keep you psoted if I found a better way to deploy the
configuration admin from the OBR.
TX
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
