2009/1/30 Vinicius Carvalho <[email protected]> > 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 < > [email protected]> wrote: > > > > > > > On Thu, Jan 29, 2009 at 5:30 PM, Neil Bartlett <[email protected] > >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 <[email protected]> > >> wrote: > >> > 2009/1/30 Vinicius Carvalho <[email protected]> > >> > > >> >> 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 < > [email protected] > >> >> >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 < > >> [email protected] > >> >> >> >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 > >> >> >>>> <[email protected]> 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 < > >> >> [email protected] > >> >> >>>>> > >> >> >>>>> > >> >> >>>>>> 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 > >> >> >>>>>> <[email protected]> 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: [email protected] > >> >> >>>>>> For additional commands, e-mail: [email protected] > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>> > >> --------------------------------------------------------------------- > >> >> >>>> To unsubscribe, e-mail: [email protected] > >> >> >>>> For additional commands, e-mail: [email protected] > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>> > >> --------------------------------------------------------------------- > >> >> >>> To unsubscribe, e-mail: [email protected] > >> >> >>> For additional commands, e-mail: [email protected] > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >> > >> >> >> > >> >> >> > >> >> > > >> >> > > --------------------------------------------------------------------- > >> >> > To unsubscribe, e-mail: [email protected] > >> >> > For additional commands, e-mail: [email protected] > >> >> > > >> >> > > >> >> > >> > > >> > > >> > > >> > -- > >> > Cheers, Stuart > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > -- Cheers, Stuart
