Depends to what degree I am allowed to talk about the project in the public. But I already thought about sharing some of the experience in my blog. The first problem I have run into is that the current app uses main() as its entry point and from there on its chaining up methods and basically never returns. Somewhere in the code are System.exit hidden that have to be removed first I guess.
I will see what I can publish on the blog about the progress I am making. Regards, Phil On Thu, Nov 11, 2010 at 2:39 PM, Peter Kriens <[email protected]> wrote: > Why not start a blog and tell us your experiences? Would be nice to have a > trail for others to follow. I am pretty sure many readers would love to help > you out along the way. > > Kind regards, > > Peter Kriens > > > > On 10 nov 2010, at 17:20, Philipp Kursawe wrote: > >> 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 > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
