You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Vinicius Carvalho <vi...@caravelatech.com> on 2009/01/29 14:48:37 UTC
ServiceTracker never gets called
Hello all, sorry for always comming back on the same subject, but tomorrow
is our deadline, and even we got some progress on the osgi front with spring
(we now have services and dependency injection working). Nothing seems to
work on the HttpService integration.
We tried almost everything to get equinox running inside a servlet
container. The documentation on equinox servlet bridge is almost inexistent.
We are not using their servletbridge since it starts the osgi container and
that is something we are doing in our code (following the sling approach)
What seems to be happening is that any service tracker registered to
HttpService never gets called, ever... We've seen this on the OsgiManager
class, and now we decided to drop our own little servlet bundle:
public class Activator implements BundleActivator {
private ServiceTracker httpServiceTracker;
public void start(BundleContext context) throws Exception {
httpServiceTracker = new HttpServiceTracker(context);
httpServiceTracker.open();
}
public void stop(BundleContext arg0) throws Exception {
httpServiceTracker.close();
httpServiceTracker = null;
}
private class HttpServiceTracker extends ServiceTracker {
public HttpServiceTracker(BundleContext context) {
super(context, HttpService.class.getName(), null);
}
public Object addingService(ServiceReference reference) {
HttpService httpService = (HttpService)
context.getService(reference);
try {
httpService.registerServlet("/dummy", new DummyServlet(),
null, null); //$NON-NLS-1$
} catch (Exception e) {
e.printStackTrace();
}
return httpService;
}
public void removedService(ServiceReference reference, Object
service) {
HttpService httpService = (HttpService) service;
httpService.unregister("/dummy"); //$NON-NLS-1$
super.removedService(reference, service);
}
}
}
Well, the adding servlet never gets called :(
Here how we start the felix container:
public void init() throws ServletException {
ServletContextResourceProvider rp = new
ServletContextResourceProvider(getServletContext());
Logger logger = new ServletContextLogger(getServletContext());
Map<Object, Object> props = loadProperties();
this.osl = new OSL(rp,props,logger);
this.delegatee = new HttpServiceServlet();
this.delegatee.init(getServletConfig());
super.init();
}
public class OSL implements BundleActivator {
private Felix felix;
private ReadWriteLock felixLock;
private ResourceProvider resourceProvider;
private Logger logger;
private BundleActivator httpServiceActivator;
public OSL(ResourceProvider rp, Map<Object, Object> props, Logger
logger){
this.resourceProvider = rp;
this.logger = logger;
List<BundleActivator> activators = new ArrayList<BundleActivator>();
activators.add(this);
activators.add(new BootstrapInstaller(logger,rp));
props.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, activators);
Felix tmpFelix = new Felix(props);
try {
tmpFelix.start();
this.felix = tmpFelix;
} catch (Exception e) {
e.printStackTrace();
}
}
public void start(BundleContext context) throws Exception {
this.httpServiceActivator = new Activator();
this.httpServiceActivator.start(context);
}
As you can see, we are starting the Httpservice ourselves, we tried to not
do so and pack it with the other bundles, but the effect is the same (do not
call the addingservice)
After the complete startup we have these services:
System Bundle (0) provides:
---------------------------
org.osgi.service.startlevel.StartLevel
org.osgi.service.packageadmin.PackageAdmin
org.osgi.service.http.HttpService
So I guess the HttpService is up and running.
Is there anything else that we could do? Any other point to look at, replace
class, packaging format, anything please. Tomorrow if we don't present at
least one servlet (we needed at least the GWT-RPC working but one servlet
should do it), we may have to drop osgi for good, and that's something we
are really not willing to do :(
Regards
Re: ServiceTracker never gets called
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/1/30 Vinicius Carvalho <vi...@caravelatech.com>
> Wow!!! Finally :D
>
> Thanks all, I finally got it working :D
>
> We still have the HttpService activator being called by system bundle. but
> follwoing Stuart's and Neil's advice, just adding org.osgi.http.service to
> the org.osgi.framework.system.packages.extra did the trick :)
>
excellent news!
btw, when you have a situation where a bundle can't see something but you
can
see it in the console (like a service) then it's worth thinking about class
visibility,
especially when you're embedding the framework and accessing services from
both inside and outside.
Now my bundle that register a servlet have access to the httpservice
>
> Thanks a bunch :D
>
> Regards
>
> On Thu, Jan 29, 2009 at 6:02 PM, Vinicius Carvalho <
> vinicius@caravelatech.com> wrote:
>
> >
> >
> > On Thu, Jan 29, 2009 at 5:30 PM, Neil Bartlett <njbartlett@gmail.com
> >wrote:
> >
> >> Further to Stuart's email, it would be interesting to see how your
> >> tracking bundle is getting the HttpService class. Do you import the
> >> org.osgi.service.http package using Import-Package? If so, which
> >> bundle is supplying the export?
> >
> >
> > Well, the system-bundle, at least I think from the console output:
> >
> > System Bundle (0) provides:
> > ---------------------------
> > objectClass = org.osgi.service.startlevel.StartLevel
> > service.id = 1
> > ----
> > objectClass = org.osgi.service.packageadmin.PackageAdmin
> > service.id = 2
> > ----
> > objectClass = org.osgi.service.http.HttpService
> > service.description = Equinox Servlet Bridge
> > service.id = 39
> > service.vendor = Eclipse.org
> >
> >
> >>
> >>
> >> It seems like you're using the Equinox servlet bridge, which has a
> >> parameter "extendedFrameworkExports". You set this in the web.xml of
> >> the WAR and it should contain a list of packages to be exported by the
> >> system bundle. Then they can be imported in the usual way by any other
> >> bundle.
> >
> >
> > Well, that's the point, we are not using the ServletBridge Servlet
> > (org.eclipse.equinox.servletbridge.BridgeServlet)
> >
> > We have our own.
> >
> >
> >>
> >>
> >> You may have better luck asking about this in the Equinox newgroups or
> >> mailing lists, since your problem seems to be quite specific to the
> >> Equinox servlet bridge rather than Felix or OSGi in general.
> >>
> >> Regards
> >> Neil
> >>
> >
> > Yeah, I'm giving a try there as well, sorry, folks here seems to be more
> > helpful
> >
> > Regards
> >
> >>
> >> On Thu, Jan 29, 2009 at 7:16 PM, Stuart McCulloch <mc...@gmail.com>
> >> wrote:
> >> > 2009/1/30 Vinicius Carvalho <vi...@caravelatech.com>
> >> >
> >> >> Well, we got stuck again :(
> >> >>
> >> >> Here's the dilema:
> >> >>
> >> >> We need the ProxyServlet to handle requests, so it is loaded from
> >> >> webappclassloader, so we need the equinox jar in our web-inf/lib
> >> >> We need the Activator from equinox to get started outside the
> >> >> webappclassloader, it has to be loaded by context classloader
> >> >>
> >> >> So we have this:
> >> >>
> >> >> WEB-INF/
> >> >> lib/
> >> >> equinox-servlet.jar
> >> >>
> >> >> bundles/
> >> >> equinox-servlet.jar
> >> >>
> >> >>
> >> >> Now, the problem happens here:
> >> >>
> >> >> ProxyServlet (from equinox) calls
> >> >> Activator.addProxyServlet(this)
> >> >>
> >> >> The method:
> >> >>
> >> >> static synchronized void addProxyServlet(ProxyServlet proxyServlet) {
> >> >> ServiceRegistration registration = null;
> >> >> if (context != null)
> >> >> registration = registerHttpService(proxyServlet);
> >> >>
> >> >> serviceRegistrations.put(proxyServlet, registration);
> >> >> }
> >> >>
> >> >>
> >> >> Ok, of course the damn context will be null, ProxyServlet was loaded
> by
> >> >> webappclassloader whereas the Activator was started by our
> >> >> contextclassloader
> >> >>
> >> >> So, no way we get HttpService registred this way.
> >> >>
> >> >> The other way around:
> >> >>
> >> >> Having our servlet starting equinox Activator:
> >> >>
> >> >> Well now we do have an HttpService installed as service but... It
> comes
> >> >> from
> >> >> a differente classloader :( and can't be used by our bundles.
> >> >>
> >> >> I guess we hit a dead end here? Is there a solution for this?
> >> >>
> >> >
> >> > if you're embedding an OSGi framework inside another container (like a
> >> > web-app) and want to use the same container classloader for a
> particular
> >> > package then there are a couple of framework properties you can use to
> >> > either:
> >> >
> >> > a) expose packages through the system bundle
> >> > (org.osgi.framework.system.packages)
> >> >
> >> > or
> >> >
> >> > b) expose packages through bootdelegation
> >> > (org.osgi.framework.bootdelegation)
> >> >
> >> > your bundles will then get wired to the container classloader (not the
> >> local
> >> > bundle) for the named package(s)
> >> >
> >> > this blog has a good write up of both approaches:
> >> >
> >> >
> >> >
> >>
> http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/
> >> >
> >> > HTH - I'd write a bit more but it's getting late here...
> >> >
> >> >
> >> >> Regards
> >> >>
> >> >>
> >> >>
> >> >> On Thu, Jan 29, 2009 at 3:25 PM, Richard S. Hall <
> heavy@ungoverned.org
> >> >> >wrote:
> >> >>
> >> >> > Vinicius Carvalho wrote:
> >> >> >
> >> >> >> Sorry for the mess. Neil, I was just mentioning that you left a
> post
> >> at
> >> >> my
> >> >> >> twitter a month ago. I read both books, and they are equally
> great.
> >> Some
> >> >> >> things better in one, others in other. I do recommend everyone to
> >> get
> >> >> both
> >> >> >> of em :)
> >> >> >>
> >> >> >>
> >> >> >
> >> >> > Don't worry, it's just Neil (he's British). ;-)
> >> >> >
> >> >> > -> richard
> >> >> >
> >> >> > On Thu, Jan 29, 2009 at 3:01 PM, Richard S. Hall <
> >> heavy@ungoverned.org
> >> >> >> >wrote:
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>> Neil Bartlett wrote:
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>> Hi Vinicius,
> >> >> >>>>
> >> >> >>>> Glad to help, and thanks for your kind comments about my book.
> >> >> >>>>
> >> >> >>>> However I think it's the authors of "OSGi in Action" who are
> >> asking
> >> >> >>>> for a book review at the moment, since they have just released
> >> some
> >> >> >>>> chapters for early access. They are on this mailing list so can
> >> >> >>>> probably clarify. My book is "OSGi in Practice". Yes, these two
> >> titles
> >> >> >>>> are confusingly similar... my defence is that I started writing
> my
> >> >> >>>> book first!
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>> We aren't asking for a book review, but there was some review
> >> recently
> >> >> on
> >> >> >>> DZone about the early access release from a few weeks back.
> >> >> >>>
> >> >> >>> Regarding the titles, we didn't really choose the title per se,
> but
> >> "X
> >> >> in
> >> >> >>> Action" and even "X in Practice" titles are both Manning
> Publishing
> >> >> >>> series
> >> >> >>> books from what I understand. So you be the judge. ;-)
> >> >> >>>
> >> >> >>> -> richard
> >> >> >>>
> >> >> >>> Kind regards,
> >> >> >>>
> >> >> >>>
> >> >> >>>> Neil
> >> >> >>>>
> >> >> >>>> On Thu, Jan 29, 2009 at 4:45 PM, Vinicius Carvalho
> >> >> >>>> <vi...@caravelatech.com> wrote:
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>> Bullseye! Thanks Neil. I've tested and got a ClassCastException
> >> ...
> >> >> >>>>>
> >> >> >>>>> We'll look into our code and check why is this happening. We've
> >> just
> >> >> >>>>> tried,
> >> >> >>>>> and in a debug breakpoint we've seen that the service returned
> >> by:
> >> >> >>>>> HttpService httpService = (HttpService)
> >> >> >>>>> context.getService(reference);
> >> >> >>>>>
> >> >> >>>>> Was indeed HttpServiceImpl, I guess we have a classloader
> >> problem. We
> >> >> >>>>> have
> >> >> >>>>> the equinox servletbridge inside webinf/lib, hence it's loaded
> by
> >> >> >>>>> WebApplicationClassLoader. Since this bundle is loaded by
> >> >> >>>>> ContextClassLoader
> >> >> >>>>> that might be the problem, we don't know.
> >> >> >>>>>
> >> >> >>>>> I'll look into it. Thanks a lot for your help, it gave us hope
> >> again
> >> >> :)
> >> >> >>>>>
> >> >> >>>>> I owe you a book review (from your message at twitter.com).
> I've
> >> >> >>>>> finished
> >> >> >>>>> you book btw, best chapter is chapter 6 (concurrency is a
> subject
> >> >> that
> >> >> >>>>> is
> >> >> >>>>> not very well explained in most books, which is a shame since
> it
> >> lead
> >> >> >>>>> to
> >> >> >>>>> really annoying problems) Promise to write a few lines of
> revuew
> >> to
> >> >> you
> >> >> >>>>> soon.
> >> >> >>>>>
> >> >> >>>>> Regards
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> On Thu, Jan 29, 2009 at 11:57 AM, Neil Bartlett <
> >> >> njbartlett@gmail.com
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>>> wrote:
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>>> It's possible that the HttpService published in the service
> >> registry
> >> >> >>>>>> is not compatible with your bundle that is trying to track it.
> >> This
> >> >> >>>>>> could happen if you have multiple bundles exporting the
> >> >> >>>>>> org.osgi.service.http package, or if your tracking bundle has
> >> >> somehow
> >> >> >>>>>> included the org.osgi.service.http package instead of
> importing
> >> it.
> >> >> >>>>>>
> >> >> >>>>>> To check if this is the case, try changing the start() method
> of
> >> >> your
> >> >> >>>>>> Activator to call httpServiceTracker.open(true) rather than
> just
> >> >> >>>>>> httpServiceTracker.open(). This will force the tracker to find
> >> all
> >> >> >>>>>> HttpServices, even the incompatible ones. Of course you will
> >> soon
> >> >> get
> >> >> >>>>>> a ClassCastException when you try to use the returned service,
> >> so
> >> >> you
> >> >> >>>>>> need to fix the underlying problem. Doing this will simply
> tell
> >> you
> >> >> if
> >> >> >>>>>> that is indeed the problem.
> >> >> >>>>>>
> >> >> >>>>>> Regards,
> >> >> >>>>>> Neil
> >> >> >>>>>>
> >> >> >>>>>> On Thu, Jan 29, 2009 at 1:48 PM, Vinicius Carvalho
> >> >> >>>>>> <vi...@caravelatech.com> wrote:
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>> Hello all, sorry for always comming back on the same subject,
> >> but
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>> tomorrow
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>> is our deadline, and even we got some progress on the osgi
> >> front
> >> >> with
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>> spring
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>> (we now have services and dependency injection working).
> >> Nothing
> >> >> >>>>>>> seems
> >> >> >>>>>>> to
> >> >> >>>>>>> work on the HttpService integration.
> >> >> >>>>>>>
> >> >> >>>>>>> We tried almost everything to get equinox running inside a
> >> servlet
> >> >> >>>>>>> container. The documentation on equinox servlet bridge is
> >> almost
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>> inexistent.
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>> We are not using their servletbridge since it starts the osgi
> >> >> >>>>>>> container
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>> and
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>> that is something we are doing in our code (following the
> sling
> >> >> >>>>>>> approach)
> >> >> >>>>>>>
> >> >> >>>>>>> What seems to be happening is that any service tracker
> >> registered
> >> >> to
> >> >> >>>>>>> HttpService never gets called, ever... We've seen this on the
> >> >> >>>>>>> OsgiManager
> >> >> >>>>>>> class, and now we decided to drop our own little servlet
> >> bundle:
> >> >> >>>>>>>
> >> >> >>>>>>> public class Activator implements BundleActivator {
> >> >> >>>>>>> private ServiceTracker httpServiceTracker;
> >> >> >>>>>>>
> >> >> >>>>>>> public void start(BundleContext context) throws Exception {
> >> >> >>>>>>> httpServiceTracker = new HttpServiceTracker(context);
> >> >> >>>>>>> httpServiceTracker.open();
> >> >> >>>>>>>
> >> >> >>>>>>> }
> >> >> >>>>>>>
> >> >> >>>>>>> public void stop(BundleContext arg0) throws Exception {
> >> >> >>>>>>> httpServiceTracker.close();
> >> >> >>>>>>> httpServiceTracker = null;
> >> >> >>>>>>> }
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>> private class HttpServiceTracker extends ServiceTracker {
> >> >> >>>>>>>
> >> >> >>>>>>> public HttpServiceTracker(BundleContext context) {
> >> >> >>>>>>> super(context, HttpService.class.getName(), null);
> >> >> >>>>>>> }
> >> >> >>>>>>>
> >> >> >>>>>>> public Object addingService(ServiceReference reference)
> {
> >> >> >>>>>>> HttpService httpService = (HttpService)
> >> >> >>>>>>> context.getService(reference);
> >> >> >>>>>>> try {
> >> >> >>>>>>> httpService.registerServlet("/dummy", new
> >> >> >>>>>>> DummyServlet(),
> >> >> >>>>>>> null, null); //$NON-NLS-1$
> >> >> >>>>>>> } catch (Exception e) {
> >> >> >>>>>>> e.printStackTrace();
> >> >> >>>>>>> }
> >> >> >>>>>>> return httpService;
> >> >> >>>>>>> }
> >> >> >>>>>>>
> >> >> >>>>>>> public void removedService(ServiceReference reference,
> >> Object
> >> >> >>>>>>> service) {
> >> >> >>>>>>> HttpService httpService = (HttpService) service;
> >> >> >>>>>>> httpService.unregister("/dummy"); //$NON-NLS-1$
> >> >> >>>>>>> super.removedService(reference, service);
> >> >> >>>>>>> }
> >> >> >>>>>>> }
> >> >> >>>>>>> }
> >> >> >>>>>>>
> >> >> >>>>>>> Well, the adding servlet never gets called :(
> >> >> >>>>>>>
> >> >> >>>>>>> Here how we start the felix container:
> >> >> >>>>>>>
> >> >> >>>>>>> public void init() throws ServletException {
> >> >> >>>>>>> ServletContextResourceProvider rp = new
> >> >> >>>>>>> ServletContextResourceProvider(getServletContext());
> >> >> >>>>>>> Logger logger = new
> >> ServletContextLogger(getServletContext());
> >> >> >>>>>>> Map<Object, Object> props = loadProperties();
> >> >> >>>>>>> this.osl = new OSL(rp,props,logger);
> >> >> >>>>>>> this.delegatee = new HttpServiceServlet();
> >> >> >>>>>>> this.delegatee.init(getServletConfig());
> >> >> >>>>>>>
> >> >> >>>>>>> super.init();
> >> >> >>>>>>> }
> >> >> >>>>>>>
> >> >> >>>>>>> public class OSL implements BundleActivator {
> >> >> >>>>>>>
> >> >> >>>>>>> private Felix felix;
> >> >> >>>>>>> private ReadWriteLock felixLock;
> >> >> >>>>>>> private ResourceProvider resourceProvider;
> >> >> >>>>>>> private Logger logger;
> >> >> >>>>>>> private BundleActivator httpServiceActivator;
> >> >> >>>>>>>
> >> >> >>>>>>> public OSL(ResourceProvider rp, Map<Object, Object> props,
> >> Logger
> >> >> >>>>>>> logger){
> >> >> >>>>>>> this.resourceProvider = rp;
> >> >> >>>>>>> this.logger = logger;
> >> >> >>>>>>> List<BundleActivator> activators = new
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>> ArrayList<BundleActivator>();
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>> activators.add(this);
> >> >> >>>>>>> activators.add(new BootstrapInstaller(logger,rp));
> >> >> >>>>>>> props.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>> activators);
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>> Felix tmpFelix = new Felix(props);
> >> >> >>>>>>> try {
> >> >> >>>>>>> tmpFelix.start();
> >> >> >>>>>>> this.felix = tmpFelix;
> >> >> >>>>>>> } catch (Exception e) {
> >> >> >>>>>>> e.printStackTrace();
> >> >> >>>>>>> }
> >> >> >>>>>>> }
> >> >> >>>>>>>
> >> >> >>>>>>> public void start(BundleContext context) throws Exception {
> >> >> >>>>>>> this.httpServiceActivator = new Activator();
> >> >> >>>>>>> this.httpServiceActivator.start(context);
> >> >> >>>>>>>
> >> >> >>>>>>> }
> >> >> >>>>>>>
> >> >> >>>>>>> As you can see, we are starting the Httpservice ourselves, we
> >> tried
> >> >> >>>>>>> to
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>> not
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>> do so and pack it with the other bundles, but the effect is
> the
> >> >> same
> >> >> >>>>>>> (do
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>> not
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>> call the addingservice)
> >> >> >>>>>>>
> >> >> >>>>>>> After the complete startup we have these services:
> >> >> >>>>>>>
> >> >> >>>>>>> System Bundle (0) provides:
> >> >> >>>>>>> ---------------------------
> >> >> >>>>>>> org.osgi.service.startlevel.StartLevel
> >> >> >>>>>>> org.osgi.service.packageadmin.PackageAdmin
> >> >> >>>>>>> org.osgi.service.http.HttpService
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>> So I guess the HttpService is up and running.
> >> >> >>>>>>>
> >> >> >>>>>>> Is there anything else that we could do? Any other point to
> >> look
> >> >> at,
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>> replace
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>> class, packaging format, anything please. Tomorrow if we
> don't
> >> >> >>>>>>> present
> >> >> >>>>>>> at
> >> >> >>>>>>> least one servlet (we needed at least the GWT-RPC working but
> >> one
> >> >> >>>>>>> servlet
> >> >> >>>>>>> should do it), we may have to drop osgi for good, and that's
> >> >> >>>>>>> something
> >> >> >>>>>>> we
> >> >> >>>>>>> are really not willing to do :(
> >> >> >>>>>>>
> >> >> >>>>>>> Regards
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>>> 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
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Cheers, Stuart
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >
>
--
Cheers, Stuart
Re: ServiceTracker never gets called
Posted by Vinicius Carvalho <vi...@caravelatech.com>.
Wow!!! Finally :D
Thanks all, I finally got it working :D
We still have the HttpService activator being called by system bundle. but
follwoing Stuart's and Neil's advice, just adding org.osgi.http.service to
the org.osgi.framework.system.packages.extra did the trick :)
Now my bundle that register a servlet have access to the httpservice
Thanks a bunch :D
Regards
On Thu, Jan 29, 2009 at 6:02 PM, Vinicius Carvalho <
vinicius@caravelatech.com> wrote:
>
>
> On Thu, Jan 29, 2009 at 5:30 PM, Neil Bartlett <nj...@gmail.com>wrote:
>
>> Further to Stuart's email, it would be interesting to see how your
>> tracking bundle is getting the HttpService class. Do you import the
>> org.osgi.service.http package using Import-Package? If so, which
>> bundle is supplying the export?
>
>
> Well, the system-bundle, at least I think from the console output:
>
> System Bundle (0) provides:
> ---------------------------
> objectClass = org.osgi.service.startlevel.StartLevel
> service.id = 1
> ----
> objectClass = org.osgi.service.packageadmin.PackageAdmin
> service.id = 2
> ----
> objectClass = org.osgi.service.http.HttpService
> service.description = Equinox Servlet Bridge
> service.id = 39
> service.vendor = Eclipse.org
>
>
>>
>>
>> It seems like you're using the Equinox servlet bridge, which has a
>> parameter "extendedFrameworkExports". You set this in the web.xml of
>> the WAR and it should contain a list of packages to be exported by the
>> system bundle. Then they can be imported in the usual way by any other
>> bundle.
>
>
> Well, that's the point, we are not using the ServletBridge Servlet
> (org.eclipse.equinox.servletbridge.BridgeServlet)
>
> We have our own.
>
>
>>
>>
>> You may have better luck asking about this in the Equinox newgroups or
>> mailing lists, since your problem seems to be quite specific to the
>> Equinox servlet bridge rather than Felix or OSGi in general.
>>
>> Regards
>> Neil
>>
>
> Yeah, I'm giving a try there as well, sorry, folks here seems to be more
> helpful
>
> Regards
>
>>
>> On Thu, Jan 29, 2009 at 7:16 PM, Stuart McCulloch <mc...@gmail.com>
>> wrote:
>> > 2009/1/30 Vinicius Carvalho <vi...@caravelatech.com>
>> >
>> >> Well, we got stuck again :(
>> >>
>> >> Here's the dilema:
>> >>
>> >> We need the ProxyServlet to handle requests, so it is loaded from
>> >> webappclassloader, so we need the equinox jar in our web-inf/lib
>> >> We need the Activator from equinox to get started outside the
>> >> webappclassloader, it has to be loaded by context classloader
>> >>
>> >> So we have this:
>> >>
>> >> WEB-INF/
>> >> lib/
>> >> equinox-servlet.jar
>> >>
>> >> bundles/
>> >> equinox-servlet.jar
>> >>
>> >>
>> >> Now, the problem happens here:
>> >>
>> >> ProxyServlet (from equinox) calls
>> >> Activator.addProxyServlet(this)
>> >>
>> >> The method:
>> >>
>> >> static synchronized void addProxyServlet(ProxyServlet proxyServlet) {
>> >> ServiceRegistration registration = null;
>> >> if (context != null)
>> >> registration = registerHttpService(proxyServlet);
>> >>
>> >> serviceRegistrations.put(proxyServlet, registration);
>> >> }
>> >>
>> >>
>> >> Ok, of course the damn context will be null, ProxyServlet was loaded by
>> >> webappclassloader whereas the Activator was started by our
>> >> contextclassloader
>> >>
>> >> So, no way we get HttpService registred this way.
>> >>
>> >> The other way around:
>> >>
>> >> Having our servlet starting equinox Activator:
>> >>
>> >> Well now we do have an HttpService installed as service but... It comes
>> >> from
>> >> a differente classloader :( and can't be used by our bundles.
>> >>
>> >> I guess we hit a dead end here? Is there a solution for this?
>> >>
>> >
>> > if you're embedding an OSGi framework inside another container (like a
>> > web-app) and want to use the same container classloader for a particular
>> > package then there are a couple of framework properties you can use to
>> > either:
>> >
>> > a) expose packages through the system bundle
>> > (org.osgi.framework.system.packages)
>> >
>> > or
>> >
>> > b) expose packages through bootdelegation
>> > (org.osgi.framework.bootdelegation)
>> >
>> > your bundles will then get wired to the container classloader (not the
>> local
>> > bundle) for the named package(s)
>> >
>> > this blog has a good write up of both approaches:
>> >
>> >
>> >
>> http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/
>> >
>> > HTH - I'd write a bit more but it's getting late here...
>> >
>> >
>> >> Regards
>> >>
>> >>
>> >>
>> >> On Thu, Jan 29, 2009 at 3:25 PM, Richard S. Hall <heavy@ungoverned.org
>> >> >wrote:
>> >>
>> >> > Vinicius Carvalho wrote:
>> >> >
>> >> >> Sorry for the mess. Neil, I was just mentioning that you left a post
>> at
>> >> my
>> >> >> twitter a month ago. I read both books, and they are equally great.
>> Some
>> >> >> things better in one, others in other. I do recommend everyone to
>> get
>> >> both
>> >> >> of em :)
>> >> >>
>> >> >>
>> >> >
>> >> > Don't worry, it's just Neil (he's British). ;-)
>> >> >
>> >> > -> richard
>> >> >
>> >> > On Thu, Jan 29, 2009 at 3:01 PM, Richard S. Hall <
>> heavy@ungoverned.org
>> >> >> >wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >>> Neil Bartlett wrote:
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>> Hi Vinicius,
>> >> >>>>
>> >> >>>> Glad to help, and thanks for your kind comments about my book.
>> >> >>>>
>> >> >>>> However I think it's the authors of "OSGi in Action" who are
>> asking
>> >> >>>> for a book review at the moment, since they have just released
>> some
>> >> >>>> chapters for early access. They are on this mailing list so can
>> >> >>>> probably clarify. My book is "OSGi in Practice". Yes, these two
>> titles
>> >> >>>> are confusingly similar... my defence is that I started writing my
>> >> >>>> book first!
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>> We aren't asking for a book review, but there was some review
>> recently
>> >> on
>> >> >>> DZone about the early access release from a few weeks back.
>> >> >>>
>> >> >>> Regarding the titles, we didn't really choose the title per se, but
>> "X
>> >> in
>> >> >>> Action" and even "X in Practice" titles are both Manning Publishing
>> >> >>> series
>> >> >>> books from what I understand. So you be the judge. ;-)
>> >> >>>
>> >> >>> -> richard
>> >> >>>
>> >> >>> Kind regards,
>> >> >>>
>> >> >>>
>> >> >>>> Neil
>> >> >>>>
>> >> >>>> On Thu, Jan 29, 2009 at 4:45 PM, Vinicius Carvalho
>> >> >>>> <vi...@caravelatech.com> wrote:
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>> Bullseye! Thanks Neil. I've tested and got a ClassCastException
>> ...
>> >> >>>>>
>> >> >>>>> We'll look into our code and check why is this happening. We've
>> just
>> >> >>>>> tried,
>> >> >>>>> and in a debug breakpoint we've seen that the service returned
>> by:
>> >> >>>>> HttpService httpService = (HttpService)
>> >> >>>>> context.getService(reference);
>> >> >>>>>
>> >> >>>>> Was indeed HttpServiceImpl, I guess we have a classloader
>> problem. We
>> >> >>>>> have
>> >> >>>>> the equinox servletbridge inside webinf/lib, hence it's loaded by
>> >> >>>>> WebApplicationClassLoader. Since this bundle is loaded by
>> >> >>>>> ContextClassLoader
>> >> >>>>> that might be the problem, we don't know.
>> >> >>>>>
>> >> >>>>> I'll look into it. Thanks a lot for your help, it gave us hope
>> again
>> >> :)
>> >> >>>>>
>> >> >>>>> I owe you a book review (from your message at twitter.com). I've
>> >> >>>>> finished
>> >> >>>>> you book btw, best chapter is chapter 6 (concurrency is a subject
>> >> that
>> >> >>>>> is
>> >> >>>>> not very well explained in most books, which is a shame since it
>> lead
>> >> >>>>> to
>> >> >>>>> really annoying problems) Promise to write a few lines of revuew
>> to
>> >> you
>> >> >>>>> soon.
>> >> >>>>>
>> >> >>>>> Regards
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> On Thu, Jan 29, 2009 at 11:57 AM, Neil Bartlett <
>> >> njbartlett@gmail.com
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>> wrote:
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>> It's possible that the HttpService published in the service
>> registry
>> >> >>>>>> is not compatible with your bundle that is trying to track it.
>> This
>> >> >>>>>> could happen if you have multiple bundles exporting the
>> >> >>>>>> org.osgi.service.http package, or if your tracking bundle has
>> >> somehow
>> >> >>>>>> included the org.osgi.service.http package instead of importing
>> it.
>> >> >>>>>>
>> >> >>>>>> To check if this is the case, try changing the start() method of
>> >> your
>> >> >>>>>> Activator to call httpServiceTracker.open(true) rather than just
>> >> >>>>>> httpServiceTracker.open(). This will force the tracker to find
>> all
>> >> >>>>>> HttpServices, even the incompatible ones. Of course you will
>> soon
>> >> get
>> >> >>>>>> a ClassCastException when you try to use the returned service,
>> so
>> >> you
>> >> >>>>>> need to fix the underlying problem. Doing this will simply tell
>> you
>> >> if
>> >> >>>>>> that is indeed the problem.
>> >> >>>>>>
>> >> >>>>>> Regards,
>> >> >>>>>> Neil
>> >> >>>>>>
>> >> >>>>>> On Thu, Jan 29, 2009 at 1:48 PM, Vinicius Carvalho
>> >> >>>>>> <vi...@caravelatech.com> wrote:
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>> Hello all, sorry for always comming back on the same subject,
>> but
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>> tomorrow
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>> is our deadline, and even we got some progress on the osgi
>> front
>> >> with
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>> spring
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>> (we now have services and dependency injection working).
>> Nothing
>> >> >>>>>>> seems
>> >> >>>>>>> to
>> >> >>>>>>> work on the HttpService integration.
>> >> >>>>>>>
>> >> >>>>>>> We tried almost everything to get equinox running inside a
>> servlet
>> >> >>>>>>> container. The documentation on equinox servlet bridge is
>> almost
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>> inexistent.
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>> We are not using their servletbridge since it starts the osgi
>> >> >>>>>>> container
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>> and
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>> that is something we are doing in our code (following the sling
>> >> >>>>>>> approach)
>> >> >>>>>>>
>> >> >>>>>>> What seems to be happening is that any service tracker
>> registered
>> >> to
>> >> >>>>>>> HttpService never gets called, ever... We've seen this on the
>> >> >>>>>>> OsgiManager
>> >> >>>>>>> class, and now we decided to drop our own little servlet
>> bundle:
>> >> >>>>>>>
>> >> >>>>>>> public class Activator implements BundleActivator {
>> >> >>>>>>> private ServiceTracker httpServiceTracker;
>> >> >>>>>>>
>> >> >>>>>>> public void start(BundleContext context) throws Exception {
>> >> >>>>>>> httpServiceTracker = new HttpServiceTracker(context);
>> >> >>>>>>> httpServiceTracker.open();
>> >> >>>>>>>
>> >> >>>>>>> }
>> >> >>>>>>>
>> >> >>>>>>> public void stop(BundleContext arg0) throws Exception {
>> >> >>>>>>> httpServiceTracker.close();
>> >> >>>>>>> httpServiceTracker = null;
>> >> >>>>>>> }
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> private class HttpServiceTracker extends ServiceTracker {
>> >> >>>>>>>
>> >> >>>>>>> public HttpServiceTracker(BundleContext context) {
>> >> >>>>>>> super(context, HttpService.class.getName(), null);
>> >> >>>>>>> }
>> >> >>>>>>>
>> >> >>>>>>> public Object addingService(ServiceReference reference) {
>> >> >>>>>>> HttpService httpService = (HttpService)
>> >> >>>>>>> context.getService(reference);
>> >> >>>>>>> try {
>> >> >>>>>>> httpService.registerServlet("/dummy", new
>> >> >>>>>>> DummyServlet(),
>> >> >>>>>>> null, null); //$NON-NLS-1$
>> >> >>>>>>> } catch (Exception e) {
>> >> >>>>>>> e.printStackTrace();
>> >> >>>>>>> }
>> >> >>>>>>> return httpService;
>> >> >>>>>>> }
>> >> >>>>>>>
>> >> >>>>>>> public void removedService(ServiceReference reference,
>> Object
>> >> >>>>>>> service) {
>> >> >>>>>>> HttpService httpService = (HttpService) service;
>> >> >>>>>>> httpService.unregister("/dummy"); //$NON-NLS-1$
>> >> >>>>>>> super.removedService(reference, service);
>> >> >>>>>>> }
>> >> >>>>>>> }
>> >> >>>>>>> }
>> >> >>>>>>>
>> >> >>>>>>> Well, the adding servlet never gets called :(
>> >> >>>>>>>
>> >> >>>>>>> Here how we start the felix container:
>> >> >>>>>>>
>> >> >>>>>>> public void init() throws ServletException {
>> >> >>>>>>> ServletContextResourceProvider rp = new
>> >> >>>>>>> ServletContextResourceProvider(getServletContext());
>> >> >>>>>>> Logger logger = new
>> ServletContextLogger(getServletContext());
>> >> >>>>>>> Map<Object, Object> props = loadProperties();
>> >> >>>>>>> this.osl = new OSL(rp,props,logger);
>> >> >>>>>>> this.delegatee = new HttpServiceServlet();
>> >> >>>>>>> this.delegatee.init(getServletConfig());
>> >> >>>>>>>
>> >> >>>>>>> super.init();
>> >> >>>>>>> }
>> >> >>>>>>>
>> >> >>>>>>> public class OSL implements BundleActivator {
>> >> >>>>>>>
>> >> >>>>>>> private Felix felix;
>> >> >>>>>>> private ReadWriteLock felixLock;
>> >> >>>>>>> private ResourceProvider resourceProvider;
>> >> >>>>>>> private Logger logger;
>> >> >>>>>>> private BundleActivator httpServiceActivator;
>> >> >>>>>>>
>> >> >>>>>>> public OSL(ResourceProvider rp, Map<Object, Object> props,
>> Logger
>> >> >>>>>>> logger){
>> >> >>>>>>> this.resourceProvider = rp;
>> >> >>>>>>> this.logger = logger;
>> >> >>>>>>> List<BundleActivator> activators = new
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>> ArrayList<BundleActivator>();
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>> activators.add(this);
>> >> >>>>>>> activators.add(new BootstrapInstaller(logger,rp));
>> >> >>>>>>> props.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>> activators);
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>> Felix tmpFelix = new Felix(props);
>> >> >>>>>>> try {
>> >> >>>>>>> tmpFelix.start();
>> >> >>>>>>> this.felix = tmpFelix;
>> >> >>>>>>> } catch (Exception e) {
>> >> >>>>>>> e.printStackTrace();
>> >> >>>>>>> }
>> >> >>>>>>> }
>> >> >>>>>>>
>> >> >>>>>>> public void start(BundleContext context) throws Exception {
>> >> >>>>>>> this.httpServiceActivator = new Activator();
>> >> >>>>>>> this.httpServiceActivator.start(context);
>> >> >>>>>>>
>> >> >>>>>>> }
>> >> >>>>>>>
>> >> >>>>>>> As you can see, we are starting the Httpservice ourselves, we
>> tried
>> >> >>>>>>> to
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>> not
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>> do so and pack it with the other bundles, but the effect is the
>> >> same
>> >> >>>>>>> (do
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>> not
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>> call the addingservice)
>> >> >>>>>>>
>> >> >>>>>>> After the complete startup we have these services:
>> >> >>>>>>>
>> >> >>>>>>> System Bundle (0) provides:
>> >> >>>>>>> ---------------------------
>> >> >>>>>>> org.osgi.service.startlevel.StartLevel
>> >> >>>>>>> org.osgi.service.packageadmin.PackageAdmin
>> >> >>>>>>> org.osgi.service.http.HttpService
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> So I guess the HttpService is up and running.
>> >> >>>>>>>
>> >> >>>>>>> Is there anything else that we could do? Any other point to
>> look
>> >> at,
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>> replace
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>> class, packaging format, anything please. Tomorrow if we don't
>> >> >>>>>>> present
>> >> >>>>>>> at
>> >> >>>>>>> least one servlet (we needed at least the GWT-RPC working but
>> one
>> >> >>>>>>> servlet
>> >> >>>>>>> should do it), we may have to drop osgi for good, and that's
>> >> >>>>>>> something
>> >> >>>>>>> we
>> >> >>>>>>> are really not willing to do :(
>> >> >>>>>>>
>> >> >>>>>>> Regards
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>
>> >> ---------------------------------------------------------------------
>> >> >>>>>> 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
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Cheers, Stuart
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
Re: ServiceTracker never gets called
Posted by Vinicius Carvalho <vi...@caravelatech.com>.
On Thu, Jan 29, 2009 at 5:30 PM, Neil Bartlett <nj...@gmail.com> wrote:
> Further to Stuart's email, it would be interesting to see how your
> tracking bundle is getting the HttpService class. Do you import the
> org.osgi.service.http package using Import-Package? If so, which
> bundle is supplying the export?
Well, the system-bundle, at least I think from the console output:
System Bundle (0) provides:
---------------------------
objectClass = org.osgi.service.startlevel.StartLevel
service.id = 1
----
objectClass = org.osgi.service.packageadmin.PackageAdmin
service.id = 2
----
objectClass = org.osgi.service.http.HttpService
service.description = Equinox Servlet Bridge
service.id = 39
service.vendor = Eclipse.org
>
>
> It seems like you're using the Equinox servlet bridge, which has a
> parameter "extendedFrameworkExports". You set this in the web.xml of
> the WAR and it should contain a list of packages to be exported by the
> system bundle. Then they can be imported in the usual way by any other
> bundle.
Well, that's the point, we are not using the ServletBridge Servlet
(org.eclipse.equinox.servletbridge.BridgeServlet)
We have our own.
>
>
> You may have better luck asking about this in the Equinox newgroups or
> mailing lists, since your problem seems to be quite specific to the
> Equinox servlet bridge rather than Felix or OSGi in general.
>
> Regards
> Neil
>
Yeah, I'm giving a try there as well, sorry, folks here seems to be more
helpful
Regards
>
> On Thu, Jan 29, 2009 at 7:16 PM, Stuart McCulloch <mc...@gmail.com>
> wrote:
> > 2009/1/30 Vinicius Carvalho <vi...@caravelatech.com>
> >
> >> Well, we got stuck again :(
> >>
> >> Here's the dilema:
> >>
> >> We need the ProxyServlet to handle requests, so it is loaded from
> >> webappclassloader, so we need the equinox jar in our web-inf/lib
> >> We need the Activator from equinox to get started outside the
> >> webappclassloader, it has to be loaded by context classloader
> >>
> >> So we have this:
> >>
> >> WEB-INF/
> >> lib/
> >> equinox-servlet.jar
> >>
> >> bundles/
> >> equinox-servlet.jar
> >>
> >>
> >> Now, the problem happens here:
> >>
> >> ProxyServlet (from equinox) calls
> >> Activator.addProxyServlet(this)
> >>
> >> The method:
> >>
> >> static synchronized void addProxyServlet(ProxyServlet proxyServlet) {
> >> ServiceRegistration registration = null;
> >> if (context != null)
> >> registration = registerHttpService(proxyServlet);
> >>
> >> serviceRegistrations.put(proxyServlet, registration);
> >> }
> >>
> >>
> >> Ok, of course the damn context will be null, ProxyServlet was loaded by
> >> webappclassloader whereas the Activator was started by our
> >> contextclassloader
> >>
> >> So, no way we get HttpService registred this way.
> >>
> >> The other way around:
> >>
> >> Having our servlet starting equinox Activator:
> >>
> >> Well now we do have an HttpService installed as service but... It comes
> >> from
> >> a differente classloader :( and can't be used by our bundles.
> >>
> >> I guess we hit a dead end here? Is there a solution for this?
> >>
> >
> > if you're embedding an OSGi framework inside another container (like a
> > web-app) and want to use the same container classloader for a particular
> > package then there are a couple of framework properties you can use to
> > either:
> >
> > a) expose packages through the system bundle
> > (org.osgi.framework.system.packages)
> >
> > or
> >
> > b) expose packages through bootdelegation
> > (org.osgi.framework.bootdelegation)
> >
> > your bundles will then get wired to the container classloader (not the
> local
> > bundle) for the named package(s)
> >
> > this blog has a good write up of both approaches:
> >
> >
> >
> http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/
> >
> > HTH - I'd write a bit more but it's getting late here...
> >
> >
> >> Regards
> >>
> >>
> >>
> >> On Thu, Jan 29, 2009 at 3:25 PM, Richard S. Hall <heavy@ungoverned.org
> >> >wrote:
> >>
> >> > Vinicius Carvalho wrote:
> >> >
> >> >> Sorry for the mess. Neil, I was just mentioning that you left a post
> at
> >> my
> >> >> twitter a month ago. I read both books, and they are equally great.
> Some
> >> >> things better in one, others in other. I do recommend everyone to get
> >> both
> >> >> of em :)
> >> >>
> >> >>
> >> >
> >> > Don't worry, it's just Neil (he's British). ;-)
> >> >
> >> > -> richard
> >> >
> >> > On Thu, Jan 29, 2009 at 3:01 PM, Richard S. Hall <
> heavy@ungoverned.org
> >> >> >wrote:
> >> >>
> >> >>
> >> >>
> >> >>> Neil Bartlett wrote:
> >> >>>
> >> >>>
> >> >>>
> >> >>>> Hi Vinicius,
> >> >>>>
> >> >>>> Glad to help, and thanks for your kind comments about my book.
> >> >>>>
> >> >>>> However I think it's the authors of "OSGi in Action" who are asking
> >> >>>> for a book review at the moment, since they have just released some
> >> >>>> chapters for early access. They are on this mailing list so can
> >> >>>> probably clarify. My book is "OSGi in Practice". Yes, these two
> titles
> >> >>>> are confusingly similar... my defence is that I started writing my
> >> >>>> book first!
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>> We aren't asking for a book review, but there was some review
> recently
> >> on
> >> >>> DZone about the early access release from a few weeks back.
> >> >>>
> >> >>> Regarding the titles, we didn't really choose the title per se, but
> "X
> >> in
> >> >>> Action" and even "X in Practice" titles are both Manning Publishing
> >> >>> series
> >> >>> books from what I understand. So you be the judge. ;-)
> >> >>>
> >> >>> -> richard
> >> >>>
> >> >>> Kind regards,
> >> >>>
> >> >>>
> >> >>>> Neil
> >> >>>>
> >> >>>> On Thu, Jan 29, 2009 at 4:45 PM, Vinicius Carvalho
> >> >>>> <vi...@caravelatech.com> wrote:
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>> Bullseye! Thanks Neil. I've tested and got a ClassCastException
> ...
> >> >>>>>
> >> >>>>> We'll look into our code and check why is this happening. We've
> just
> >> >>>>> tried,
> >> >>>>> and in a debug breakpoint we've seen that the service returned by:
> >> >>>>> HttpService httpService = (HttpService)
> >> >>>>> context.getService(reference);
> >> >>>>>
> >> >>>>> Was indeed HttpServiceImpl, I guess we have a classloader problem.
> We
> >> >>>>> have
> >> >>>>> the equinox servletbridge inside webinf/lib, hence it's loaded by
> >> >>>>> WebApplicationClassLoader. Since this bundle is loaded by
> >> >>>>> ContextClassLoader
> >> >>>>> that might be the problem, we don't know.
> >> >>>>>
> >> >>>>> I'll look into it. Thanks a lot for your help, it gave us hope
> again
> >> :)
> >> >>>>>
> >> >>>>> I owe you a book review (from your message at twitter.com). I've
> >> >>>>> finished
> >> >>>>> you book btw, best chapter is chapter 6 (concurrency is a subject
> >> that
> >> >>>>> is
> >> >>>>> not very well explained in most books, which is a shame since it
> lead
> >> >>>>> to
> >> >>>>> really annoying problems) Promise to write a few lines of revuew
> to
> >> you
> >> >>>>> soon.
> >> >>>>>
> >> >>>>> Regards
> >> >>>>>
> >> >>>>>
> >> >>>>> On Thu, Jan 29, 2009 at 11:57 AM, Neil Bartlett <
> >> njbartlett@gmail.com
> >> >>>>>
> >> >>>>>
> >> >>>>>> wrote:
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>> It's possible that the HttpService published in the service
> registry
> >> >>>>>> is not compatible with your bundle that is trying to track it.
> This
> >> >>>>>> could happen if you have multiple bundles exporting the
> >> >>>>>> org.osgi.service.http package, or if your tracking bundle has
> >> somehow
> >> >>>>>> included the org.osgi.service.http package instead of importing
> it.
> >> >>>>>>
> >> >>>>>> To check if this is the case, try changing the start() method of
> >> your
> >> >>>>>> Activator to call httpServiceTracker.open(true) rather than just
> >> >>>>>> httpServiceTracker.open(). This will force the tracker to find
> all
> >> >>>>>> HttpServices, even the incompatible ones. Of course you will soon
> >> get
> >> >>>>>> a ClassCastException when you try to use the returned service, so
> >> you
> >> >>>>>> need to fix the underlying problem. Doing this will simply tell
> you
> >> if
> >> >>>>>> that is indeed the problem.
> >> >>>>>>
> >> >>>>>> Regards,
> >> >>>>>> Neil
> >> >>>>>>
> >> >>>>>> On Thu, Jan 29, 2009 at 1:48 PM, Vinicius Carvalho
> >> >>>>>> <vi...@caravelatech.com> wrote:
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> Hello all, sorry for always comming back on the same subject,
> but
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> tomorrow
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> is our deadline, and even we got some progress on the osgi front
> >> with
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> spring
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> (we now have services and dependency injection working). Nothing
> >> >>>>>>> seems
> >> >>>>>>> to
> >> >>>>>>> work on the HttpService integration.
> >> >>>>>>>
> >> >>>>>>> We tried almost everything to get equinox running inside a
> servlet
> >> >>>>>>> container. The documentation on equinox servlet bridge is almost
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> inexistent.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> We are not using their servletbridge since it starts the osgi
> >> >>>>>>> container
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> and
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> that is something we are doing in our code (following the sling
> >> >>>>>>> approach)
> >> >>>>>>>
> >> >>>>>>> What seems to be happening is that any service tracker
> registered
> >> to
> >> >>>>>>> HttpService never gets called, ever... We've seen this on the
> >> >>>>>>> OsgiManager
> >> >>>>>>> class, and now we decided to drop our own little servlet bundle:
> >> >>>>>>>
> >> >>>>>>> public class Activator implements BundleActivator {
> >> >>>>>>> private ServiceTracker httpServiceTracker;
> >> >>>>>>>
> >> >>>>>>> public void start(BundleContext context) throws Exception {
> >> >>>>>>> httpServiceTracker = new HttpServiceTracker(context);
> >> >>>>>>> httpServiceTracker.open();
> >> >>>>>>>
> >> >>>>>>> }
> >> >>>>>>>
> >> >>>>>>> public void stop(BundleContext arg0) throws Exception {
> >> >>>>>>> httpServiceTracker.close();
> >> >>>>>>> httpServiceTracker = null;
> >> >>>>>>> }
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> private class HttpServiceTracker extends ServiceTracker {
> >> >>>>>>>
> >> >>>>>>> public HttpServiceTracker(BundleContext context) {
> >> >>>>>>> super(context, HttpService.class.getName(), null);
> >> >>>>>>> }
> >> >>>>>>>
> >> >>>>>>> public Object addingService(ServiceReference reference) {
> >> >>>>>>> HttpService httpService = (HttpService)
> >> >>>>>>> context.getService(reference);
> >> >>>>>>> try {
> >> >>>>>>> httpService.registerServlet("/dummy", new
> >> >>>>>>> DummyServlet(),
> >> >>>>>>> null, null); //$NON-NLS-1$
> >> >>>>>>> } catch (Exception e) {
> >> >>>>>>> e.printStackTrace();
> >> >>>>>>> }
> >> >>>>>>> return httpService;
> >> >>>>>>> }
> >> >>>>>>>
> >> >>>>>>> public void removedService(ServiceReference reference,
> Object
> >> >>>>>>> service) {
> >> >>>>>>> HttpService httpService = (HttpService) service;
> >> >>>>>>> httpService.unregister("/dummy"); //$NON-NLS-1$
> >> >>>>>>> super.removedService(reference, service);
> >> >>>>>>> }
> >> >>>>>>> }
> >> >>>>>>> }
> >> >>>>>>>
> >> >>>>>>> Well, the adding servlet never gets called :(
> >> >>>>>>>
> >> >>>>>>> Here how we start the felix container:
> >> >>>>>>>
> >> >>>>>>> public void init() throws ServletException {
> >> >>>>>>> ServletContextResourceProvider rp = new
> >> >>>>>>> ServletContextResourceProvider(getServletContext());
> >> >>>>>>> Logger logger = new
> ServletContextLogger(getServletContext());
> >> >>>>>>> Map<Object, Object> props = loadProperties();
> >> >>>>>>> this.osl = new OSL(rp,props,logger);
> >> >>>>>>> this.delegatee = new HttpServiceServlet();
> >> >>>>>>> this.delegatee.init(getServletConfig());
> >> >>>>>>>
> >> >>>>>>> super.init();
> >> >>>>>>> }
> >> >>>>>>>
> >> >>>>>>> public class OSL implements BundleActivator {
> >> >>>>>>>
> >> >>>>>>> private Felix felix;
> >> >>>>>>> private ReadWriteLock felixLock;
> >> >>>>>>> private ResourceProvider resourceProvider;
> >> >>>>>>> private Logger logger;
> >> >>>>>>> private BundleActivator httpServiceActivator;
> >> >>>>>>>
> >> >>>>>>> public OSL(ResourceProvider rp, Map<Object, Object> props,
> Logger
> >> >>>>>>> logger){
> >> >>>>>>> this.resourceProvider = rp;
> >> >>>>>>> this.logger = logger;
> >> >>>>>>> List<BundleActivator> activators = new
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> ArrayList<BundleActivator>();
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> activators.add(this);
> >> >>>>>>> activators.add(new BootstrapInstaller(logger,rp));
> >> >>>>>>> props.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> activators);
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> Felix tmpFelix = new Felix(props);
> >> >>>>>>> try {
> >> >>>>>>> tmpFelix.start();
> >> >>>>>>> this.felix = tmpFelix;
> >> >>>>>>> } catch (Exception e) {
> >> >>>>>>> e.printStackTrace();
> >> >>>>>>> }
> >> >>>>>>> }
> >> >>>>>>>
> >> >>>>>>> public void start(BundleContext context) throws Exception {
> >> >>>>>>> this.httpServiceActivator = new Activator();
> >> >>>>>>> this.httpServiceActivator.start(context);
> >> >>>>>>>
> >> >>>>>>> }
> >> >>>>>>>
> >> >>>>>>> As you can see, we are starting the Httpservice ourselves, we
> tried
> >> >>>>>>> to
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> not
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> do so and pack it with the other bundles, but the effect is the
> >> same
> >> >>>>>>> (do
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> not
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> call the addingservice)
> >> >>>>>>>
> >> >>>>>>> After the complete startup we have these services:
> >> >>>>>>>
> >> >>>>>>> System Bundle (0) provides:
> >> >>>>>>> ---------------------------
> >> >>>>>>> org.osgi.service.startlevel.StartLevel
> >> >>>>>>> org.osgi.service.packageadmin.PackageAdmin
> >> >>>>>>> org.osgi.service.http.HttpService
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> So I guess the HttpService is up and running.
> >> >>>>>>>
> >> >>>>>>> Is there anything else that we could do? Any other point to look
> >> at,
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> replace
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> class, packaging format, anything please. Tomorrow if we don't
> >> >>>>>>> present
> >> >>>>>>> at
> >> >>>>>>> least one servlet (we needed at least the GWT-RPC working but
> one
> >> >>>>>>> servlet
> >> >>>>>>> should do it), we may have to drop osgi for good, and that's
> >> >>>>>>> something
> >> >>>>>>> we
> >> >>>>>>> are really not willing to do :(
> >> >>>>>>>
> >> >>>>>>> Regards
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>> 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
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > Cheers, Stuart
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: ServiceTracker never gets called
Posted by Neil Bartlett <nj...@gmail.com>.
Further to Stuart's email, it would be interesting to see how your
tracking bundle is getting the HttpService class. Do you import the
org.osgi.service.http package using Import-Package? If so, which
bundle is supplying the export?
It seems like you're using the Equinox servlet bridge, which has a
parameter "extendedFrameworkExports". You set this in the web.xml of
the WAR and it should contain a list of packages to be exported by the
system bundle. Then they can be imported in the usual way by any other
bundle.
You may have better luck asking about this in the Equinox newgroups or
mailing lists, since your problem seems to be quite specific to the
Equinox servlet bridge rather than Felix or OSGi in general.
Regards
Neil
On Thu, Jan 29, 2009 at 7:16 PM, Stuart McCulloch <mc...@gmail.com> wrote:
> 2009/1/30 Vinicius Carvalho <vi...@caravelatech.com>
>
>> Well, we got stuck again :(
>>
>> Here's the dilema:
>>
>> We need the ProxyServlet to handle requests, so it is loaded from
>> webappclassloader, so we need the equinox jar in our web-inf/lib
>> We need the Activator from equinox to get started outside the
>> webappclassloader, it has to be loaded by context classloader
>>
>> So we have this:
>>
>> WEB-INF/
>> lib/
>> equinox-servlet.jar
>>
>> bundles/
>> equinox-servlet.jar
>>
>>
>> Now, the problem happens here:
>>
>> ProxyServlet (from equinox) calls
>> Activator.addProxyServlet(this)
>>
>> The method:
>>
>> static synchronized void addProxyServlet(ProxyServlet proxyServlet) {
>> ServiceRegistration registration = null;
>> if (context != null)
>> registration = registerHttpService(proxyServlet);
>>
>> serviceRegistrations.put(proxyServlet, registration);
>> }
>>
>>
>> Ok, of course the damn context will be null, ProxyServlet was loaded by
>> webappclassloader whereas the Activator was started by our
>> contextclassloader
>>
>> So, no way we get HttpService registred this way.
>>
>> The other way around:
>>
>> Having our servlet starting equinox Activator:
>>
>> Well now we do have an HttpService installed as service but... It comes
>> from
>> a differente classloader :( and can't be used by our bundles.
>>
>> I guess we hit a dead end here? Is there a solution for this?
>>
>
> if you're embedding an OSGi framework inside another container (like a
> web-app) and want to use the same container classloader for a particular
> package then there are a couple of framework properties you can use to
> either:
>
> a) expose packages through the system bundle
> (org.osgi.framework.system.packages)
>
> or
>
> b) expose packages through bootdelegation
> (org.osgi.framework.bootdelegation)
>
> your bundles will then get wired to the container classloader (not the local
> bundle) for the named package(s)
>
> this blog has a good write up of both approaches:
>
>
> http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/
>
> HTH - I'd write a bit more but it's getting late here...
>
>
>> Regards
>>
>>
>>
>> On Thu, Jan 29, 2009 at 3:25 PM, Richard S. Hall <heavy@ungoverned.org
>> >wrote:
>>
>> > Vinicius Carvalho wrote:
>> >
>> >> Sorry for the mess. Neil, I was just mentioning that you left a post at
>> my
>> >> twitter a month ago. I read both books, and they are equally great. Some
>> >> things better in one, others in other. I do recommend everyone to get
>> both
>> >> of em :)
>> >>
>> >>
>> >
>> > Don't worry, it's just Neil (he's British). ;-)
>> >
>> > -> richard
>> >
>> > On Thu, Jan 29, 2009 at 3:01 PM, Richard S. Hall <heavy@ungoverned.org
>> >> >wrote:
>> >>
>> >>
>> >>
>> >>> Neil Bartlett wrote:
>> >>>
>> >>>
>> >>>
>> >>>> Hi Vinicius,
>> >>>>
>> >>>> Glad to help, and thanks for your kind comments about my book.
>> >>>>
>> >>>> However I think it's the authors of "OSGi in Action" who are asking
>> >>>> for a book review at the moment, since they have just released some
>> >>>> chapters for early access. They are on this mailing list so can
>> >>>> probably clarify. My book is "OSGi in Practice". Yes, these two titles
>> >>>> are confusingly similar... my defence is that I started writing my
>> >>>> book first!
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>> We aren't asking for a book review, but there was some review recently
>> on
>> >>> DZone about the early access release from a few weeks back.
>> >>>
>> >>> Regarding the titles, we didn't really choose the title per se, but "X
>> in
>> >>> Action" and even "X in Practice" titles are both Manning Publishing
>> >>> series
>> >>> books from what I understand. So you be the judge. ;-)
>> >>>
>> >>> -> richard
>> >>>
>> >>> Kind regards,
>> >>>
>> >>>
>> >>>> Neil
>> >>>>
>> >>>> On Thu, Jan 29, 2009 at 4:45 PM, Vinicius Carvalho
>> >>>> <vi...@caravelatech.com> wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>> Bullseye! Thanks Neil. I've tested and got a ClassCastException ...
>> >>>>>
>> >>>>> We'll look into our code and check why is this happening. We've just
>> >>>>> tried,
>> >>>>> and in a debug breakpoint we've seen that the service returned by:
>> >>>>> HttpService httpService = (HttpService)
>> >>>>> context.getService(reference);
>> >>>>>
>> >>>>> Was indeed HttpServiceImpl, I guess we have a classloader problem. We
>> >>>>> have
>> >>>>> the equinox servletbridge inside webinf/lib, hence it's loaded by
>> >>>>> WebApplicationClassLoader. Since this bundle is loaded by
>> >>>>> ContextClassLoader
>> >>>>> that might be the problem, we don't know.
>> >>>>>
>> >>>>> I'll look into it. Thanks a lot for your help, it gave us hope again
>> :)
>> >>>>>
>> >>>>> I owe you a book review (from your message at twitter.com). I've
>> >>>>> finished
>> >>>>> you book btw, best chapter is chapter 6 (concurrency is a subject
>> that
>> >>>>> is
>> >>>>> not very well explained in most books, which is a shame since it lead
>> >>>>> to
>> >>>>> really annoying problems) Promise to write a few lines of revuew to
>> you
>> >>>>> soon.
>> >>>>>
>> >>>>> Regards
>> >>>>>
>> >>>>>
>> >>>>> On Thu, Jan 29, 2009 at 11:57 AM, Neil Bartlett <
>> njbartlett@gmail.com
>> >>>>>
>> >>>>>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>> It's possible that the HttpService published in the service registry
>> >>>>>> is not compatible with your bundle that is trying to track it. This
>> >>>>>> could happen if you have multiple bundles exporting the
>> >>>>>> org.osgi.service.http package, or if your tracking bundle has
>> somehow
>> >>>>>> included the org.osgi.service.http package instead of importing it.
>> >>>>>>
>> >>>>>> To check if this is the case, try changing the start() method of
>> your
>> >>>>>> Activator to call httpServiceTracker.open(true) rather than just
>> >>>>>> httpServiceTracker.open(). This will force the tracker to find all
>> >>>>>> HttpServices, even the incompatible ones. Of course you will soon
>> get
>> >>>>>> a ClassCastException when you try to use the returned service, so
>> you
>> >>>>>> need to fix the underlying problem. Doing this will simply tell you
>> if
>> >>>>>> that is indeed the problem.
>> >>>>>>
>> >>>>>> Regards,
>> >>>>>> Neil
>> >>>>>>
>> >>>>>> On Thu, Jan 29, 2009 at 1:48 PM, Vinicius Carvalho
>> >>>>>> <vi...@caravelatech.com> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> Hello all, sorry for always comming back on the same subject, but
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> tomorrow
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> is our deadline, and even we got some progress on the osgi front
>> with
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> spring
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> (we now have services and dependency injection working). Nothing
>> >>>>>>> seems
>> >>>>>>> to
>> >>>>>>> work on the HttpService integration.
>> >>>>>>>
>> >>>>>>> We tried almost everything to get equinox running inside a servlet
>> >>>>>>> container. The documentation on equinox servlet bridge is almost
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> inexistent.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> We are not using their servletbridge since it starts the osgi
>> >>>>>>> container
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> and
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> that is something we are doing in our code (following the sling
>> >>>>>>> approach)
>> >>>>>>>
>> >>>>>>> What seems to be happening is that any service tracker registered
>> to
>> >>>>>>> HttpService never gets called, ever... We've seen this on the
>> >>>>>>> OsgiManager
>> >>>>>>> class, and now we decided to drop our own little servlet bundle:
>> >>>>>>>
>> >>>>>>> public class Activator implements BundleActivator {
>> >>>>>>> private ServiceTracker httpServiceTracker;
>> >>>>>>>
>> >>>>>>> public void start(BundleContext context) throws Exception {
>> >>>>>>> httpServiceTracker = new HttpServiceTracker(context);
>> >>>>>>> httpServiceTracker.open();
>> >>>>>>>
>> >>>>>>> }
>> >>>>>>>
>> >>>>>>> public void stop(BundleContext arg0) throws Exception {
>> >>>>>>> httpServiceTracker.close();
>> >>>>>>> httpServiceTracker = null;
>> >>>>>>> }
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> private class HttpServiceTracker extends ServiceTracker {
>> >>>>>>>
>> >>>>>>> public HttpServiceTracker(BundleContext context) {
>> >>>>>>> super(context, HttpService.class.getName(), null);
>> >>>>>>> }
>> >>>>>>>
>> >>>>>>> public Object addingService(ServiceReference reference) {
>> >>>>>>> HttpService httpService = (HttpService)
>> >>>>>>> context.getService(reference);
>> >>>>>>> try {
>> >>>>>>> httpService.registerServlet("/dummy", new
>> >>>>>>> DummyServlet(),
>> >>>>>>> null, null); //$NON-NLS-1$
>> >>>>>>> } catch (Exception e) {
>> >>>>>>> e.printStackTrace();
>> >>>>>>> }
>> >>>>>>> return httpService;
>> >>>>>>> }
>> >>>>>>>
>> >>>>>>> public void removedService(ServiceReference reference, Object
>> >>>>>>> service) {
>> >>>>>>> HttpService httpService = (HttpService) service;
>> >>>>>>> httpService.unregister("/dummy"); //$NON-NLS-1$
>> >>>>>>> super.removedService(reference, service);
>> >>>>>>> }
>> >>>>>>> }
>> >>>>>>> }
>> >>>>>>>
>> >>>>>>> Well, the adding servlet never gets called :(
>> >>>>>>>
>> >>>>>>> Here how we start the felix container:
>> >>>>>>>
>> >>>>>>> public void init() throws ServletException {
>> >>>>>>> ServletContextResourceProvider rp = new
>> >>>>>>> ServletContextResourceProvider(getServletContext());
>> >>>>>>> Logger logger = new ServletContextLogger(getServletContext());
>> >>>>>>> Map<Object, Object> props = loadProperties();
>> >>>>>>> this.osl = new OSL(rp,props,logger);
>> >>>>>>> this.delegatee = new HttpServiceServlet();
>> >>>>>>> this.delegatee.init(getServletConfig());
>> >>>>>>>
>> >>>>>>> super.init();
>> >>>>>>> }
>> >>>>>>>
>> >>>>>>> public class OSL implements BundleActivator {
>> >>>>>>>
>> >>>>>>> private Felix felix;
>> >>>>>>> private ReadWriteLock felixLock;
>> >>>>>>> private ResourceProvider resourceProvider;
>> >>>>>>> private Logger logger;
>> >>>>>>> private BundleActivator httpServiceActivator;
>> >>>>>>>
>> >>>>>>> public OSL(ResourceProvider rp, Map<Object, Object> props, Logger
>> >>>>>>> logger){
>> >>>>>>> this.resourceProvider = rp;
>> >>>>>>> this.logger = logger;
>> >>>>>>> List<BundleActivator> activators = new
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> ArrayList<BundleActivator>();
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> activators.add(this);
>> >>>>>>> activators.add(new BootstrapInstaller(logger,rp));
>> >>>>>>> props.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> activators);
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> Felix tmpFelix = new Felix(props);
>> >>>>>>> try {
>> >>>>>>> tmpFelix.start();
>> >>>>>>> this.felix = tmpFelix;
>> >>>>>>> } catch (Exception e) {
>> >>>>>>> e.printStackTrace();
>> >>>>>>> }
>> >>>>>>> }
>> >>>>>>>
>> >>>>>>> public void start(BundleContext context) throws Exception {
>> >>>>>>> this.httpServiceActivator = new Activator();
>> >>>>>>> this.httpServiceActivator.start(context);
>> >>>>>>>
>> >>>>>>> }
>> >>>>>>>
>> >>>>>>> As you can see, we are starting the Httpservice ourselves, we tried
>> >>>>>>> to
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> not
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> do so and pack it with the other bundles, but the effect is the
>> same
>> >>>>>>> (do
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> not
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> call the addingservice)
>> >>>>>>>
>> >>>>>>> After the complete startup we have these services:
>> >>>>>>>
>> >>>>>>> System Bundle (0) provides:
>> >>>>>>> ---------------------------
>> >>>>>>> org.osgi.service.startlevel.StartLevel
>> >>>>>>> org.osgi.service.packageadmin.PackageAdmin
>> >>>>>>> org.osgi.service.http.HttpService
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> So I guess the HttpService is up and running.
>> >>>>>>>
>> >>>>>>> Is there anything else that we could do? Any other point to look
>> at,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> replace
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> class, packaging format, anything please. Tomorrow if we don't
>> >>>>>>> present
>> >>>>>>> at
>> >>>>>>> least one servlet (we needed at least the GWT-RPC working but one
>> >>>>>>> servlet
>> >>>>>>> should do it), we may have to drop osgi for good, and that's
>> >>>>>>> something
>> >>>>>>> we
>> >>>>>>> are really not willing to do :(
>> >>>>>>>
>> >>>>>>> Regards
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> 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
>> >
>> >
>>
>
>
>
> --
> Cheers, Stuart
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ServiceTracker never gets called
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/1/30 Vinicius Carvalho <vi...@caravelatech.com>
> Well, we got stuck again :(
>
> Here's the dilema:
>
> We need the ProxyServlet to handle requests, so it is loaded from
> webappclassloader, so we need the equinox jar in our web-inf/lib
> We need the Activator from equinox to get started outside the
> webappclassloader, it has to be loaded by context classloader
>
> So we have this:
>
> WEB-INF/
> lib/
> equinox-servlet.jar
>
> bundles/
> equinox-servlet.jar
>
>
> Now, the problem happens here:
>
> ProxyServlet (from equinox) calls
> Activator.addProxyServlet(this)
>
> The method:
>
> static synchronized void addProxyServlet(ProxyServlet proxyServlet) {
> ServiceRegistration registration = null;
> if (context != null)
> registration = registerHttpService(proxyServlet);
>
> serviceRegistrations.put(proxyServlet, registration);
> }
>
>
> Ok, of course the damn context will be null, ProxyServlet was loaded by
> webappclassloader whereas the Activator was started by our
> contextclassloader
>
> So, no way we get HttpService registred this way.
>
> The other way around:
>
> Having our servlet starting equinox Activator:
>
> Well now we do have an HttpService installed as service but... It comes
> from
> a differente classloader :( and can't be used by our bundles.
>
> I guess we hit a dead end here? Is there a solution for this?
>
if you're embedding an OSGi framework inside another container (like a
web-app) and want to use the same container classloader for a particular
package then there are a couple of framework properties you can use to
either:
a) expose packages through the system bundle
(org.osgi.framework.system.packages)
or
b) expose packages through bootdelegation
(org.osgi.framework.bootdelegation)
your bundles will then get wired to the container classloader (not the local
bundle) for the named package(s)
this blog has a good write up of both approaches:
http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/
HTH - I'd write a bit more but it's getting late here...
> Regards
>
>
>
> On Thu, Jan 29, 2009 at 3:25 PM, Richard S. Hall <heavy@ungoverned.org
> >wrote:
>
> > Vinicius Carvalho wrote:
> >
> >> Sorry for the mess. Neil, I was just mentioning that you left a post at
> my
> >> twitter a month ago. I read both books, and they are equally great. Some
> >> things better in one, others in other. I do recommend everyone to get
> both
> >> of em :)
> >>
> >>
> >
> > Don't worry, it's just Neil (he's British). ;-)
> >
> > -> richard
> >
> > On Thu, Jan 29, 2009 at 3:01 PM, Richard S. Hall <heavy@ungoverned.org
> >> >wrote:
> >>
> >>
> >>
> >>> Neil Bartlett wrote:
> >>>
> >>>
> >>>
> >>>> Hi Vinicius,
> >>>>
> >>>> Glad to help, and thanks for your kind comments about my book.
> >>>>
> >>>> However I think it's the authors of "OSGi in Action" who are asking
> >>>> for a book review at the moment, since they have just released some
> >>>> chapters for early access. They are on this mailing list so can
> >>>> probably clarify. My book is "OSGi in Practice". Yes, these two titles
> >>>> are confusingly similar... my defence is that I started writing my
> >>>> book first!
> >>>>
> >>>>
> >>>>
> >>>>
> >>> We aren't asking for a book review, but there was some review recently
> on
> >>> DZone about the early access release from a few weeks back.
> >>>
> >>> Regarding the titles, we didn't really choose the title per se, but "X
> in
> >>> Action" and even "X in Practice" titles are both Manning Publishing
> >>> series
> >>> books from what I understand. So you be the judge. ;-)
> >>>
> >>> -> richard
> >>>
> >>> Kind regards,
> >>>
> >>>
> >>>> Neil
> >>>>
> >>>> On Thu, Jan 29, 2009 at 4:45 PM, Vinicius Carvalho
> >>>> <vi...@caravelatech.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Bullseye! Thanks Neil. I've tested and got a ClassCastException ...
> >>>>>
> >>>>> We'll look into our code and check why is this happening. We've just
> >>>>> tried,
> >>>>> and in a debug breakpoint we've seen that the service returned by:
> >>>>> HttpService httpService = (HttpService)
> >>>>> context.getService(reference);
> >>>>>
> >>>>> Was indeed HttpServiceImpl, I guess we have a classloader problem. We
> >>>>> have
> >>>>> the equinox servletbridge inside webinf/lib, hence it's loaded by
> >>>>> WebApplicationClassLoader. Since this bundle is loaded by
> >>>>> ContextClassLoader
> >>>>> that might be the problem, we don't know.
> >>>>>
> >>>>> I'll look into it. Thanks a lot for your help, it gave us hope again
> :)
> >>>>>
> >>>>> I owe you a book review (from your message at twitter.com). I've
> >>>>> finished
> >>>>> you book btw, best chapter is chapter 6 (concurrency is a subject
> that
> >>>>> is
> >>>>> not very well explained in most books, which is a shame since it lead
> >>>>> to
> >>>>> really annoying problems) Promise to write a few lines of revuew to
> you
> >>>>> soon.
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>>
> >>>>> On Thu, Jan 29, 2009 at 11:57 AM, Neil Bartlett <
> njbartlett@gmail.com
> >>>>>
> >>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> It's possible that the HttpService published in the service registry
> >>>>>> is not compatible with your bundle that is trying to track it. This
> >>>>>> could happen if you have multiple bundles exporting the
> >>>>>> org.osgi.service.http package, or if your tracking bundle has
> somehow
> >>>>>> included the org.osgi.service.http package instead of importing it.
> >>>>>>
> >>>>>> To check if this is the case, try changing the start() method of
> your
> >>>>>> Activator to call httpServiceTracker.open(true) rather than just
> >>>>>> httpServiceTracker.open(). This will force the tracker to find all
> >>>>>> HttpServices, even the incompatible ones. Of course you will soon
> get
> >>>>>> a ClassCastException when you try to use the returned service, so
> you
> >>>>>> need to fix the underlying problem. Doing this will simply tell you
> if
> >>>>>> that is indeed the problem.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Neil
> >>>>>>
> >>>>>> On Thu, Jan 29, 2009 at 1:48 PM, Vinicius Carvalho
> >>>>>> <vi...@caravelatech.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Hello all, sorry for always comming back on the same subject, but
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> tomorrow
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> is our deadline, and even we got some progress on the osgi front
> with
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> spring
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> (we now have services and dependency injection working). Nothing
> >>>>>>> seems
> >>>>>>> to
> >>>>>>> work on the HttpService integration.
> >>>>>>>
> >>>>>>> We tried almost everything to get equinox running inside a servlet
> >>>>>>> container. The documentation on equinox servlet bridge is almost
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> inexistent.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> We are not using their servletbridge since it starts the osgi
> >>>>>>> container
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> and
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> that is something we are doing in our code (following the sling
> >>>>>>> approach)
> >>>>>>>
> >>>>>>> What seems to be happening is that any service tracker registered
> to
> >>>>>>> HttpService never gets called, ever... We've seen this on the
> >>>>>>> OsgiManager
> >>>>>>> class, and now we decided to drop our own little servlet bundle:
> >>>>>>>
> >>>>>>> public class Activator implements BundleActivator {
> >>>>>>> private ServiceTracker httpServiceTracker;
> >>>>>>>
> >>>>>>> public void start(BundleContext context) throws Exception {
> >>>>>>> httpServiceTracker = new HttpServiceTracker(context);
> >>>>>>> httpServiceTracker.open();
> >>>>>>>
> >>>>>>> }
> >>>>>>>
> >>>>>>> public void stop(BundleContext arg0) throws Exception {
> >>>>>>> httpServiceTracker.close();
> >>>>>>> httpServiceTracker = null;
> >>>>>>> }
> >>>>>>>
> >>>>>>>
> >>>>>>> private class HttpServiceTracker extends ServiceTracker {
> >>>>>>>
> >>>>>>> public HttpServiceTracker(BundleContext context) {
> >>>>>>> super(context, HttpService.class.getName(), null);
> >>>>>>> }
> >>>>>>>
> >>>>>>> public Object addingService(ServiceReference reference) {
> >>>>>>> HttpService httpService = (HttpService)
> >>>>>>> context.getService(reference);
> >>>>>>> try {
> >>>>>>> httpService.registerServlet("/dummy", new
> >>>>>>> DummyServlet(),
> >>>>>>> null, null); //$NON-NLS-1$
> >>>>>>> } catch (Exception e) {
> >>>>>>> e.printStackTrace();
> >>>>>>> }
> >>>>>>> return httpService;
> >>>>>>> }
> >>>>>>>
> >>>>>>> public void removedService(ServiceReference reference, Object
> >>>>>>> service) {
> >>>>>>> HttpService httpService = (HttpService) service;
> >>>>>>> httpService.unregister("/dummy"); //$NON-NLS-1$
> >>>>>>> super.removedService(reference, service);
> >>>>>>> }
> >>>>>>> }
> >>>>>>> }
> >>>>>>>
> >>>>>>> Well, the adding servlet never gets called :(
> >>>>>>>
> >>>>>>> Here how we start the felix container:
> >>>>>>>
> >>>>>>> public void init() throws ServletException {
> >>>>>>> ServletContextResourceProvider rp = new
> >>>>>>> ServletContextResourceProvider(getServletContext());
> >>>>>>> Logger logger = new ServletContextLogger(getServletContext());
> >>>>>>> Map<Object, Object> props = loadProperties();
> >>>>>>> this.osl = new OSL(rp,props,logger);
> >>>>>>> this.delegatee = new HttpServiceServlet();
> >>>>>>> this.delegatee.init(getServletConfig());
> >>>>>>>
> >>>>>>> super.init();
> >>>>>>> }
> >>>>>>>
> >>>>>>> public class OSL implements BundleActivator {
> >>>>>>>
> >>>>>>> private Felix felix;
> >>>>>>> private ReadWriteLock felixLock;
> >>>>>>> private ResourceProvider resourceProvider;
> >>>>>>> private Logger logger;
> >>>>>>> private BundleActivator httpServiceActivator;
> >>>>>>>
> >>>>>>> public OSL(ResourceProvider rp, Map<Object, Object> props, Logger
> >>>>>>> logger){
> >>>>>>> this.resourceProvider = rp;
> >>>>>>> this.logger = logger;
> >>>>>>> List<BundleActivator> activators = new
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> ArrayList<BundleActivator>();
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> activators.add(this);
> >>>>>>> activators.add(new BootstrapInstaller(logger,rp));
> >>>>>>> props.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> activators);
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Felix tmpFelix = new Felix(props);
> >>>>>>> try {
> >>>>>>> tmpFelix.start();
> >>>>>>> this.felix = tmpFelix;
> >>>>>>> } catch (Exception e) {
> >>>>>>> e.printStackTrace();
> >>>>>>> }
> >>>>>>> }
> >>>>>>>
> >>>>>>> public void start(BundleContext context) throws Exception {
> >>>>>>> this.httpServiceActivator = new Activator();
> >>>>>>> this.httpServiceActivator.start(context);
> >>>>>>>
> >>>>>>> }
> >>>>>>>
> >>>>>>> As you can see, we are starting the Httpservice ourselves, we tried
> >>>>>>> to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> not
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> do so and pack it with the other bundles, but the effect is the
> same
> >>>>>>> (do
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> not
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> call the addingservice)
> >>>>>>>
> >>>>>>> After the complete startup we have these services:
> >>>>>>>
> >>>>>>> System Bundle (0) provides:
> >>>>>>> ---------------------------
> >>>>>>> org.osgi.service.startlevel.StartLevel
> >>>>>>> org.osgi.service.packageadmin.PackageAdmin
> >>>>>>> org.osgi.service.http.HttpService
> >>>>>>>
> >>>>>>>
> >>>>>>> So I guess the HttpService is up and running.
> >>>>>>>
> >>>>>>> Is there anything else that we could do? Any other point to look
> at,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> replace
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> class, packaging format, anything please. Tomorrow if we don't
> >>>>>>> present
> >>>>>>> at
> >>>>>>> least one servlet (we needed at least the GWT-RPC working but one
> >>>>>>> servlet
> >>>>>>> should do it), we may have to drop osgi for good, and that's
> >>>>>>> something
> >>>>>>> we
> >>>>>>> are really not willing to do :(
> >>>>>>>
> >>>>>>> Regards
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> 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
> >
> >
>
--
Cheers, Stuart
Re: ServiceTracker never gets called
Posted by Vinicius Carvalho <vi...@caravelatech.com>.
Thanks Felix, that final property was the last piece of the puzzle. We got
everything running now. The web console, our servlet, even a servlet that is
managed by spring (I've post an entry here:
http://forum.springsource.org/showthread.php?p=224265#post224265)
We are now heading for the final part of the Proof of Concept : The GWT
Servlet. Once this is done, we shall start the project with this
architecture
The sponsor got really excited with a simple feature for osgi, but an major
improvement for us:
We showed them a servlet listing all services, then, we went to the
web-console, stop a few, refresh the page, and then start them again. They
were able to see services comming and going, and that was exactly what they
were looking for.
Thanks everyone for the help so far.
On Fri, Jan 30, 2009 at 10:33 AM, Felix Meschberger <fm...@gmail.com>wrote:
> Hi Vinicius,
>
> Sorry to chime in late :-(
>
> Since you referred to Sling and I authored that stuff there, it is
> probably up to me to tell you more: As Neill pointed out, this is most
> certainly a classloader issue. In addition Stuart provided you the hint
> with the org.osgi.framework.system.packages framework property.
>
> So this is how we do this in Sling:
>
> In the Application Classloader (the WebApp Classloader in your case), we
> load the framework, the osgi-core, the osgi-compendium and the
> equinox-servlet libraries. In the org.osgi.framework.system.packages
> property will list all the org.osgi.* packages plus the javax.servlet.*
> packages such that the bundles deployed see the same API classes.
>
> This is how we get it to work in Sling. The drawback of this solution
> is, that we have to bundle the Compendium library with the web
> application instead of deploying it as a bundle.
>
> Hope this helps.
>
> Regards
> Felix
>
> Vinicius Carvalho schrieb:
> > Well, we got stuck again :(
> >
> > Here's the dilema:
> >
> > We need the ProxyServlet to handle requests, so it is loaded from
> > webappclassloader, so we need the equinox jar in our web-inf/lib
> > We need the Activator from equinox to get started outside the
> > webappclassloader, it has to be loaded by context classloader
> >
> > So we have this:
> >
> > WEB-INF/
> > lib/
> > equinox-servlet.jar
> >
> > bundles/
> > equinox-servlet.jar
> >
> >
> > Now, the problem happens here:
> >
> > ProxyServlet (from equinox) calls
> > Activator.addProxyServlet(this)
> >
> > The method:
> >
> > static synchronized void addProxyServlet(ProxyServlet proxyServlet) {
> > ServiceRegistration registration = null;
> > if (context != null)
> > registration = registerHttpService(proxyServlet);
> >
> > serviceRegistrations.put(proxyServlet, registration);
> > }
> >
> >
> > Ok, of course the damn context will be null, ProxyServlet was loaded by
> > webappclassloader whereas the Activator was started by our
> > contextclassloader
> >
> > So, no way we get HttpService registred this way.
> >
> > The other way around:
> >
> > Having our servlet starting equinox Activator:
> >
> > Well now we do have an HttpService installed as service but... It comes
> from
> > a differente classloader :( and can't be used by our bundles.
> >
> > I guess we hit a dead end here? Is there a solution for this?
> >
> > Regards
> >
> >
> >
> > On Thu, Jan 29, 2009 at 3:25 PM, Richard S. Hall <heavy@ungoverned.org
> >wrote:
> >
> >> Vinicius Carvalho wrote:
> >>
> >>> Sorry for the mess. Neil, I was just mentioning that you left a post at
> my
> >>> twitter a month ago. I read both books, and they are equally great.
> Some
> >>> things better in one, others in other. I do recommend everyone to get
> both
> >>> of em :)
> >>>
> >>>
> >> Don't worry, it's just Neil (he's British). ;-)
> >>
> >> -> richard
> >>
> >> On Thu, Jan 29, 2009 at 3:01 PM, Richard S. Hall <heavy@ungoverned.org
> >>>> wrote:
> >>>
> >>>
> >>>> Neil Bartlett wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Hi Vinicius,
> >>>>>
> >>>>> Glad to help, and thanks for your kind comments about my book.
> >>>>>
> >>>>> However I think it's the authors of "OSGi in Action" who are asking
> >>>>> for a book review at the moment, since they have just released some
> >>>>> chapters for early access. They are on this mailing list so can
> >>>>> probably clarify. My book is "OSGi in Practice". Yes, these two
> titles
> >>>>> are confusingly similar... my defence is that I started writing my
> >>>>> book first!
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> We aren't asking for a book review, but there was some review recently
> on
> >>>> DZone about the early access release from a few weeks back.
> >>>>
> >>>> Regarding the titles, we didn't really choose the title per se, but "X
> in
> >>>> Action" and even "X in Practice" titles are both Manning Publishing
> >>>> series
> >>>> books from what I understand. So you be the judge. ;-)
> >>>>
> >>>> -> richard
> >>>>
> >>>> Kind regards,
> >>>>
> >>>>
> >>>>> Neil
> >>>>>
> >>>>> On Thu, Jan 29, 2009 at 4:45 PM, Vinicius Carvalho
> >>>>> <vi...@caravelatech.com> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Bullseye! Thanks Neil. I've tested and got a ClassCastException ...
> >>>>>>
> >>>>>> We'll look into our code and check why is this happening. We've just
> >>>>>> tried,
> >>>>>> and in a debug breakpoint we've seen that the service returned by:
> >>>>>> HttpService httpService = (HttpService)
> >>>>>> context.getService(reference);
> >>>>>>
> >>>>>> Was indeed HttpServiceImpl, I guess we have a classloader problem.
> We
> >>>>>> have
> >>>>>> the equinox servletbridge inside webinf/lib, hence it's loaded by
> >>>>>> WebApplicationClassLoader. Since this bundle is loaded by
> >>>>>> ContextClassLoader
> >>>>>> that might be the problem, we don't know.
> >>>>>>
> >>>>>> I'll look into it. Thanks a lot for your help, it gave us hope again
> :)
> >>>>>>
> >>>>>> I owe you a book review (from your message at twitter.com). I've
> >>>>>> finished
> >>>>>> you book btw, best chapter is chapter 6 (concurrency is a subject
> that
> >>>>>> is
> >>>>>> not very well explained in most books, which is a shame since it
> lead
> >>>>>> to
> >>>>>> really annoying problems) Promise to write a few lines of revuew to
> you
> >>>>>> soon.
> >>>>>>
> >>>>>> Regards
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Jan 29, 2009 at 11:57 AM, Neil Bartlett <
> njbartlett@gmail.com
> >>>>>>
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> It's possible that the HttpService published in the service
> registry
> >>>>>>> is not compatible with your bundle that is trying to track it. This
> >>>>>>> could happen if you have multiple bundles exporting the
> >>>>>>> org.osgi.service.http package, or if your tracking bundle has
> somehow
> >>>>>>> included the org.osgi.service.http package instead of importing it.
> >>>>>>>
> >>>>>>> To check if this is the case, try changing the start() method of
> your
> >>>>>>> Activator to call httpServiceTracker.open(true) rather than just
> >>>>>>> httpServiceTracker.open(). This will force the tracker to find all
> >>>>>>> HttpServices, even the incompatible ones. Of course you will soon
> get
> >>>>>>> a ClassCastException when you try to use the returned service, so
> you
> >>>>>>> need to fix the underlying problem. Doing this will simply tell you
> if
> >>>>>>> that is indeed the problem.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Neil
> >>>>>>>
> >>>>>>> On Thu, Jan 29, 2009 at 1:48 PM, Vinicius Carvalho
> >>>>>>> <vi...@caravelatech.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Hello all, sorry for always comming back on the same subject, but
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> tomorrow
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> is our deadline, and even we got some progress on the osgi front
> with
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> spring
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> (we now have services and dependency injection working). Nothing
> >>>>>>>> seems
> >>>>>>>> to
> >>>>>>>> work on the HttpService integration.
> >>>>>>>>
> >>>>>>>> We tried almost everything to get equinox running inside a servlet
> >>>>>>>> container. The documentation on equinox servlet bridge is almost
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> inexistent.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> We are not using their servletbridge since it starts the osgi
> >>>>>>>> container
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> and
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> that is something we are doing in our code (following the sling
> >>>>>>>> approach)
> >>>>>>>>
> >>>>>>>> What seems to be happening is that any service tracker registered
> to
> >>>>>>>> HttpService never gets called, ever... We've seen this on the
> >>>>>>>> OsgiManager
> >>>>>>>> class, and now we decided to drop our own little servlet bundle:
> >>>>>>>>
> >>>>>>>> public class Activator implements BundleActivator {
> >>>>>>>> private ServiceTracker httpServiceTracker;
> >>>>>>>>
> >>>>>>>> public void start(BundleContext context) throws Exception {
> >>>>>>>> httpServiceTracker = new HttpServiceTracker(context);
> >>>>>>>> httpServiceTracker.open();
> >>>>>>>>
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> public void stop(BundleContext arg0) throws Exception {
> >>>>>>>> httpServiceTracker.close();
> >>>>>>>> httpServiceTracker = null;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> private class HttpServiceTracker extends ServiceTracker {
> >>>>>>>>
> >>>>>>>> public HttpServiceTracker(BundleContext context) {
> >>>>>>>> super(context, HttpService.class.getName(), null);
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> public Object addingService(ServiceReference reference) {
> >>>>>>>> HttpService httpService = (HttpService)
> >>>>>>>> context.getService(reference);
> >>>>>>>> try {
> >>>>>>>> httpService.registerServlet("/dummy", new
> >>>>>>>> DummyServlet(),
> >>>>>>>> null, null); //$NON-NLS-1$
> >>>>>>>> } catch (Exception e) {
> >>>>>>>> e.printStackTrace();
> >>>>>>>> }
> >>>>>>>> return httpService;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> public void removedService(ServiceReference reference, Object
> >>>>>>>> service) {
> >>>>>>>> HttpService httpService = (HttpService) service;
> >>>>>>>> httpService.unregister("/dummy"); //$NON-NLS-1$
> >>>>>>>> super.removedService(reference, service);
> >>>>>>>> }
> >>>>>>>> }
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> Well, the adding servlet never gets called :(
> >>>>>>>>
> >>>>>>>> Here how we start the felix container:
> >>>>>>>>
> >>>>>>>> public void init() throws ServletException {
> >>>>>>>> ServletContextResourceProvider rp = new
> >>>>>>>> ServletContextResourceProvider(getServletContext());
> >>>>>>>> Logger logger = new
> ServletContextLogger(getServletContext());
> >>>>>>>> Map<Object, Object> props = loadProperties();
> >>>>>>>> this.osl = new OSL(rp,props,logger);
> >>>>>>>> this.delegatee = new HttpServiceServlet();
> >>>>>>>> this.delegatee.init(getServletConfig());
> >>>>>>>>
> >>>>>>>> super.init();
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> public class OSL implements BundleActivator {
> >>>>>>>>
> >>>>>>>> private Felix felix;
> >>>>>>>> private ReadWriteLock felixLock;
> >>>>>>>> private ResourceProvider resourceProvider;
> >>>>>>>> private Logger logger;
> >>>>>>>> private BundleActivator httpServiceActivator;
> >>>>>>>>
> >>>>>>>> public OSL(ResourceProvider rp, Map<Object, Object> props, Logger
> >>>>>>>> logger){
> >>>>>>>> this.resourceProvider = rp;
> >>>>>>>> this.logger = logger;
> >>>>>>>> List<BundleActivator> activators = new
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> ArrayList<BundleActivator>();
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> activators.add(this);
> >>>>>>>> activators.add(new BootstrapInstaller(logger,rp));
> >>>>>>>> props.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> activators);
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Felix tmpFelix = new Felix(props);
> >>>>>>>> try {
> >>>>>>>> tmpFelix.start();
> >>>>>>>> this.felix = tmpFelix;
> >>>>>>>> } catch (Exception e) {
> >>>>>>>> e.printStackTrace();
> >>>>>>>> }
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> public void start(BundleContext context) throws Exception {
> >>>>>>>> this.httpServiceActivator = new Activator();
> >>>>>>>> this.httpServiceActivator.start(context);
> >>>>>>>>
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> As you can see, we are starting the Httpservice ourselves, we
> tried
> >>>>>>>> to
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> not
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> do so and pack it with the other bundles, but the effect is the
> same
> >>>>>>>> (do
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> not
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> call the addingservice)
> >>>>>>>>
> >>>>>>>> After the complete startup we have these services:
> >>>>>>>>
> >>>>>>>> System Bundle (0) provides:
> >>>>>>>> ---------------------------
> >>>>>>>> org.osgi.service.startlevel.StartLevel
> >>>>>>>> org.osgi.service.packageadmin.PackageAdmin
> >>>>>>>> org.osgi.service.http.HttpService
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> So I guess the HttpService is up and running.
> >>>>>>>>
> >>>>>>>> Is there anything else that we could do? Any other point to look
> at,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> replace
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> class, packaging format, anything please. Tomorrow if we don't
> >>>>>>>> present
> >>>>>>>> at
> >>>>>>>> least one servlet (we needed at least the GWT-RPC working but one
> >>>>>>>> servlet
> >>>>>>>> should do it), we may have to drop osgi for good, and that's
> >>>>>>>> something
> >>>>>>>> we
> >>>>>>>> are really not willing to do :(
> >>>>>>>>
> >>>>>>>> Regards
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> 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
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: ServiceTracker never gets called
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Vinicius,
Sorry to chime in late :-(
Since you referred to Sling and I authored that stuff there, it is
probably up to me to tell you more: As Neill pointed out, this is most
certainly a classloader issue. In addition Stuart provided you the hint
with the org.osgi.framework.system.packages framework property.
So this is how we do this in Sling:
In the Application Classloader (the WebApp Classloader in your case), we
load the framework, the osgi-core, the osgi-compendium and the
equinox-servlet libraries. In the org.osgi.framework.system.packages
property will list all the org.osgi.* packages plus the javax.servlet.*
packages such that the bundles deployed see the same API classes.
This is how we get it to work in Sling. The drawback of this solution
is, that we have to bundle the Compendium library with the web
application instead of deploying it as a bundle.
Hope this helps.
Regards
Felix
Vinicius Carvalho schrieb:
> Well, we got stuck again :(
>
> Here's the dilema:
>
> We need the ProxyServlet to handle requests, so it is loaded from
> webappclassloader, so we need the equinox jar in our web-inf/lib
> We need the Activator from equinox to get started outside the
> webappclassloader, it has to be loaded by context classloader
>
> So we have this:
>
> WEB-INF/
> lib/
> equinox-servlet.jar
>
> bundles/
> equinox-servlet.jar
>
>
> Now, the problem happens here:
>
> ProxyServlet (from equinox) calls
> Activator.addProxyServlet(this)
>
> The method:
>
> static synchronized void addProxyServlet(ProxyServlet proxyServlet) {
> ServiceRegistration registration = null;
> if (context != null)
> registration = registerHttpService(proxyServlet);
>
> serviceRegistrations.put(proxyServlet, registration);
> }
>
>
> Ok, of course the damn context will be null, ProxyServlet was loaded by
> webappclassloader whereas the Activator was started by our
> contextclassloader
>
> So, no way we get HttpService registred this way.
>
> The other way around:
>
> Having our servlet starting equinox Activator:
>
> Well now we do have an HttpService installed as service but... It comes from
> a differente classloader :( and can't be used by our bundles.
>
> I guess we hit a dead end here? Is there a solution for this?
>
> Regards
>
>
>
> On Thu, Jan 29, 2009 at 3:25 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> Vinicius Carvalho wrote:
>>
>>> Sorry for the mess. Neil, I was just mentioning that you left a post at my
>>> twitter a month ago. I read both books, and they are equally great. Some
>>> things better in one, others in other. I do recommend everyone to get both
>>> of em :)
>>>
>>>
>> Don't worry, it's just Neil (he's British). ;-)
>>
>> -> richard
>>
>> On Thu, Jan 29, 2009 at 3:01 PM, Richard S. Hall <heavy@ungoverned.org
>>>> wrote:
>>>
>>>
>>>> Neil Bartlett wrote:
>>>>
>>>>
>>>>
>>>>> Hi Vinicius,
>>>>>
>>>>> Glad to help, and thanks for your kind comments about my book.
>>>>>
>>>>> However I think it's the authors of "OSGi in Action" who are asking
>>>>> for a book review at the moment, since they have just released some
>>>>> chapters for early access. They are on this mailing list so can
>>>>> probably clarify. My book is "OSGi in Practice". Yes, these two titles
>>>>> are confusingly similar... my defence is that I started writing my
>>>>> book first!
>>>>>
>>>>>
>>>>>
>>>>>
>>>> We aren't asking for a book review, but there was some review recently on
>>>> DZone about the early access release from a few weeks back.
>>>>
>>>> Regarding the titles, we didn't really choose the title per se, but "X in
>>>> Action" and even "X in Practice" titles are both Manning Publishing
>>>> series
>>>> books from what I understand. So you be the judge. ;-)
>>>>
>>>> -> richard
>>>>
>>>> Kind regards,
>>>>
>>>>
>>>>> Neil
>>>>>
>>>>> On Thu, Jan 29, 2009 at 4:45 PM, Vinicius Carvalho
>>>>> <vi...@caravelatech.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Bullseye! Thanks Neil. I've tested and got a ClassCastException ...
>>>>>>
>>>>>> We'll look into our code and check why is this happening. We've just
>>>>>> tried,
>>>>>> and in a debug breakpoint we've seen that the service returned by:
>>>>>> HttpService httpService = (HttpService)
>>>>>> context.getService(reference);
>>>>>>
>>>>>> Was indeed HttpServiceImpl, I guess we have a classloader problem. We
>>>>>> have
>>>>>> the equinox servletbridge inside webinf/lib, hence it's loaded by
>>>>>> WebApplicationClassLoader. Since this bundle is loaded by
>>>>>> ContextClassLoader
>>>>>> that might be the problem, we don't know.
>>>>>>
>>>>>> I'll look into it. Thanks a lot for your help, it gave us hope again :)
>>>>>>
>>>>>> I owe you a book review (from your message at twitter.com). I've
>>>>>> finished
>>>>>> you book btw, best chapter is chapter 6 (concurrency is a subject that
>>>>>> is
>>>>>> not very well explained in most books, which is a shame since it lead
>>>>>> to
>>>>>> really annoying problems) Promise to write a few lines of revuew to you
>>>>>> soon.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 29, 2009 at 11:57 AM, Neil Bartlett <njbartlett@gmail.com
>>>>>>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>> It's possible that the HttpService published in the service registry
>>>>>>> is not compatible with your bundle that is trying to track it. This
>>>>>>> could happen if you have multiple bundles exporting the
>>>>>>> org.osgi.service.http package, or if your tracking bundle has somehow
>>>>>>> included the org.osgi.service.http package instead of importing it.
>>>>>>>
>>>>>>> To check if this is the case, try changing the start() method of your
>>>>>>> Activator to call httpServiceTracker.open(true) rather than just
>>>>>>> httpServiceTracker.open(). This will force the tracker to find all
>>>>>>> HttpServices, even the incompatible ones. Of course you will soon get
>>>>>>> a ClassCastException when you try to use the returned service, so you
>>>>>>> need to fix the underlying problem. Doing this will simply tell you if
>>>>>>> that is indeed the problem.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Neil
>>>>>>>
>>>>>>> On Thu, Jan 29, 2009 at 1:48 PM, Vinicius Carvalho
>>>>>>> <vi...@caravelatech.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hello all, sorry for always comming back on the same subject, but
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> tomorrow
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> is our deadline, and even we got some progress on the osgi front with
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> spring
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> (we now have services and dependency injection working). Nothing
>>>>>>>> seems
>>>>>>>> to
>>>>>>>> work on the HttpService integration.
>>>>>>>>
>>>>>>>> We tried almost everything to get equinox running inside a servlet
>>>>>>>> container. The documentation on equinox servlet bridge is almost
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> inexistent.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> We are not using their servletbridge since it starts the osgi
>>>>>>>> container
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> that is something we are doing in our code (following the sling
>>>>>>>> approach)
>>>>>>>>
>>>>>>>> What seems to be happening is that any service tracker registered to
>>>>>>>> HttpService never gets called, ever... We've seen this on the
>>>>>>>> OsgiManager
>>>>>>>> class, and now we decided to drop our own little servlet bundle:
>>>>>>>>
>>>>>>>> public class Activator implements BundleActivator {
>>>>>>>> private ServiceTracker httpServiceTracker;
>>>>>>>>
>>>>>>>> public void start(BundleContext context) throws Exception {
>>>>>>>> httpServiceTracker = new HttpServiceTracker(context);
>>>>>>>> httpServiceTracker.open();
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> public void stop(BundleContext arg0) throws Exception {
>>>>>>>> httpServiceTracker.close();
>>>>>>>> httpServiceTracker = null;
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> private class HttpServiceTracker extends ServiceTracker {
>>>>>>>>
>>>>>>>> public HttpServiceTracker(BundleContext context) {
>>>>>>>> super(context, HttpService.class.getName(), null);
>>>>>>>> }
>>>>>>>>
>>>>>>>> public Object addingService(ServiceReference reference) {
>>>>>>>> HttpService httpService = (HttpService)
>>>>>>>> context.getService(reference);
>>>>>>>> try {
>>>>>>>> httpService.registerServlet("/dummy", new
>>>>>>>> DummyServlet(),
>>>>>>>> null, null); //$NON-NLS-1$
>>>>>>>> } catch (Exception e) {
>>>>>>>> e.printStackTrace();
>>>>>>>> }
>>>>>>>> return httpService;
>>>>>>>> }
>>>>>>>>
>>>>>>>> public void removedService(ServiceReference reference, Object
>>>>>>>> service) {
>>>>>>>> HttpService httpService = (HttpService) service;
>>>>>>>> httpService.unregister("/dummy"); //$NON-NLS-1$
>>>>>>>> super.removedService(reference, service);
>>>>>>>> }
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> Well, the adding servlet never gets called :(
>>>>>>>>
>>>>>>>> Here how we start the felix container:
>>>>>>>>
>>>>>>>> public void init() throws ServletException {
>>>>>>>> ServletContextResourceProvider rp = new
>>>>>>>> ServletContextResourceProvider(getServletContext());
>>>>>>>> Logger logger = new ServletContextLogger(getServletContext());
>>>>>>>> Map<Object, Object> props = loadProperties();
>>>>>>>> this.osl = new OSL(rp,props,logger);
>>>>>>>> this.delegatee = new HttpServiceServlet();
>>>>>>>> this.delegatee.init(getServletConfig());
>>>>>>>>
>>>>>>>> super.init();
>>>>>>>> }
>>>>>>>>
>>>>>>>> public class OSL implements BundleActivator {
>>>>>>>>
>>>>>>>> private Felix felix;
>>>>>>>> private ReadWriteLock felixLock;
>>>>>>>> private ResourceProvider resourceProvider;
>>>>>>>> private Logger logger;
>>>>>>>> private BundleActivator httpServiceActivator;
>>>>>>>>
>>>>>>>> public OSL(ResourceProvider rp, Map<Object, Object> props, Logger
>>>>>>>> logger){
>>>>>>>> this.resourceProvider = rp;
>>>>>>>> this.logger = logger;
>>>>>>>> List<BundleActivator> activators = new
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ArrayList<BundleActivator>();
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> activators.add(this);
>>>>>>>> activators.add(new BootstrapInstaller(logger,rp));
>>>>>>>> props.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> activators);
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Felix tmpFelix = new Felix(props);
>>>>>>>> try {
>>>>>>>> tmpFelix.start();
>>>>>>>> this.felix = tmpFelix;
>>>>>>>> } catch (Exception e) {
>>>>>>>> e.printStackTrace();
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> public void start(BundleContext context) throws Exception {
>>>>>>>> this.httpServiceActivator = new Activator();
>>>>>>>> this.httpServiceActivator.start(context);
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> As you can see, we are starting the Httpservice ourselves, we tried
>>>>>>>> to
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> not
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> do so and pack it with the other bundles, but the effect is the same
>>>>>>>> (do
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> not
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> call the addingservice)
>>>>>>>>
>>>>>>>> After the complete startup we have these services:
>>>>>>>>
>>>>>>>> System Bundle (0) provides:
>>>>>>>> ---------------------------
>>>>>>>> org.osgi.service.startlevel.StartLevel
>>>>>>>> org.osgi.service.packageadmin.PackageAdmin
>>>>>>>> org.osgi.service.http.HttpService
>>>>>>>>
>>>>>>>>
>>>>>>>> So I guess the HttpService is up and running.
>>>>>>>>
>>>>>>>> Is there anything else that we could do? Any other point to look at,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> replace
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> class, packaging format, anything please. Tomorrow if we don't
>>>>>>>> present
>>>>>>>> at
>>>>>>>> least one servlet (we needed at least the GWT-RPC working but one
>>>>>>>> servlet
>>>>>>>> should do it), we may have to drop osgi for good, and that's
>>>>>>>> something
>>>>>>>> we
>>>>>>>> are really not willing to do :(
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ServiceTracker never gets called
Posted by Vinicius Carvalho <vi...@caravelatech.com>.
Well, we got stuck again :(
Here's the dilema:
We need the ProxyServlet to handle requests, so it is loaded from
webappclassloader, so we need the equinox jar in our web-inf/lib
We need the Activator from equinox to get started outside the
webappclassloader, it has to be loaded by context classloader
So we have this:
WEB-INF/
lib/
equinox-servlet.jar
bundles/
equinox-servlet.jar
Now, the problem happens here:
ProxyServlet (from equinox) calls
Activator.addProxyServlet(this)
The method:
static synchronized void addProxyServlet(ProxyServlet proxyServlet) {
ServiceRegistration registration = null;
if (context != null)
registration = registerHttpService(proxyServlet);
serviceRegistrations.put(proxyServlet, registration);
}
Ok, of course the damn context will be null, ProxyServlet was loaded by
webappclassloader whereas the Activator was started by our
contextclassloader
So, no way we get HttpService registred this way.
The other way around:
Having our servlet starting equinox Activator:
Well now we do have an HttpService installed as service but... It comes from
a differente classloader :( and can't be used by our bundles.
I guess we hit a dead end here? Is there a solution for this?
Regards
On Thu, Jan 29, 2009 at 3:25 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> Vinicius Carvalho wrote:
>
>> Sorry for the mess. Neil, I was just mentioning that you left a post at my
>> twitter a month ago. I read both books, and they are equally great. Some
>> things better in one, others in other. I do recommend everyone to get both
>> of em :)
>>
>>
>
> Don't worry, it's just Neil (he's British). ;-)
>
> -> richard
>
> On Thu, Jan 29, 2009 at 3:01 PM, Richard S. Hall <heavy@ungoverned.org
>> >wrote:
>>
>>
>>
>>> Neil Bartlett wrote:
>>>
>>>
>>>
>>>> Hi Vinicius,
>>>>
>>>> Glad to help, and thanks for your kind comments about my book.
>>>>
>>>> However I think it's the authors of "OSGi in Action" who are asking
>>>> for a book review at the moment, since they have just released some
>>>> chapters for early access. They are on this mailing list so can
>>>> probably clarify. My book is "OSGi in Practice". Yes, these two titles
>>>> are confusingly similar... my defence is that I started writing my
>>>> book first!
>>>>
>>>>
>>>>
>>>>
>>> We aren't asking for a book review, but there was some review recently on
>>> DZone about the early access release from a few weeks back.
>>>
>>> Regarding the titles, we didn't really choose the title per se, but "X in
>>> Action" and even "X in Practice" titles are both Manning Publishing
>>> series
>>> books from what I understand. So you be the judge. ;-)
>>>
>>> -> richard
>>>
>>> Kind regards,
>>>
>>>
>>>> Neil
>>>>
>>>> On Thu, Jan 29, 2009 at 4:45 PM, Vinicius Carvalho
>>>> <vi...@caravelatech.com> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Bullseye! Thanks Neil. I've tested and got a ClassCastException ...
>>>>>
>>>>> We'll look into our code and check why is this happening. We've just
>>>>> tried,
>>>>> and in a debug breakpoint we've seen that the service returned by:
>>>>> HttpService httpService = (HttpService)
>>>>> context.getService(reference);
>>>>>
>>>>> Was indeed HttpServiceImpl, I guess we have a classloader problem. We
>>>>> have
>>>>> the equinox servletbridge inside webinf/lib, hence it's loaded by
>>>>> WebApplicationClassLoader. Since this bundle is loaded by
>>>>> ContextClassLoader
>>>>> that might be the problem, we don't know.
>>>>>
>>>>> I'll look into it. Thanks a lot for your help, it gave us hope again :)
>>>>>
>>>>> I owe you a book review (from your message at twitter.com). I've
>>>>> finished
>>>>> you book btw, best chapter is chapter 6 (concurrency is a subject that
>>>>> is
>>>>> not very well explained in most books, which is a shame since it lead
>>>>> to
>>>>> really annoying problems) Promise to write a few lines of revuew to you
>>>>> soon.
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>>>> On Thu, Jan 29, 2009 at 11:57 AM, Neil Bartlett <njbartlett@gmail.com
>>>>>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> It's possible that the HttpService published in the service registry
>>>>>> is not compatible with your bundle that is trying to track it. This
>>>>>> could happen if you have multiple bundles exporting the
>>>>>> org.osgi.service.http package, or if your tracking bundle has somehow
>>>>>> included the org.osgi.service.http package instead of importing it.
>>>>>>
>>>>>> To check if this is the case, try changing the start() method of your
>>>>>> Activator to call httpServiceTracker.open(true) rather than just
>>>>>> httpServiceTracker.open(). This will force the tracker to find all
>>>>>> HttpServices, even the incompatible ones. Of course you will soon get
>>>>>> a ClassCastException when you try to use the returned service, so you
>>>>>> need to fix the underlying problem. Doing this will simply tell you if
>>>>>> that is indeed the problem.
>>>>>>
>>>>>> Regards,
>>>>>> Neil
>>>>>>
>>>>>> On Thu, Jan 29, 2009 at 1:48 PM, Vinicius Carvalho
>>>>>> <vi...@caravelatech.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hello all, sorry for always comming back on the same subject, but
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> tomorrow
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> is our deadline, and even we got some progress on the osgi front with
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> spring
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> (we now have services and dependency injection working). Nothing
>>>>>>> seems
>>>>>>> to
>>>>>>> work on the HttpService integration.
>>>>>>>
>>>>>>> We tried almost everything to get equinox running inside a servlet
>>>>>>> container. The documentation on equinox servlet bridge is almost
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> inexistent.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> We are not using their servletbridge since it starts the osgi
>>>>>>> container
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> and
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> that is something we are doing in our code (following the sling
>>>>>>> approach)
>>>>>>>
>>>>>>> What seems to be happening is that any service tracker registered to
>>>>>>> HttpService never gets called, ever... We've seen this on the
>>>>>>> OsgiManager
>>>>>>> class, and now we decided to drop our own little servlet bundle:
>>>>>>>
>>>>>>> public class Activator implements BundleActivator {
>>>>>>> private ServiceTracker httpServiceTracker;
>>>>>>>
>>>>>>> public void start(BundleContext context) throws Exception {
>>>>>>> httpServiceTracker = new HttpServiceTracker(context);
>>>>>>> httpServiceTracker.open();
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> public void stop(BundleContext arg0) throws Exception {
>>>>>>> httpServiceTracker.close();
>>>>>>> httpServiceTracker = null;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> private class HttpServiceTracker extends ServiceTracker {
>>>>>>>
>>>>>>> public HttpServiceTracker(BundleContext context) {
>>>>>>> super(context, HttpService.class.getName(), null);
>>>>>>> }
>>>>>>>
>>>>>>> public Object addingService(ServiceReference reference) {
>>>>>>> HttpService httpService = (HttpService)
>>>>>>> context.getService(reference);
>>>>>>> try {
>>>>>>> httpService.registerServlet("/dummy", new
>>>>>>> DummyServlet(),
>>>>>>> null, null); //$NON-NLS-1$
>>>>>>> } catch (Exception e) {
>>>>>>> e.printStackTrace();
>>>>>>> }
>>>>>>> return httpService;
>>>>>>> }
>>>>>>>
>>>>>>> public void removedService(ServiceReference reference, Object
>>>>>>> service) {
>>>>>>> HttpService httpService = (HttpService) service;
>>>>>>> httpService.unregister("/dummy"); //$NON-NLS-1$
>>>>>>> super.removedService(reference, service);
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> Well, the adding servlet never gets called :(
>>>>>>>
>>>>>>> Here how we start the felix container:
>>>>>>>
>>>>>>> public void init() throws ServletException {
>>>>>>> ServletContextResourceProvider rp = new
>>>>>>> ServletContextResourceProvider(getServletContext());
>>>>>>> Logger logger = new ServletContextLogger(getServletContext());
>>>>>>> Map<Object, Object> props = loadProperties();
>>>>>>> this.osl = new OSL(rp,props,logger);
>>>>>>> this.delegatee = new HttpServiceServlet();
>>>>>>> this.delegatee.init(getServletConfig());
>>>>>>>
>>>>>>> super.init();
>>>>>>> }
>>>>>>>
>>>>>>> public class OSL implements BundleActivator {
>>>>>>>
>>>>>>> private Felix felix;
>>>>>>> private ReadWriteLock felixLock;
>>>>>>> private ResourceProvider resourceProvider;
>>>>>>> private Logger logger;
>>>>>>> private BundleActivator httpServiceActivator;
>>>>>>>
>>>>>>> public OSL(ResourceProvider rp, Map<Object, Object> props, Logger
>>>>>>> logger){
>>>>>>> this.resourceProvider = rp;
>>>>>>> this.logger = logger;
>>>>>>> List<BundleActivator> activators = new
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ArrayList<BundleActivator>();
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> activators.add(this);
>>>>>>> activators.add(new BootstrapInstaller(logger,rp));
>>>>>>> props.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> activators);
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Felix tmpFelix = new Felix(props);
>>>>>>> try {
>>>>>>> tmpFelix.start();
>>>>>>> this.felix = tmpFelix;
>>>>>>> } catch (Exception e) {
>>>>>>> e.printStackTrace();
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> public void start(BundleContext context) throws Exception {
>>>>>>> this.httpServiceActivator = new Activator();
>>>>>>> this.httpServiceActivator.start(context);
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> As you can see, we are starting the Httpservice ourselves, we tried
>>>>>>> to
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> not
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> do so and pack it with the other bundles, but the effect is the same
>>>>>>> (do
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> not
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> call the addingservice)
>>>>>>>
>>>>>>> After the complete startup we have these services:
>>>>>>>
>>>>>>> System Bundle (0) provides:
>>>>>>> ---------------------------
>>>>>>> org.osgi.service.startlevel.StartLevel
>>>>>>> org.osgi.service.packageadmin.PackageAdmin
>>>>>>> org.osgi.service.http.HttpService
>>>>>>>
>>>>>>>
>>>>>>> So I guess the HttpService is up and running.
>>>>>>>
>>>>>>> Is there anything else that we could do? Any other point to look at,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> replace
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> class, packaging format, anything please. Tomorrow if we don't
>>>>>>> present
>>>>>>> at
>>>>>>> least one servlet (we needed at least the GWT-RPC working but one
>>>>>>> servlet
>>>>>>> should do it), we may have to drop osgi for good, and that's
>>>>>>> something
>>>>>>> we
>>>>>>> are really not willing to do :(
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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: ServiceTracker never gets called
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Vinicius Carvalho wrote:
> Sorry for the mess. Neil, I was just mentioning that you left a post at my
> twitter a month ago. I read both books, and they are equally great. Some
> things better in one, others in other. I do recommend everyone to get both
> of em :)
>
Don't worry, it's just Neil (he's British). ;-)
-> richard
> On Thu, Jan 29, 2009 at 3:01 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>
>> Neil Bartlett wrote:
>>
>>
>>> Hi Vinicius,
>>>
>>> Glad to help, and thanks for your kind comments about my book.
>>>
>>> However I think it's the authors of "OSGi in Action" who are asking
>>> for a book review at the moment, since they have just released some
>>> chapters for early access. They are on this mailing list so can
>>> probably clarify. My book is "OSGi in Practice". Yes, these two titles
>>> are confusingly similar... my defence is that I started writing my
>>> book first!
>>>
>>>
>>>
>> We aren't asking for a book review, but there was some review recently on
>> DZone about the early access release from a few weeks back.
>>
>> Regarding the titles, we didn't really choose the title per se, but "X in
>> Action" and even "X in Practice" titles are both Manning Publishing series
>> books from what I understand. So you be the judge. ;-)
>>
>> -> richard
>>
>> Kind regards,
>>
>>> Neil
>>>
>>> On Thu, Jan 29, 2009 at 4:45 PM, Vinicius Carvalho
>>> <vi...@caravelatech.com> wrote:
>>>
>>>
>>>
>>>> Bullseye! Thanks Neil. I've tested and got a ClassCastException ...
>>>>
>>>> We'll look into our code and check why is this happening. We've just
>>>> tried,
>>>> and in a debug breakpoint we've seen that the service returned by:
>>>> HttpService httpService = (HttpService)
>>>> context.getService(reference);
>>>>
>>>> Was indeed HttpServiceImpl, I guess we have a classloader problem. We
>>>> have
>>>> the equinox servletbridge inside webinf/lib, hence it's loaded by
>>>> WebApplicationClassLoader. Since this bundle is loaded by
>>>> ContextClassLoader
>>>> that might be the problem, we don't know.
>>>>
>>>> I'll look into it. Thanks a lot for your help, it gave us hope again :)
>>>>
>>>> I owe you a book review (from your message at twitter.com). I've
>>>> finished
>>>> you book btw, best chapter is chapter 6 (concurrency is a subject that is
>>>> not very well explained in most books, which is a shame since it lead to
>>>> really annoying problems) Promise to write a few lines of revuew to you
>>>> soon.
>>>>
>>>> Regards
>>>>
>>>>
>>>> On Thu, Jan 29, 2009 at 11:57 AM, Neil Bartlett <njbartlett@gmail.com
>>>>
>>>>> wrote:
>>>>>
>>>>
>>>>
>>>>> It's possible that the HttpService published in the service registry
>>>>> is not compatible with your bundle that is trying to track it. This
>>>>> could happen if you have multiple bundles exporting the
>>>>> org.osgi.service.http package, or if your tracking bundle has somehow
>>>>> included the org.osgi.service.http package instead of importing it.
>>>>>
>>>>> To check if this is the case, try changing the start() method of your
>>>>> Activator to call httpServiceTracker.open(true) rather than just
>>>>> httpServiceTracker.open(). This will force the tracker to find all
>>>>> HttpServices, even the incompatible ones. Of course you will soon get
>>>>> a ClassCastException when you try to use the returned service, so you
>>>>> need to fix the underlying problem. Doing this will simply tell you if
>>>>> that is indeed the problem.
>>>>>
>>>>> Regards,
>>>>> Neil
>>>>>
>>>>> On Thu, Jan 29, 2009 at 1:48 PM, Vinicius Carvalho
>>>>> <vi...@caravelatech.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hello all, sorry for always comming back on the same subject, but
>>>>>>
>>>>>>
>>>>>>
>>>>> tomorrow
>>>>>
>>>>>
>>>>>
>>>>>> is our deadline, and even we got some progress on the osgi front with
>>>>>>
>>>>>>
>>>>>>
>>>>> spring
>>>>>
>>>>>
>>>>>
>>>>>> (we now have services and dependency injection working). Nothing seems
>>>>>> to
>>>>>> work on the HttpService integration.
>>>>>>
>>>>>> We tried almost everything to get equinox running inside a servlet
>>>>>> container. The documentation on equinox servlet bridge is almost
>>>>>>
>>>>>>
>>>>>>
>>>>> inexistent.
>>>>>
>>>>>
>>>>>
>>>>>> We are not using their servletbridge since it starts the osgi container
>>>>>>
>>>>>>
>>>>>>
>>>>> and
>>>>>
>>>>>
>>>>>
>>>>>> that is something we are doing in our code (following the sling
>>>>>> approach)
>>>>>>
>>>>>> What seems to be happening is that any service tracker registered to
>>>>>> HttpService never gets called, ever... We've seen this on the
>>>>>> OsgiManager
>>>>>> class, and now we decided to drop our own little servlet bundle:
>>>>>>
>>>>>> public class Activator implements BundleActivator {
>>>>>> private ServiceTracker httpServiceTracker;
>>>>>>
>>>>>> public void start(BundleContext context) throws Exception {
>>>>>> httpServiceTracker = new HttpServiceTracker(context);
>>>>>> httpServiceTracker.open();
>>>>>>
>>>>>> }
>>>>>>
>>>>>> public void stop(BundleContext arg0) throws Exception {
>>>>>> httpServiceTracker.close();
>>>>>> httpServiceTracker = null;
>>>>>> }
>>>>>>
>>>>>>
>>>>>> private class HttpServiceTracker extends ServiceTracker {
>>>>>>
>>>>>> public HttpServiceTracker(BundleContext context) {
>>>>>> super(context, HttpService.class.getName(), null);
>>>>>> }
>>>>>>
>>>>>> public Object addingService(ServiceReference reference) {
>>>>>> HttpService httpService = (HttpService)
>>>>>> context.getService(reference);
>>>>>> try {
>>>>>> httpService.registerServlet("/dummy", new DummyServlet(),
>>>>>> null, null); //$NON-NLS-1$
>>>>>> } catch (Exception e) {
>>>>>> e.printStackTrace();
>>>>>> }
>>>>>> return httpService;
>>>>>> }
>>>>>>
>>>>>> public void removedService(ServiceReference reference, Object
>>>>>> service) {
>>>>>> HttpService httpService = (HttpService) service;
>>>>>> httpService.unregister("/dummy"); //$NON-NLS-1$
>>>>>> super.removedService(reference, service);
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Well, the adding servlet never gets called :(
>>>>>>
>>>>>> Here how we start the felix container:
>>>>>>
>>>>>> public void init() throws ServletException {
>>>>>> ServletContextResourceProvider rp = new
>>>>>> ServletContextResourceProvider(getServletContext());
>>>>>> Logger logger = new ServletContextLogger(getServletContext());
>>>>>> Map<Object, Object> props = loadProperties();
>>>>>> this.osl = new OSL(rp,props,logger);
>>>>>> this.delegatee = new HttpServiceServlet();
>>>>>> this.delegatee.init(getServletConfig());
>>>>>>
>>>>>> super.init();
>>>>>> }
>>>>>>
>>>>>> public class OSL implements BundleActivator {
>>>>>>
>>>>>> private Felix felix;
>>>>>> private ReadWriteLock felixLock;
>>>>>> private ResourceProvider resourceProvider;
>>>>>> private Logger logger;
>>>>>> private BundleActivator httpServiceActivator;
>>>>>>
>>>>>> public OSL(ResourceProvider rp, Map<Object, Object> props, Logger
>>>>>> logger){
>>>>>> this.resourceProvider = rp;
>>>>>> this.logger = logger;
>>>>>> List<BundleActivator> activators = new
>>>>>>
>>>>>>
>>>>>>
>>>>> ArrayList<BundleActivator>();
>>>>>
>>>>>
>>>>>
>>>>>> activators.add(this);
>>>>>> activators.add(new BootstrapInstaller(logger,rp));
>>>>>> props.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
>>>>>>
>>>>>>
>>>>>>
>>>>> activators);
>>>>>
>>>>>
>>>>>
>>>>>> Felix tmpFelix = new Felix(props);
>>>>>> try {
>>>>>> tmpFelix.start();
>>>>>> this.felix = tmpFelix;
>>>>>> } catch (Exception e) {
>>>>>> e.printStackTrace();
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> public void start(BundleContext context) throws Exception {
>>>>>> this.httpServiceActivator = new Activator();
>>>>>> this.httpServiceActivator.start(context);
>>>>>>
>>>>>> }
>>>>>>
>>>>>> As you can see, we are starting the Httpservice ourselves, we tried to
>>>>>>
>>>>>>
>>>>>>
>>>>> not
>>>>>
>>>>>
>>>>>
>>>>>> do so and pack it with the other bundles, but the effect is the same
>>>>>> (do
>>>>>>
>>>>>>
>>>>>>
>>>>> not
>>>>>
>>>>>
>>>>>
>>>>>> call the addingservice)
>>>>>>
>>>>>> After the complete startup we have these services:
>>>>>>
>>>>>> System Bundle (0) provides:
>>>>>> ---------------------------
>>>>>> org.osgi.service.startlevel.StartLevel
>>>>>> org.osgi.service.packageadmin.PackageAdmin
>>>>>> org.osgi.service.http.HttpService
>>>>>>
>>>>>>
>>>>>> So I guess the HttpService is up and running.
>>>>>>
>>>>>> Is there anything else that we could do? Any other point to look at,
>>>>>>
>>>>>>
>>>>>>
>>>>> replace
>>>>>
>>>>>
>>>>>
>>>>>> class, packaging format, anything please. Tomorrow if we don't present
>>>>>> at
>>>>>> least one servlet (we needed at least the GWT-RPC working but one
>>>>>> servlet
>>>>>> should do it), we may have to drop osgi for good, and that's something
>>>>>> we
>>>>>> are really not willing to do :(
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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: ServiceTracker never gets called
Posted by Vinicius Carvalho <vi...@caravelatech.com>.
Sorry for the mess. Neil, I was just mentioning that you left a post at my
twitter a month ago. I read both books, and they are equally great. Some
things better in one, others in other. I do recommend everyone to get both
of em :)
On Thu, Jan 29, 2009 at 3:01 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> Neil Bartlett wrote:
>
>> Hi Vinicius,
>>
>> Glad to help, and thanks for your kind comments about my book.
>>
>> However I think it's the authors of "OSGi in Action" who are asking
>> for a book review at the moment, since they have just released some
>> chapters for early access. They are on this mailing list so can
>> probably clarify. My book is "OSGi in Practice". Yes, these two titles
>> are confusingly similar... my defence is that I started writing my
>> book first!
>>
>>
>
> We aren't asking for a book review, but there was some review recently on
> DZone about the early access release from a few weeks back.
>
> Regarding the titles, we didn't really choose the title per se, but "X in
> Action" and even "X in Practice" titles are both Manning Publishing series
> books from what I understand. So you be the judge. ;-)
>
> -> richard
>
> Kind regards,
>> Neil
>>
>> On Thu, Jan 29, 2009 at 4:45 PM, Vinicius Carvalho
>> <vi...@caravelatech.com> wrote:
>>
>>
>>> Bullseye! Thanks Neil. I've tested and got a ClassCastException ...
>>>
>>> We'll look into our code and check why is this happening. We've just
>>> tried,
>>> and in a debug breakpoint we've seen that the service returned by:
>>> HttpService httpService = (HttpService)
>>> context.getService(reference);
>>>
>>> Was indeed HttpServiceImpl, I guess we have a classloader problem. We
>>> have
>>> the equinox servletbridge inside webinf/lib, hence it's loaded by
>>> WebApplicationClassLoader. Since this bundle is loaded by
>>> ContextClassLoader
>>> that might be the problem, we don't know.
>>>
>>> I'll look into it. Thanks a lot for your help, it gave us hope again :)
>>>
>>> I owe you a book review (from your message at twitter.com). I've
>>> finished
>>> you book btw, best chapter is chapter 6 (concurrency is a subject that is
>>> not very well explained in most books, which is a shame since it lead to
>>> really annoying problems) Promise to write a few lines of revuew to you
>>> soon.
>>>
>>> Regards
>>>
>>>
>>> On Thu, Jan 29, 2009 at 11:57 AM, Neil Bartlett <njbartlett@gmail.com
>>> >wrote:
>>>
>>>
>>>
>>>> It's possible that the HttpService published in the service registry
>>>> is not compatible with your bundle that is trying to track it. This
>>>> could happen if you have multiple bundles exporting the
>>>> org.osgi.service.http package, or if your tracking bundle has somehow
>>>> included the org.osgi.service.http package instead of importing it.
>>>>
>>>> To check if this is the case, try changing the start() method of your
>>>> Activator to call httpServiceTracker.open(true) rather than just
>>>> httpServiceTracker.open(). This will force the tracker to find all
>>>> HttpServices, even the incompatible ones. Of course you will soon get
>>>> a ClassCastException when you try to use the returned service, so you
>>>> need to fix the underlying problem. Doing this will simply tell you if
>>>> that is indeed the problem.
>>>>
>>>> Regards,
>>>> Neil
>>>>
>>>> On Thu, Jan 29, 2009 at 1:48 PM, Vinicius Carvalho
>>>> <vi...@caravelatech.com> wrote:
>>>>
>>>>
>>>>> Hello all, sorry for always comming back on the same subject, but
>>>>>
>>>>>
>>>> tomorrow
>>>>
>>>>
>>>>> is our deadline, and even we got some progress on the osgi front with
>>>>>
>>>>>
>>>> spring
>>>>
>>>>
>>>>> (we now have services and dependency injection working). Nothing seems
>>>>> to
>>>>> work on the HttpService integration.
>>>>>
>>>>> We tried almost everything to get equinox running inside a servlet
>>>>> container. The documentation on equinox servlet bridge is almost
>>>>>
>>>>>
>>>> inexistent.
>>>>
>>>>
>>>>> We are not using their servletbridge since it starts the osgi container
>>>>>
>>>>>
>>>> and
>>>>
>>>>
>>>>> that is something we are doing in our code (following the sling
>>>>> approach)
>>>>>
>>>>> What seems to be happening is that any service tracker registered to
>>>>> HttpService never gets called, ever... We've seen this on the
>>>>> OsgiManager
>>>>> class, and now we decided to drop our own little servlet bundle:
>>>>>
>>>>> public class Activator implements BundleActivator {
>>>>> private ServiceTracker httpServiceTracker;
>>>>>
>>>>> public void start(BundleContext context) throws Exception {
>>>>> httpServiceTracker = new HttpServiceTracker(context);
>>>>> httpServiceTracker.open();
>>>>>
>>>>> }
>>>>>
>>>>> public void stop(BundleContext arg0) throws Exception {
>>>>> httpServiceTracker.close();
>>>>> httpServiceTracker = null;
>>>>> }
>>>>>
>>>>>
>>>>> private class HttpServiceTracker extends ServiceTracker {
>>>>>
>>>>> public HttpServiceTracker(BundleContext context) {
>>>>> super(context, HttpService.class.getName(), null);
>>>>> }
>>>>>
>>>>> public Object addingService(ServiceReference reference) {
>>>>> HttpService httpService = (HttpService)
>>>>> context.getService(reference);
>>>>> try {
>>>>> httpService.registerServlet("/dummy", new DummyServlet(),
>>>>> null, null); //$NON-NLS-1$
>>>>> } catch (Exception e) {
>>>>> e.printStackTrace();
>>>>> }
>>>>> return httpService;
>>>>> }
>>>>>
>>>>> public void removedService(ServiceReference reference, Object
>>>>> service) {
>>>>> HttpService httpService = (HttpService) service;
>>>>> httpService.unregister("/dummy"); //$NON-NLS-1$
>>>>> super.removedService(reference, service);
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>> Well, the adding servlet never gets called :(
>>>>>
>>>>> Here how we start the felix container:
>>>>>
>>>>> public void init() throws ServletException {
>>>>> ServletContextResourceProvider rp = new
>>>>> ServletContextResourceProvider(getServletContext());
>>>>> Logger logger = new ServletContextLogger(getServletContext());
>>>>> Map<Object, Object> props = loadProperties();
>>>>> this.osl = new OSL(rp,props,logger);
>>>>> this.delegatee = new HttpServiceServlet();
>>>>> this.delegatee.init(getServletConfig());
>>>>>
>>>>> super.init();
>>>>> }
>>>>>
>>>>> public class OSL implements BundleActivator {
>>>>>
>>>>> private Felix felix;
>>>>> private ReadWriteLock felixLock;
>>>>> private ResourceProvider resourceProvider;
>>>>> private Logger logger;
>>>>> private BundleActivator httpServiceActivator;
>>>>>
>>>>> public OSL(ResourceProvider rp, Map<Object, Object> props, Logger
>>>>> logger){
>>>>> this.resourceProvider = rp;
>>>>> this.logger = logger;
>>>>> List<BundleActivator> activators = new
>>>>>
>>>>>
>>>> ArrayList<BundleActivator>();
>>>>
>>>>
>>>>> activators.add(this);
>>>>> activators.add(new BootstrapInstaller(logger,rp));
>>>>> props.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
>>>>>
>>>>>
>>>> activators);
>>>>
>>>>
>>>>> Felix tmpFelix = new Felix(props);
>>>>> try {
>>>>> tmpFelix.start();
>>>>> this.felix = tmpFelix;
>>>>> } catch (Exception e) {
>>>>> e.printStackTrace();
>>>>> }
>>>>> }
>>>>>
>>>>> public void start(BundleContext context) throws Exception {
>>>>> this.httpServiceActivator = new Activator();
>>>>> this.httpServiceActivator.start(context);
>>>>>
>>>>> }
>>>>>
>>>>> As you can see, we are starting the Httpservice ourselves, we tried to
>>>>>
>>>>>
>>>> not
>>>>
>>>>
>>>>> do so and pack it with the other bundles, but the effect is the same
>>>>> (do
>>>>>
>>>>>
>>>> not
>>>>
>>>>
>>>>> call the addingservice)
>>>>>
>>>>> After the complete startup we have these services:
>>>>>
>>>>> System Bundle (0) provides:
>>>>> ---------------------------
>>>>> org.osgi.service.startlevel.StartLevel
>>>>> org.osgi.service.packageadmin.PackageAdmin
>>>>> org.osgi.service.http.HttpService
>>>>>
>>>>>
>>>>> So I guess the HttpService is up and running.
>>>>>
>>>>> Is there anything else that we could do? Any other point to look at,
>>>>>
>>>>>
>>>> replace
>>>>
>>>>
>>>>> class, packaging format, anything please. Tomorrow if we don't present
>>>>> at
>>>>> least one servlet (we needed at least the GWT-RPC working but one
>>>>> servlet
>>>>> should do it), we may have to drop osgi for good, and that's something
>>>>> we
>>>>> are really not willing to do :(
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: ServiceTracker never gets called
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Neil Bartlett wrote:
> Hi Vinicius,
>
> Glad to help, and thanks for your kind comments about my book.
>
> However I think it's the authors of "OSGi in Action" who are asking
> for a book review at the moment, since they have just released some
> chapters for early access. They are on this mailing list so can
> probably clarify. My book is "OSGi in Practice". Yes, these two titles
> are confusingly similar... my defence is that I started writing my
> book first!
>
We aren't asking for a book review, but there was some review recently
on DZone about the early access release from a few weeks back.
Regarding the titles, we didn't really choose the title per se, but "X
in Action" and even "X in Practice" titles are both Manning Publishing
series books from what I understand. So you be the judge. ;-)
-> richard
> Kind regards,
> Neil
>
> On Thu, Jan 29, 2009 at 4:45 PM, Vinicius Carvalho
> <vi...@caravelatech.com> wrote:
>
>> Bullseye! Thanks Neil. I've tested and got a ClassCastException ...
>>
>> We'll look into our code and check why is this happening. We've just tried,
>> and in a debug breakpoint we've seen that the service returned by:
>> HttpService httpService = (HttpService)
>> context.getService(reference);
>>
>> Was indeed HttpServiceImpl, I guess we have a classloader problem. We have
>> the equinox servletbridge inside webinf/lib, hence it's loaded by
>> WebApplicationClassLoader. Since this bundle is loaded by ContextClassLoader
>> that might be the problem, we don't know.
>>
>> I'll look into it. Thanks a lot for your help, it gave us hope again :)
>>
>> I owe you a book review (from your message at twitter.com). I've finished
>> you book btw, best chapter is chapter 6 (concurrency is a subject that is
>> not very well explained in most books, which is a shame since it lead to
>> really annoying problems) Promise to write a few lines of revuew to you
>> soon.
>>
>> Regards
>>
>>
>> On Thu, Jan 29, 2009 at 11:57 AM, Neil Bartlett <nj...@gmail.com>wrote:
>>
>>
>>> It's possible that the HttpService published in the service registry
>>> is not compatible with your bundle that is trying to track it. This
>>> could happen if you have multiple bundles exporting the
>>> org.osgi.service.http package, or if your tracking bundle has somehow
>>> included the org.osgi.service.http package instead of importing it.
>>>
>>> To check if this is the case, try changing the start() method of your
>>> Activator to call httpServiceTracker.open(true) rather than just
>>> httpServiceTracker.open(). This will force the tracker to find all
>>> HttpServices, even the incompatible ones. Of course you will soon get
>>> a ClassCastException when you try to use the returned service, so you
>>> need to fix the underlying problem. Doing this will simply tell you if
>>> that is indeed the problem.
>>>
>>> Regards,
>>> Neil
>>>
>>> On Thu, Jan 29, 2009 at 1:48 PM, Vinicius Carvalho
>>> <vi...@caravelatech.com> wrote:
>>>
>>>> Hello all, sorry for always comming back on the same subject, but
>>>>
>>> tomorrow
>>>
>>>> is our deadline, and even we got some progress on the osgi front with
>>>>
>>> spring
>>>
>>>> (we now have services and dependency injection working). Nothing seems to
>>>> work on the HttpService integration.
>>>>
>>>> We tried almost everything to get equinox running inside a servlet
>>>> container. The documentation on equinox servlet bridge is almost
>>>>
>>> inexistent.
>>>
>>>> We are not using their servletbridge since it starts the osgi container
>>>>
>>> and
>>>
>>>> that is something we are doing in our code (following the sling approach)
>>>>
>>>> What seems to be happening is that any service tracker registered to
>>>> HttpService never gets called, ever... We've seen this on the OsgiManager
>>>> class, and now we decided to drop our own little servlet bundle:
>>>>
>>>> public class Activator implements BundleActivator {
>>>> private ServiceTracker httpServiceTracker;
>>>>
>>>> public void start(BundleContext context) throws Exception {
>>>> httpServiceTracker = new HttpServiceTracker(context);
>>>> httpServiceTracker.open();
>>>>
>>>> }
>>>>
>>>> public void stop(BundleContext arg0) throws Exception {
>>>> httpServiceTracker.close();
>>>> httpServiceTracker = null;
>>>> }
>>>>
>>>>
>>>> private class HttpServiceTracker extends ServiceTracker {
>>>>
>>>> public HttpServiceTracker(BundleContext context) {
>>>> super(context, HttpService.class.getName(), null);
>>>> }
>>>>
>>>> public Object addingService(ServiceReference reference) {
>>>> HttpService httpService = (HttpService)
>>>> context.getService(reference);
>>>> try {
>>>> httpService.registerServlet("/dummy", new DummyServlet(),
>>>> null, null); //$NON-NLS-1$
>>>> } catch (Exception e) {
>>>> e.printStackTrace();
>>>> }
>>>> return httpService;
>>>> }
>>>>
>>>> public void removedService(ServiceReference reference, Object
>>>> service) {
>>>> HttpService httpService = (HttpService) service;
>>>> httpService.unregister("/dummy"); //$NON-NLS-1$
>>>> super.removedService(reference, service);
>>>> }
>>>> }
>>>> }
>>>>
>>>> Well, the adding servlet never gets called :(
>>>>
>>>> Here how we start the felix container:
>>>>
>>>> public void init() throws ServletException {
>>>> ServletContextResourceProvider rp = new
>>>> ServletContextResourceProvider(getServletContext());
>>>> Logger logger = new ServletContextLogger(getServletContext());
>>>> Map<Object, Object> props = loadProperties();
>>>> this.osl = new OSL(rp,props,logger);
>>>> this.delegatee = new HttpServiceServlet();
>>>> this.delegatee.init(getServletConfig());
>>>>
>>>> super.init();
>>>> }
>>>>
>>>> public class OSL implements BundleActivator {
>>>>
>>>> private Felix felix;
>>>> private ReadWriteLock felixLock;
>>>> private ResourceProvider resourceProvider;
>>>> private Logger logger;
>>>> private BundleActivator httpServiceActivator;
>>>>
>>>> public OSL(ResourceProvider rp, Map<Object, Object> props, Logger
>>>> logger){
>>>> this.resourceProvider = rp;
>>>> this.logger = logger;
>>>> List<BundleActivator> activators = new
>>>>
>>> ArrayList<BundleActivator>();
>>>
>>>> activators.add(this);
>>>> activators.add(new BootstrapInstaller(logger,rp));
>>>> props.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
>>>>
>>> activators);
>>>
>>>> Felix tmpFelix = new Felix(props);
>>>> try {
>>>> tmpFelix.start();
>>>> this.felix = tmpFelix;
>>>> } catch (Exception e) {
>>>> e.printStackTrace();
>>>> }
>>>> }
>>>>
>>>> public void start(BundleContext context) throws Exception {
>>>> this.httpServiceActivator = new Activator();
>>>> this.httpServiceActivator.start(context);
>>>>
>>>> }
>>>>
>>>> As you can see, we are starting the Httpservice ourselves, we tried to
>>>>
>>> not
>>>
>>>> do so and pack it with the other bundles, but the effect is the same (do
>>>>
>>> not
>>>
>>>> call the addingservice)
>>>>
>>>> After the complete startup we have these services:
>>>>
>>>> System Bundle (0) provides:
>>>> ---------------------------
>>>> org.osgi.service.startlevel.StartLevel
>>>> org.osgi.service.packageadmin.PackageAdmin
>>>> org.osgi.service.http.HttpService
>>>>
>>>>
>>>> So I guess the HttpService is up and running.
>>>>
>>>> Is there anything else that we could do? Any other point to look at,
>>>>
>>> replace
>>>
>>>> class, packaging format, anything please. Tomorrow if we don't present at
>>>> least one servlet (we needed at least the GWT-RPC working but one servlet
>>>> should do it), we may have to drop osgi for good, and that's something we
>>>> are really not willing to do :(
>>>>
>>>> Regards
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> 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: ServiceTracker never gets called
Posted by Neil Bartlett <nj...@gmail.com>.
Hi Vinicius,
Glad to help, and thanks for your kind comments about my book.
However I think it's the authors of "OSGi in Action" who are asking
for a book review at the moment, since they have just released some
chapters for early access. They are on this mailing list so can
probably clarify. My book is "OSGi in Practice". Yes, these two titles
are confusingly similar... my defence is that I started writing my
book first!
Kind regards,
Neil
On Thu, Jan 29, 2009 at 4:45 PM, Vinicius Carvalho
<vi...@caravelatech.com> wrote:
> Bullseye! Thanks Neil. I've tested and got a ClassCastException ...
>
> We'll look into our code and check why is this happening. We've just tried,
> and in a debug breakpoint we've seen that the service returned by:
> HttpService httpService = (HttpService)
> context.getService(reference);
>
> Was indeed HttpServiceImpl, I guess we have a classloader problem. We have
> the equinox servletbridge inside webinf/lib, hence it's loaded by
> WebApplicationClassLoader. Since this bundle is loaded by ContextClassLoader
> that might be the problem, we don't know.
>
> I'll look into it. Thanks a lot for your help, it gave us hope again :)
>
> I owe you a book review (from your message at twitter.com). I've finished
> you book btw, best chapter is chapter 6 (concurrency is a subject that is
> not very well explained in most books, which is a shame since it lead to
> really annoying problems) Promise to write a few lines of revuew to you
> soon.
>
> Regards
>
>
> On Thu, Jan 29, 2009 at 11:57 AM, Neil Bartlett <nj...@gmail.com>wrote:
>
>> It's possible that the HttpService published in the service registry
>> is not compatible with your bundle that is trying to track it. This
>> could happen if you have multiple bundles exporting the
>> org.osgi.service.http package, or if your tracking bundle has somehow
>> included the org.osgi.service.http package instead of importing it.
>>
>> To check if this is the case, try changing the start() method of your
>> Activator to call httpServiceTracker.open(true) rather than just
>> httpServiceTracker.open(). This will force the tracker to find all
>> HttpServices, even the incompatible ones. Of course you will soon get
>> a ClassCastException when you try to use the returned service, so you
>> need to fix the underlying problem. Doing this will simply tell you if
>> that is indeed the problem.
>>
>> Regards,
>> Neil
>>
>> On Thu, Jan 29, 2009 at 1:48 PM, Vinicius Carvalho
>> <vi...@caravelatech.com> wrote:
>> > Hello all, sorry for always comming back on the same subject, but
>> tomorrow
>> > is our deadline, and even we got some progress on the osgi front with
>> spring
>> > (we now have services and dependency injection working). Nothing seems to
>> > work on the HttpService integration.
>> >
>> > We tried almost everything to get equinox running inside a servlet
>> > container. The documentation on equinox servlet bridge is almost
>> inexistent.
>> > We are not using their servletbridge since it starts the osgi container
>> and
>> > that is something we are doing in our code (following the sling approach)
>> >
>> > What seems to be happening is that any service tracker registered to
>> > HttpService never gets called, ever... We've seen this on the OsgiManager
>> > class, and now we decided to drop our own little servlet bundle:
>> >
>> > public class Activator implements BundleActivator {
>> > private ServiceTracker httpServiceTracker;
>> >
>> > public void start(BundleContext context) throws Exception {
>> > httpServiceTracker = new HttpServiceTracker(context);
>> > httpServiceTracker.open();
>> >
>> > }
>> >
>> > public void stop(BundleContext arg0) throws Exception {
>> > httpServiceTracker.close();
>> > httpServiceTracker = null;
>> > }
>> >
>> >
>> > private class HttpServiceTracker extends ServiceTracker {
>> >
>> > public HttpServiceTracker(BundleContext context) {
>> > super(context, HttpService.class.getName(), null);
>> > }
>> >
>> > public Object addingService(ServiceReference reference) {
>> > HttpService httpService = (HttpService)
>> > context.getService(reference);
>> > try {
>> > httpService.registerServlet("/dummy", new DummyServlet(),
>> > null, null); //$NON-NLS-1$
>> > } catch (Exception e) {
>> > e.printStackTrace();
>> > }
>> > return httpService;
>> > }
>> >
>> > public void removedService(ServiceReference reference, Object
>> > service) {
>> > HttpService httpService = (HttpService) service;
>> > httpService.unregister("/dummy"); //$NON-NLS-1$
>> > super.removedService(reference, service);
>> > }
>> > }
>> > }
>> >
>> > Well, the adding servlet never gets called :(
>> >
>> > Here how we start the felix container:
>> >
>> > public void init() throws ServletException {
>> > ServletContextResourceProvider rp = new
>> > ServletContextResourceProvider(getServletContext());
>> > Logger logger = new ServletContextLogger(getServletContext());
>> > Map<Object, Object> props = loadProperties();
>> > this.osl = new OSL(rp,props,logger);
>> > this.delegatee = new HttpServiceServlet();
>> > this.delegatee.init(getServletConfig());
>> >
>> > super.init();
>> > }
>> >
>> > public class OSL implements BundleActivator {
>> >
>> > private Felix felix;
>> > private ReadWriteLock felixLock;
>> > private ResourceProvider resourceProvider;
>> > private Logger logger;
>> > private BundleActivator httpServiceActivator;
>> >
>> > public OSL(ResourceProvider rp, Map<Object, Object> props, Logger
>> > logger){
>> > this.resourceProvider = rp;
>> > this.logger = logger;
>> > List<BundleActivator> activators = new
>> ArrayList<BundleActivator>();
>> > activators.add(this);
>> > activators.add(new BootstrapInstaller(logger,rp));
>> > props.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
>> activators);
>> > Felix tmpFelix = new Felix(props);
>> > try {
>> > tmpFelix.start();
>> > this.felix = tmpFelix;
>> > } catch (Exception e) {
>> > e.printStackTrace();
>> > }
>> > }
>> >
>> > public void start(BundleContext context) throws Exception {
>> > this.httpServiceActivator = new Activator();
>> > this.httpServiceActivator.start(context);
>> >
>> > }
>> >
>> > As you can see, we are starting the Httpservice ourselves, we tried to
>> not
>> > do so and pack it with the other bundles, but the effect is the same (do
>> not
>> > call the addingservice)
>> >
>> > After the complete startup we have these services:
>> >
>> > System Bundle (0) provides:
>> > ---------------------------
>> > org.osgi.service.startlevel.StartLevel
>> > org.osgi.service.packageadmin.PackageAdmin
>> > org.osgi.service.http.HttpService
>> >
>> >
>> > So I guess the HttpService is up and running.
>> >
>> > Is there anything else that we could do? Any other point to look at,
>> replace
>> > class, packaging format, anything please. Tomorrow if we don't present at
>> > least one servlet (we needed at least the GWT-RPC working but one servlet
>> > should do it), we may have to drop osgi for good, and that's something we
>> > are really not willing to do :(
>> >
>> > Regards
>> >
>>
>> ---------------------------------------------------------------------
>> 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: ServiceTracker never gets called
Posted by Vinicius Carvalho <vi...@caravelatech.com>.
Bullseye! Thanks Neil. I've tested and got a ClassCastException ...
We'll look into our code and check why is this happening. We've just tried,
and in a debug breakpoint we've seen that the service returned by:
HttpService httpService = (HttpService)
context.getService(reference);
Was indeed HttpServiceImpl, I guess we have a classloader problem. We have
the equinox servletbridge inside webinf/lib, hence it's loaded by
WebApplicationClassLoader. Since this bundle is loaded by ContextClassLoader
that might be the problem, we don't know.
I'll look into it. Thanks a lot for your help, it gave us hope again :)
I owe you a book review (from your message at twitter.com). I've finished
you book btw, best chapter is chapter 6 (concurrency is a subject that is
not very well explained in most books, which is a shame since it lead to
really annoying problems) Promise to write a few lines of revuew to you
soon.
Regards
On Thu, Jan 29, 2009 at 11:57 AM, Neil Bartlett <nj...@gmail.com>wrote:
> It's possible that the HttpService published in the service registry
> is not compatible with your bundle that is trying to track it. This
> could happen if you have multiple bundles exporting the
> org.osgi.service.http package, or if your tracking bundle has somehow
> included the org.osgi.service.http package instead of importing it.
>
> To check if this is the case, try changing the start() method of your
> Activator to call httpServiceTracker.open(true) rather than just
> httpServiceTracker.open(). This will force the tracker to find all
> HttpServices, even the incompatible ones. Of course you will soon get
> a ClassCastException when you try to use the returned service, so you
> need to fix the underlying problem. Doing this will simply tell you if
> that is indeed the problem.
>
> Regards,
> Neil
>
> On Thu, Jan 29, 2009 at 1:48 PM, Vinicius Carvalho
> <vi...@caravelatech.com> wrote:
> > Hello all, sorry for always comming back on the same subject, but
> tomorrow
> > is our deadline, and even we got some progress on the osgi front with
> spring
> > (we now have services and dependency injection working). Nothing seems to
> > work on the HttpService integration.
> >
> > We tried almost everything to get equinox running inside a servlet
> > container. The documentation on equinox servlet bridge is almost
> inexistent.
> > We are not using their servletbridge since it starts the osgi container
> and
> > that is something we are doing in our code (following the sling approach)
> >
> > What seems to be happening is that any service tracker registered to
> > HttpService never gets called, ever... We've seen this on the OsgiManager
> > class, and now we decided to drop our own little servlet bundle:
> >
> > public class Activator implements BundleActivator {
> > private ServiceTracker httpServiceTracker;
> >
> > public void start(BundleContext context) throws Exception {
> > httpServiceTracker = new HttpServiceTracker(context);
> > httpServiceTracker.open();
> >
> > }
> >
> > public void stop(BundleContext arg0) throws Exception {
> > httpServiceTracker.close();
> > httpServiceTracker = null;
> > }
> >
> >
> > private class HttpServiceTracker extends ServiceTracker {
> >
> > public HttpServiceTracker(BundleContext context) {
> > super(context, HttpService.class.getName(), null);
> > }
> >
> > public Object addingService(ServiceReference reference) {
> > HttpService httpService = (HttpService)
> > context.getService(reference);
> > try {
> > httpService.registerServlet("/dummy", new DummyServlet(),
> > null, null); //$NON-NLS-1$
> > } catch (Exception e) {
> > e.printStackTrace();
> > }
> > return httpService;
> > }
> >
> > public void removedService(ServiceReference reference, Object
> > service) {
> > HttpService httpService = (HttpService) service;
> > httpService.unregister("/dummy"); //$NON-NLS-1$
> > super.removedService(reference, service);
> > }
> > }
> > }
> >
> > Well, the adding servlet never gets called :(
> >
> > Here how we start the felix container:
> >
> > public void init() throws ServletException {
> > ServletContextResourceProvider rp = new
> > ServletContextResourceProvider(getServletContext());
> > Logger logger = new ServletContextLogger(getServletContext());
> > Map<Object, Object> props = loadProperties();
> > this.osl = new OSL(rp,props,logger);
> > this.delegatee = new HttpServiceServlet();
> > this.delegatee.init(getServletConfig());
> >
> > super.init();
> > }
> >
> > public class OSL implements BundleActivator {
> >
> > private Felix felix;
> > private ReadWriteLock felixLock;
> > private ResourceProvider resourceProvider;
> > private Logger logger;
> > private BundleActivator httpServiceActivator;
> >
> > public OSL(ResourceProvider rp, Map<Object, Object> props, Logger
> > logger){
> > this.resourceProvider = rp;
> > this.logger = logger;
> > List<BundleActivator> activators = new
> ArrayList<BundleActivator>();
> > activators.add(this);
> > activators.add(new BootstrapInstaller(logger,rp));
> > props.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
> activators);
> > Felix tmpFelix = new Felix(props);
> > try {
> > tmpFelix.start();
> > this.felix = tmpFelix;
> > } catch (Exception e) {
> > e.printStackTrace();
> > }
> > }
> >
> > public void start(BundleContext context) throws Exception {
> > this.httpServiceActivator = new Activator();
> > this.httpServiceActivator.start(context);
> >
> > }
> >
> > As you can see, we are starting the Httpservice ourselves, we tried to
> not
> > do so and pack it with the other bundles, but the effect is the same (do
> not
> > call the addingservice)
> >
> > After the complete startup we have these services:
> >
> > System Bundle (0) provides:
> > ---------------------------
> > org.osgi.service.startlevel.StartLevel
> > org.osgi.service.packageadmin.PackageAdmin
> > org.osgi.service.http.HttpService
> >
> >
> > So I guess the HttpService is up and running.
> >
> > Is there anything else that we could do? Any other point to look at,
> replace
> > class, packaging format, anything please. Tomorrow if we don't present at
> > least one servlet (we needed at least the GWT-RPC working but one servlet
> > should do it), we may have to drop osgi for good, and that's something we
> > are really not willing to do :(
> >
> > Regards
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: ServiceTracker never gets called
Posted by Neil Bartlett <nj...@gmail.com>.
It's possible that the HttpService published in the service registry
is not compatible with your bundle that is trying to track it. This
could happen if you have multiple bundles exporting the
org.osgi.service.http package, or if your tracking bundle has somehow
included the org.osgi.service.http package instead of importing it.
To check if this is the case, try changing the start() method of your
Activator to call httpServiceTracker.open(true) rather than just
httpServiceTracker.open(). This will force the tracker to find all
HttpServices, even the incompatible ones. Of course you will soon get
a ClassCastException when you try to use the returned service, so you
need to fix the underlying problem. Doing this will simply tell you if
that is indeed the problem.
Regards,
Neil
On Thu, Jan 29, 2009 at 1:48 PM, Vinicius Carvalho
<vi...@caravelatech.com> wrote:
> Hello all, sorry for always comming back on the same subject, but tomorrow
> is our deadline, and even we got some progress on the osgi front with spring
> (we now have services and dependency injection working). Nothing seems to
> work on the HttpService integration.
>
> We tried almost everything to get equinox running inside a servlet
> container. The documentation on equinox servlet bridge is almost inexistent.
> We are not using their servletbridge since it starts the osgi container and
> that is something we are doing in our code (following the sling approach)
>
> What seems to be happening is that any service tracker registered to
> HttpService never gets called, ever... We've seen this on the OsgiManager
> class, and now we decided to drop our own little servlet bundle:
>
> public class Activator implements BundleActivator {
> private ServiceTracker httpServiceTracker;
>
> public void start(BundleContext context) throws Exception {
> httpServiceTracker = new HttpServiceTracker(context);
> httpServiceTracker.open();
>
> }
>
> public void stop(BundleContext arg0) throws Exception {
> httpServiceTracker.close();
> httpServiceTracker = null;
> }
>
>
> private class HttpServiceTracker extends ServiceTracker {
>
> public HttpServiceTracker(BundleContext context) {
> super(context, HttpService.class.getName(), null);
> }
>
> public Object addingService(ServiceReference reference) {
> HttpService httpService = (HttpService)
> context.getService(reference);
> try {
> httpService.registerServlet("/dummy", new DummyServlet(),
> null, null); //$NON-NLS-1$
> } catch (Exception e) {
> e.printStackTrace();
> }
> return httpService;
> }
>
> public void removedService(ServiceReference reference, Object
> service) {
> HttpService httpService = (HttpService) service;
> httpService.unregister("/dummy"); //$NON-NLS-1$
> super.removedService(reference, service);
> }
> }
> }
>
> Well, the adding servlet never gets called :(
>
> Here how we start the felix container:
>
> public void init() throws ServletException {
> ServletContextResourceProvider rp = new
> ServletContextResourceProvider(getServletContext());
> Logger logger = new ServletContextLogger(getServletContext());
> Map<Object, Object> props = loadProperties();
> this.osl = new OSL(rp,props,logger);
> this.delegatee = new HttpServiceServlet();
> this.delegatee.init(getServletConfig());
>
> super.init();
> }
>
> public class OSL implements BundleActivator {
>
> private Felix felix;
> private ReadWriteLock felixLock;
> private ResourceProvider resourceProvider;
> private Logger logger;
> private BundleActivator httpServiceActivator;
>
> public OSL(ResourceProvider rp, Map<Object, Object> props, Logger
> logger){
> this.resourceProvider = rp;
> this.logger = logger;
> List<BundleActivator> activators = new ArrayList<BundleActivator>();
> activators.add(this);
> activators.add(new BootstrapInstaller(logger,rp));
> props.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, activators);
> Felix tmpFelix = new Felix(props);
> try {
> tmpFelix.start();
> this.felix = tmpFelix;
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
>
> public void start(BundleContext context) throws Exception {
> this.httpServiceActivator = new Activator();
> this.httpServiceActivator.start(context);
>
> }
>
> As you can see, we are starting the Httpservice ourselves, we tried to not
> do so and pack it with the other bundles, but the effect is the same (do not
> call the addingservice)
>
> After the complete startup we have these services:
>
> System Bundle (0) provides:
> ---------------------------
> org.osgi.service.startlevel.StartLevel
> org.osgi.service.packageadmin.PackageAdmin
> org.osgi.service.http.HttpService
>
>
> So I guess the HttpService is up and running.
>
> Is there anything else that we could do? Any other point to look at, replace
> class, packaging format, anything please. Tomorrow if we don't present at
> least one servlet (we needed at least the GWT-RPC working but one servlet
> should do it), we may have to drop osgi for good, and that's something we
> are really not willing to do :(
>
> Regards
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org