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 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 you have libraries you want exposed to OSGi bundles, you either have to maintain the package list yourself or do some fancy scanning (we do the latter), which can be very problematic in some app servers.
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. This is a general challenge with OSGi, and while not insurmountable, you'll definitely want to make sure you absolutely need the extensibility OSGi delivers. In our case, we needed a way to basically let people build applications on top of our apps, and OSGi is the only way to make that happen. Along the way, we've had a host of challenges, but in the end, we have hundreds of OSGi bundles (we call them plugins) in our Marketplace, many of which are paid enabling a whole ecosystem of small and large companies, so the pain we've go through, I think, has been worth it. However, for the average web app, I'd guess it wouldn't be. Don On Wed, Jun 27, 2012 at 3:57 AM, <[email protected]> wrote: > >> >> What are the disadvantages of using embedded Felix? I assumed that it >> would facilitate easier packaging and deployment, is that not true? > > I'm working with an app that embeds felix into a web app . . . not good for > various reasons. I would strongly dissuade you from doing so. Feel free to > ask if you need more info. > > > > > --------------------------------------------------------------------- > 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]
