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 <fmesc...@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 <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 <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
> >>>>> <vinic...@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 <
> njbartl...@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
> >>>>>>> <vinic...@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-unsubscr...@felix.apache.org
> >>>>>>> For additional commands, e-mail: users-h...@felix.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> >>>>> For additional commands, e-mail: users-h...@felix.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> >>>> For additional commands, e-mail: users-h...@felix.apache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> >> For additional commands, e-mail: users-h...@felix.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>
