On 1/10/10 7:41 PM, Sten Roger Sandvik wrote:
Hi.
It's only the packages that is required. You can either install the
configadmin bundle or let the startup environment export the cm.*
compendium packages. I do not think the package dependency can easily
be removed.
We could make it optional (or dynamic) and just test for its
availability at run time.
However, I don't understand why the exception below would be thrown at
all. If HTTP Service imports the package and it isn't available, then
HTTP Service should never start to execute and would never get a
CNFE...did I miss something?
-> richard
/srs
On Sun, Jan 10, 2010 at 11:46 PM, Hlusi, Jiri (NSN - FI/Tampere)
<[email protected]> wrote:
Hello,
If I try to run the Felix framework, release 2.0.1, with default content
(framework, obr, shell, shell-tui),
and install additionally "org.apache.felix.http.bundle-2.0.4.jar" on top
of that, the HTTP bundle won't
start (will not be resolved) due to missing dependency on CM packages
(Configuration Admin):
************
java.lang.ClassNotFoundException: *** Class
'org.osgi.service.cm.ManagedService' was
not found. Bundle 4 does not import package 'org.osgi.service.cm', nor
is the package
exported by any other bundle or available from the system class loader.
***
************
[ same behavior observed for both, "http.bundle" and "http.jetty"
bundles ]
The manual page
(http://felix.apache.org/site/apache-felix-http-service.html) says
configuration
via OSGi properties and Configuration Admin is possible, but it does not
imply that usage of
the latter one would be mandatory....
So far, I found two work-arounds to get the HTTP service running:
1) install confadmin-1.2.4
2) install osgi.cmpn.jar (update 4.2.0)
Problem with 1) is that overall I'm not intending to utilize
Configuration Admin for anything
useful, so I'd rather prefer not to have it loaded just because missing
interface (package
export).
Then, looking at 2), the osgi Alliance packages are tagged as "for
development
purpose" .... so I'm not sure is it a good idea to use thos in
production, and what
eventual side effects there might be.
Can anyone advise what would be the best way to move on?
Could the hard dependency on Configration Admin be removed
somehow in next update of the service?
Many thanks in advance!
br, Jiri
---------------------------------------------------------------------
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]
