Hello, I'm involved in a project (software used by others, not in-house app) that uses Felix and Jetty. We chose the following approach:
- standalone java application that embeds felix (with an equivalent to "fileinstall" for handling "plugins") - a bundle defining an API (interfaces only) ; defines something similar to the servlet api, simplified to match use-cases ; no direct use or exposure of servlet api - a bundle containing Jetty, in embedded mode, visible only inside the bundle using Bundle-Classpath ; neither the servlet api nor the http osgi service are exposed ; dynamically maps implementations of our api to jetty We decided AGAINST : - embedding felix in a "classic" webapp, because (with particular concern for osgi framework classes) as many app servers now use and expose osgi, looked like a support nightmare if our embedded framework version conflicts with the app server's version - using the osgi http service, which tries to reuse the "standard" servlet api, but this seemed not to be a perfect fit (some classes using the servlet api would make assumptions about classes and environment that would be incorrect here) - having a fallback solution of using osgi fragments to bind to our bundle that embeds jetty if we're ever really stuck (needing to use something that expects the servlet api) ; have not hit this need yet Hope that's of some use in your considerations, Christopher On 27 June 2012 15:54, <[email protected]> wrote: > > > > > While I'm the one responsible for using embedded Felix in all Java-based > > Atlassian products, I would generally agree with my good friend Chad that it > > Hi Don! Interestingly, I've spend the last few months reworking a webapp > that hosts an embedded felix container. > > > is generally not advisable unless you have very specific extensibility > > requirements that could be serviced via OSGi. > > The main issue has to do with the different "levels" (classloaders) code > > runs > > in, so if you have lots of code back down in the web app, you have to be > > very > > careful how and where you expose that up to OSGi bundles. For example, if > > I've been re-architecting an app that embedded a felix container into an > existing web app. This came about because of a requirement for hot > deployment that arrived after the "host" app was already built and deployed > into the field. The classloader bit itself is tricky ( actually, though, > it's also a great case study deep diving on classloaders). The biggest > problem for me came out of the fact that a lot of classes were needed by both > the host app and the bundles that we're going to be installed into the > container. > > I found myself wishing I had time to re-implement the host app as an OSGi app. > > > Furthermore, many, if not most, web application libraries are built assuming > > the context classloader has full access to the whole webapp, which isn't the > > case in OSGi land where the CCL is actually undefined. > > For instance, Hibernate. > > > > --------------------------------------------------------------------- > 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]
