You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by "Hlusi, Jiri (NSN - FI/Tampere)" <ji...@nsn.com> on 2010/01/10 23:46:49 UTC
Felix HTTP implementation having hard dependency on Config Admin
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
Re: Felix HTTP implementation having hard dependency on Config Admin
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/12/10 6:42, Derek Baum wrote:
> How about addressing this by embedding the ConfigAdmin API in
> felix-http.jetty bundle?
>
> All I have done is add org.osgi.service.cm (the ConfigAdmin API package) to
> each of Export-Package, Private-Package and Import-Package to
> http/jetty/pom.xml:
>
> <Export-Package>
>
> org.apache.felix.http.api;version=${pom.version},
> org.osgi.service.http,
>
> javax.servlet.*;version=2.5;-split-package:=merge-first,
> *org.osgi.service.cm*
> </Export-Package>
> <Private-Package>
> org.apache.felix.http.base.*,
> org.apache.felix.http.jetty.*,
> org.mortbay.*;-split-package:=merge-first,
> *org.osgi.service.cm*
>
I don't believe it is necessary to specify it in <Private-Package> too,
since <Export-Package> will cause it to embed the package.
> </Private-Package>
> <Import-Package>
> javax.net.ssl; javax.security.cert;
> javax.xml.parsers; org.xml.sax;
> org.xml.sax.helpers;
> org.slf4j;resolution:=optional,
> *org.osgi.service.cm*,
> *;resolution:=optional
>
The original issue was that the cm package was NOT optional, but the
above clause marks all other dependencies as optional for some unknown
reason, which obviously led to the cm package being incorrectly marked
as optional. At a minimum, cm should be explicitly listed as a
non-optional dependency. However, I wonder if this resolution directive
on * isn't just a mistake.
Otherwise, your proposal to export and import the API also makes
sense...the age-old debate... :-)
-> richard
> </Import-Package>
>
> Adding org.osgi.service.cm to Private-Package causes the ConfigAdmin API to
> be embedded in the felix.http.jetty bundle.
> Exporting the org.osgi.service.cm package means that it can be resolved
> against a better matching bundle, so the embedded version is just used as a
> default.
>
> The resulting manifest looks like this (BND has inserted the
> org.osgi.service.cm import and export versions):
>
> Export-Package:
> org.apache.felix.http.api;uses:="javax.servlet,org.osgi.service.http";version="2.0.5.SNAPSHOT"
>
> org.osgi.service.http;uses:="javax.servlet.http,javax.servlet";version="1.2"
> javax.servlet.resources;version="2.5"
> javax.servlet;version="2.5"
> javax.servlet.jsp.resources;version="2.5"
> javax.servlet.http;uses:="javax.servlet";version="2.5"
> org.osgi.service.cm;uses:="org.osgi.framework";version="1.2"
> Import-Package: javax.net.ssl;resolution:=optional
> ....
> org.osgi.service.cm;version="1.2"
>
> The resulting bundle is< 1% larger due to embedding the ConfigAdmin API.
>
> Derek
>
> 2010/1/12 Sten Roger Sandvik<sr...@x3m.com>
>
>
>> Created a JIRA task (https://issues.apache.org/jira/browse/FELIX-1978) for
>> this.
>>
>> On Mon, Jan 11, 2010 at 10:26 PM, Felix Meschberger<fm...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I fear, the problem is
>>>
>>> public final class JettyService
>>> implements ManagedService, Runnable
>>>
>>> Thus, if the Configuration Admin package cannot be imported, the
>>> JettyService cannot be instantiated and thus not be started.
>>>
>>> The fix is probably to created a small (anonymous or inner) class which
>>> implements the ManagedService interface to be instantiated in the
>>> JettyService start (but catching any Errors) method.
>>>
>>> The ManagedService itself would just forward the updated call to the
>>> JettyServide instance.
>>>
>>> Thus instead of :
>>>
>>> this.configServiceReg = this.context.registerService(
>>> ManagedService.class.getName(), this, props);
>>>
>>> It would be
>>>
>>> try {
>>> Object srv = new ManagedService() {
>>> updated(Dictionary props) {
>>> JettyService.this.updated(props);
>>> }
>>> };
>>> this.configServiceReg = this.context.registerService(
>>> ManagedService.class.getName(), this, props);
>>> } catch (Throwable t) {
>>> ...
>>> }
>>>
>>>
>>> Regards
>>> Felix
>>>
>>> On 11.01.2010 01:41, 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.
>>>>
>>>> /srs
>>>>
>>>> On Sun, Jan 10, 2010 at 11:46 PM, Hlusi, Jiri (NSN - FI/Tampere)
>>>> <ji...@nsn.com> 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: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix HTTP implementation having hard dependency on Config Admin
Posted by Derek Baum <de...@paremus.com>.
How about addressing this by embedding the ConfigAdmin API in
felix-http.jetty bundle?
All I have done is add org.osgi.service.cm (the ConfigAdmin API package) to
each of Export-Package, Private-Package and Import-Package to
http/jetty/pom.xml:
<Export-Package>
org.apache.felix.http.api;version=${pom.version},
org.osgi.service.http,
javax.servlet.*;version=2.5;-split-package:=merge-first,
*org.osgi.service.cm*
</Export-Package>
<Private-Package>
org.apache.felix.http.base.*,
org.apache.felix.http.jetty.*,
org.mortbay.*;-split-package:=merge-first,
*org.osgi.service.cm*
</Private-Package>
<Import-Package>
javax.net.ssl; javax.security.cert;
javax.xml.parsers; org.xml.sax;
org.xml.sax.helpers;
org.slf4j;resolution:=optional,
*org.osgi.service.cm*,
*;resolution:=optional
</Import-Package>
Adding org.osgi.service.cm to Private-Package causes the ConfigAdmin API to
be embedded in the felix.http.jetty bundle.
Exporting the org.osgi.service.cm package means that it can be resolved
against a better matching bundle, so the embedded version is just used as a
default.
The resulting manifest looks like this (BND has inserted the
org.osgi.service.cm import and export versions):
Export-Package:
org.apache.felix.http.api;uses:="javax.servlet,org.osgi.service.http";version="2.0.5.SNAPSHOT"
org.osgi.service.http;uses:="javax.servlet.http,javax.servlet";version="1.2"
javax.servlet.resources;version="2.5"
javax.servlet;version="2.5"
javax.servlet.jsp.resources;version="2.5"
javax.servlet.http;uses:="javax.servlet";version="2.5"
org.osgi.service.cm;uses:="org.osgi.framework";version="1.2"
Import-Package: javax.net.ssl;resolution:=optional
....
org.osgi.service.cm;version="1.2"
The resulting bundle is < 1% larger due to embedding the ConfigAdmin API.
Derek
2010/1/12 Sten Roger Sandvik <sr...@x3m.com>
> Created a JIRA task (https://issues.apache.org/jira/browse/FELIX-1978) for
> this.
>
> On Mon, Jan 11, 2010 at 10:26 PM, Felix Meschberger <fm...@gmail.com>
> wrote:
> > Hi,
> >
> > I fear, the problem is
> >
> > public final class JettyService
> > implements ManagedService, Runnable
> >
> > Thus, if the Configuration Admin package cannot be imported, the
> > JettyService cannot be instantiated and thus not be started.
> >
> > The fix is probably to created a small (anonymous or inner) class which
> > implements the ManagedService interface to be instantiated in the
> > JettyService start (but catching any Errors) method.
> >
> > The ManagedService itself would just forward the updated call to the
> > JettyServide instance.
> >
> > Thus instead of :
> >
> > this.configServiceReg = this.context.registerService(
> > ManagedService.class.getName(), this, props);
> >
> > It would be
> >
> > try {
> > Object srv = new ManagedService() {
> > updated(Dictionary props) {
> > JettyService.this.updated(props);
> > }
> > };
> > this.configServiceReg = this.context.registerService(
> > ManagedService.class.getName(), this, props);
> > } catch (Throwable t) {
> > ...
> > }
> >
> >
> > Regards
> > Felix
> >
> > On 11.01.2010 01:41, 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.
> >>
> >> /srs
> >>
> >> On Sun, Jan 10, 2010 at 11:46 PM, Hlusi, Jiri (NSN - FI/Tampere)
> >> <ji...@nsn.com> 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: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Felix HTTP implementation having hard dependency on Config Admin
Posted by Sten Roger Sandvik <sr...@x3m.com>.
Created a JIRA task (https://issues.apache.org/jira/browse/FELIX-1978) for this.
On Mon, Jan 11, 2010 at 10:26 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> I fear, the problem is
>
> public final class JettyService
> implements ManagedService, Runnable
>
> Thus, if the Configuration Admin package cannot be imported, the
> JettyService cannot be instantiated and thus not be started.
>
> The fix is probably to created a small (anonymous or inner) class which
> implements the ManagedService interface to be instantiated in the
> JettyService start (but catching any Errors) method.
>
> The ManagedService itself would just forward the updated call to the
> JettyServide instance.
>
> Thus instead of :
>
> this.configServiceReg = this.context.registerService(
> ManagedService.class.getName(), this, props);
>
> It would be
>
> try {
> Object srv = new ManagedService() {
> updated(Dictionary props) {
> JettyService.this.updated(props);
> }
> };
> this.configServiceReg = this.context.registerService(
> ManagedService.class.getName(), this, props);
> } catch (Throwable t) {
> ...
> }
>
>
> Regards
> Felix
>
> On 11.01.2010 01:41, 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.
>>
>> /srs
>>
>> On Sun, Jan 10, 2010 at 11:46 PM, Hlusi, Jiri (NSN - FI/Tampere)
>> <ji...@nsn.com> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix HTTP implementation having hard dependency on Config Admin
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
I fear, the problem is
public final class JettyService
implements ManagedService, Runnable
Thus, if the Configuration Admin package cannot be imported, the
JettyService cannot be instantiated and thus not be started.
The fix is probably to created a small (anonymous or inner) class which
implements the ManagedService interface to be instantiated in the
JettyService start (but catching any Errors) method.
The ManagedService itself would just forward the updated call to the
JettyServide instance.
Thus instead of :
this.configServiceReg = this.context.registerService(
ManagedService.class.getName(), this, props);
It would be
try {
Object srv = new ManagedService() {
updated(Dictionary props) {
JettyService.this.updated(props);
}
};
this.configServiceReg = this.context.registerService(
ManagedService.class.getName(), this, props);
} catch (Throwable t) {
...
}
Regards
Felix
On 11.01.2010 01:41, 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.
>
> /srs
>
> On Sun, Jan 10, 2010 at 11:46 PM, Hlusi, Jiri (NSN - FI/Tampere)
> <ji...@nsn.com> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix HTTP implementation having hard dependency on Config Admin
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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)
> <ji...@nsn.com> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Felix HTTP implementation having hard dependency on Config Admin
Posted by "Hlusi, Jiri (NSN - FI/Tampere)" <ji...@nsn.com>.
Actually, I just checked the HTTP bundle manifest, and the
CM package import should, indeed, be set to optional already:
>> org.osgi.service.cm;resolution:=optional;version="1.2"
Despite of that, the package start will fail.
BTW, unless I misunderstood something, this appears to
be the case for SCR as well (import optional, yet will
fail until CM admin or OSGI compendium is loaded). I must
be doing something wrong...
I'm actually rather new to the OSGi and Felix in particular.
Can somebody tell how to make the startup environment export
cm.* packages as advised below by Mike?
Many thanks again!
br, Jiri
>-----Original Message-----
>From: ext Mike Haney [mailto:txmikester@gmail.com]
>Sent: 11 January, 2010 02:52
>To: users@felix.apache.org
>Subject: Re: Felix HTTP implementation having hard dependency
>on Config Admin
>
>Couldn't the package imports be set to optional?
>
>On Jan 10, 2010 6:42 PM, "Sten Roger Sandvik" <sr...@x3m.com> 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.
>
>/srs
>
>On Sun, Jan 10, 2010 at 11:46 PM, Hlusi, Jiri (NSN -
>FI/Tampere) < jiri.hlusi@nsn.com> wrote: > Hell...
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix HTTP implementation having hard dependency on Config Admin
Posted by Mike Haney <tx...@gmail.com>.
Couldn't the package imports be set to optional?
On Jan 10, 2010 6:42 PM, "Sten Roger Sandvik" <sr...@x3m.com> 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.
/srs
On Sun, Jan 10, 2010 at 11:46 PM, Hlusi, Jiri (NSN - FI/Tampere) <
jiri.hlusi@nsn.com> wrote: > Hell...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix HTTP implementation having hard dependency on Config Admin
Posted by Sten Roger Sandvik <sr...@x3m.com>.
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.
/srs
On Sun, Jan 10, 2010 at 11:46 PM, Hlusi, Jiri (NSN - FI/Tampere)
<ji...@nsn.com> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org