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
