Community
Participate
Working Groups
When registering instances of org.eclipse.jetty.server.Server as an OSGi services, the org.eclipse.jetty.osgi.boot bundle must be active in order for the just registered server to get started. Otherwise teh startup of registered Severs is delayed until jetty.osgi.boot becomes active. I suggest to change the Bundle-ActivationPolicy manifest header of jetty.osgi.boot to "lazy". Calling code from jetty.osgi.boot would then activate the bundle and clients could force activation.
Hi Rüdiger, It used to be marked lazy but we were asked to not do that to ease the integration with virgo: bug 329571. The org.eclipse.jetty.osgi.boot.JettyBootstrapActivator has a private static method to lazily start the bundle if you were to call the static helper methods to register a webapp. Just curious: which class and method of org.eclipse.jetty.osgi.boot are you calling that would require the activation of the bundle? Maybe it would be worth it to activate the bundle lazily when those classe or methods are invoked? Other ideas welcome of course.
Rüdiger, I am getting more context for this bug out of the comments on bug 361110.
Rüdiger, a nice way I think to lazily activate the jetty.osgi.boot bundle is the OSGiAppProvider. We could add an optional attribute lazyActivateJettyOsgiBoot="true" to it. Then when this method is called on the OSGiAppProvider we would lazily the jetty.osgi.boot is started.
(In reply to comment #3) > Rüdiger, a nice way I think to lazily activate the jetty.osgi.boot bundle is the > OSGiAppProvider. > We could add an optional attribute lazyActivateJettyOsgiBoot="true" to it. > Then when this method is called on the OSGiAppProvider we would lazily the > jetty.osgi.boot is started. Hugues, from my POV such a method isn't necessary. Clients can start the bundle from their by doing something similar as the private method in JettyBootstrapActivator. I don't quite get what the point of bug 329571 is. Shouldn't web-bundles track when Server services are registered and then deploy the web app instead of waiting for the bundle to become active? Or am I on the wrong track?
In Virgo we use Jetty as an OSGi web container, we just start the Jetty OSGi bundle and expect it to start listening for Web app bundles to be deployed into OSGi. If the org.eclipse.jetty.osgi.boot bundle is lazy start then it won't be listening for bundle deployments. The OSGi web container spec requires no service or types to be used by Web Bundles, instead the extender pattern is used where the Web container just listens for Web Bundles being deployed in to OSGi. At no point do we load any of the classes provided by Jetty and we shouldn't either, we support other implementations of the OSGi Web Container spec (Gemini.Web etc...)so our web bundles don't care who is providing the web container and can't depend on implementation specific types. I've never come across the 'OSGiAppProvider', I'm guessing this is a case of conflict between the OSGi enterprise world and other OSGi specs.
Please note that there may now be some wiggle room in that Virgo 3.0.x switched to OSGi standard semantics for starting lazy activation bundles (see bug 346775). So if the Jetty team decide that they would like to make org.eclipse.jetty.osgi.boot lazily activated again, the Virgo team could test and confirm that this works with Virgo Jetty Server.
Thanks for the clarification (comment #5), that makes of course sense. Regarding comment #6, for me this is a minor issue. The affected code is a test helper and it isn't yet clear whether the whole approach is feasible (bug 361110). Currently I work around the issue by programmatically starting the bundle.
Rüdiger, I am going to close this as a won't fix. I'm guessing as this has been open so long, you're past the point of caring about this anyway - if not please reopen. regards Jan
