On Wed, Jun 27, 2012 at 3:54 PM, <[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.
You could have used pojosr :-) regards, Karl >> 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] > -- Karl Pauls [email protected] http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
