2011/9/27 Richard S. Hall <[email protected]> > On 9/27/11 11:54 AM, Teemu Kanstrén wrote: > >> OSGI solves some set of classloading issues if you need to run plenty of >> fullblown apps inside a single container. In other cases it just provides >> a >> big pile of additional classloader issues. In many cases it is even rather >> unclear to me why people wish to run many full apps inside a single >> container. >> > > This is not really true and was never the reason why I got into OSGi in the > first place. If you are building an application out of independently > developed third-party components, then you cannot control the precise > version of everyone's dependencies, thus you need a module system to do it > for you because you will likely end up with conflicts if you don't. > > True if you have that amount of complexity. A JEE container hosting separate apps fits that perfectly. Pack of self-made wizards less so. But sure, I have been where you point and without OSGI type of support it fails to work. Personally I try to avoid this but as there are not always options then you are correct this is needed.
> > In the case of customizing some wizards I would definitely not >> apply OSGI but just some basic interface design and plugin architecture. >> > > A plugin architecture is the perfect example of building a single > application out of third-party components. For example, you cannot control > which version of Apache Commons some arbitrary plugin uses, so if you load > two plugins that both need different versions, you'd be dead in the water > without something like OSGi. > > Of course, you are free to create something plugin mechanism that minimally > provides some of OSGi's isolation features, but this starts you down the > slippery slope of reinventing the wheel, because you'll eventually decide > you need shared library support, native library support, dynamism, etc. > > Quite true, what I was referring to was some way to "plug-in" a bunch of self-made wizards or something similar in a way one prefers. Of course, it might be the case that these wizards end up requiring large bunch of external jars each in which case you have a valid argument. Personally I did an application composing from a set of plugins using OSGI but realized I didn't really need all that since I was in control of all my plugins. > The real reason people run into so many issues when trying OSGi is because > they are either knowingly or unknowingly trying to use legacy code that > makes tons of assumptions about global type visibility. It has very little > to do with multiple versions being present at the same time. > Is it not the need to run legacy code in your container a large factor that leads to requiring classloader sandboxing? So does the solution address a problem that is likely to cause problems for the solution? :) But yes, I agree with you that this is the main source of issues in OSGI and if someone would solve that, there would be few reasons ever not to use OSGI.. Teemu
