On Wed, Nov 10, 2010 at 4:05 PM, Jeff McAffer <[email protected]> wrote: > >>> "Don't program to the OSGi api" !!! >> >> What do you mean by that? > > That is the first point I generally make in my OSGi Best Practices talks. > Basically it comes down to "use dependency injection". Whether that is DS, > blueprint, pico container, ... And it doesn't matter if you are injecting > "services", "extensions", "beans", .... In fact the point is that you don't > know or care what they are. The example we develop in the OSGi book > (http://equinoxosgi.org) ends up with 80 bundles and very few have ANY > reference to OSGi packages. This makes it easy to test, easier to write and > easier to reuse. > > Normal programmers should not be referencing OSGi API >
Ah of course, I always program like that. I am using DI all over and never touch the OSGi API in most projects. Thanks for clearing this up. >>> You can start with your "non-osgi" application, launching an embedding >>> osgi framework (see core spec) and aggregating the first parts into a >>> service/component approach, step by step. >> >> That was the plan. Put everything into one bundle and start up the >> application. If its still running and behaving like it did before start to >> carve out small parts into OSGi services. Like Peter suggested. > > I think Oliver's approach was somewhat different. If I got it right, he is > saying leave your non-OSGI thing and run a framework inside it. Carve out > parts of the app and have them run in that embedded framework. Basically eat > the monolithic wad from the inside out. > > Mixed opinions on my part. It may avoid/defer some classloading nastiness > but it may also artificially introduce some as you cross the OSGi/non-OSGi > boundary. My first inclination would be along Peter's lines of wrapping the > big chunks in bundles and refactor them. This has worked well for me and my > clients in the past. > > As for the native stuff, you don't have to use a fragment. Fragments are > useful if you want to ship for multiple platforms and don't want to ship all > platforms to everyone. Other than that, there is no particular value in > using them. Ok, so I will put really everything into one bundle and see if there are some classloader issues (lots of J2EE code). Thanks all for your input. I might come back here once I have started converting this beast. Regards, Phil _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
