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 <[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] > >
