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 <[email protected]>
> 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 <[email protected]>
> 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)
> >> <[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]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
