A very good way to get started with OSGi is services first. Start with PojoSR
and then move your code to services. Since PojoSR == OSGi - classloader
isolation it will not break your code and is completely unintrusive. Once
you're there, you can test the app, move something to a bundle with services,
test, repeat ad. hopefully not infinitum. Notice that bundles work, DS works,
Config Admin works, etc. Limits are no class loader isolation, so no dynamic
install/uninstall/update and side by side versioning. Start/stop, resource
loading, etc. all work.
Once the application is broken in bundles that way you can try to run it with
isolation. Since you do not need class loader hacks for the intermodule
communication (services fulfill that role) remaining problems should be
manageable.
That said, the greatest problem is that there are too few enterprise libraries
that are really modular, uncoupled, and highly cohesive. Many popular libraries
drag in the kitchen sink.
Kind regards,
Peter Kriens
On 29 mrt. 2013, at 16:56, Raymond Auge wrote:
> [This was going to be a response to the DS vs Blueprint thread.. but got too
> long]
>
> Re: DS vs Blueprint?
>
> What about complex concerns like providing aop on thousands of services?
>
> Speaking to David Bosschaert briefly about this at osgi con, he suggested two
> options, service interception (via service listener I believe) and/or
> asm/weaving/etc (David correct me if I'm wrong here).
>
> Which of DS or Blueprint lends itself better with these concerns?
>
> It would seem to me that DS lends itself better when development is on "new"
> components while Blueprint seems more "integrate-able" with already
> established, non-osgi, components.
>
> This brings me to my main topic and a comment I have after all the fantastic
> talks from the convention is that the vast majority of application of osgi
> (except of course for Graham's talk exploring the history of Websphere's
> evolution to osgi) seems focused on new development. Meanwhile it's evident
> that a key osgi value for many ( again demonstrated by both the websphere and
> eclipse cases) is in taking a complex system and migrating it to a modular
> architecture and osgi.
>
> I think this is where a lot of developers hit a wall. We can't just start
> from scratch. Secondly, by nature of having arrived at the osgi "conclusion",
> the issue was quite obviously that complexity already existed.
>
> At the OSGi BoF, it was asked "what could the osgi community do to help make
> it easier for new developers".
>
> It would be extremely valuable to have several demonstrations of taking some
> non-osgi application containing at least some degree of complexity and
> transforming that to an osgi-ified one with insight into the decisions and
> best practices.
>
> i.e. o(sgi)petstore is fine and dandy, there are plenty of those (Tim Ward
> demonstrated ~120) but what I really would benefit from is a jpetstore ->
> opetstore migration.
>
> In an effort to make some of that experience available to the general public,
> David also suggested that it would be great for Liferay to publish it's
> experience, and so I think I may do just that. The caveat being of course
> that as "new" osgi-ers we will likely show that we made some wrong decisions.
> However, I feel emboldened by Graham's admittance of IBM having made mistakes
> along the road. If IBM can do that, surely we can do that too.
>
> It was a great pleasure meeting many of you.
>
> Sincerely,
> Ray
> _______________________________________________
> 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
