Interesting observations about the command style. I had this discussion many
years ago with Guillaume when working on the corresponding RFC. The Gogo model
is more instance oriented, it uses a life object to provide the commands. The
idea was to make it really cheap and easy to add commands to your services. The
Karaf model is more based on the static class creation model, which always
suffers a bit how to find the proper context.
The Gogo model maps very well to DS, just add a property and the listed methods
are available as commands.
I really appreciate how you are going through this transition with an open mind
and share your reflections. Good work!
Kind regards,
Peter Kriens
On 18 feb. 2014, at 22:26, Christian Schneider <ch...@die-schneider.net> wrote:
> Am 18.02.2014 19:27, schrieb Peter Kriens:
>> My god, your mind must have been completely warped by Spring! :-) There have
>> been eons before Spring when you still had to wire your app with this old
>> fashioned out of style keyword call 'new'. :-)
> There is some truth in that. I started with Java about 2 years before spring
> was starting to become main stream. So when I worked on the first bigger
> project I quickly introduced spring there as it really solved a big problem
> at the time. I am not a big fan of spring now but such a history does in fact
> influence you.
>> Kidding aside, I actually do not recognize the problem. In general I just
>> create the private objects with 'new' and lazily. I.e. I do not go out of my
>> way to make them separate. One thing I learned about dependencies is that it
>> is all or nothing. You should not look at each dependency an-sich but look
>> what it means for the people that depend on you. Each class in your bundle
>> is fair game since you're already coupled. There is no use trying to protect
>> yourself from changes because you already in the same boat. So inside your
>> bundle you use the normal Java access rules for getting some local privacy.
>> And other than that, any external reference is a service.
>>
>> In my experience, I find I have quite a large number of components that have
>> a set of private adjoint classes. If I have a public API, I do not mind
>> talking to my siblings in the same bundle through the service registry since
>> quite often this turns out to be useful, if only for debugging. Realize that
>> a service is really cheap, there are installations with ten thousands of
>> services.
> Using the service registry for in bundle communication is indeed not really
> unnatural. But again there my mind is influenced by the restrictions of
> blueprint which does not allow such usage. So it takes time to get accustomed
> to this :-)
>>
>> The trick here is cohesion. Inside a service I normally have small to medium
>> sized program, using between a few to a 100 classes. I feel I've succeeded
>> when that complexity looks really simple through the service API, with only
>> a few adjoint classes. This is what modularity s all about, putting a lot of
>> complexity inside and only showing an API to allow collaboration.
> Very true. Most of the projects I see use bundles in a very fine grained way
> which introduces a lot of bloat and complexity when looking at them top down.
> One more reason by the way why we should have some nice examples in the open
> source space that show how good design could look like.
>> Don't hesitate to contact me if you have an actual use case and want to
>> discuss it.
> At the moment my main focus regarding DS is to prepare Apache Karaf for the
> switch from blueprint to DS. In karaf there will be no problem with the
> wiring regarding the number of classes involved. Each karaf bundle is
> relatively small and simple.
>
> In karaf the one big issue we have is that the Karaf Actions which help
> people to build commands are not very suitable for DS. For each command
> invocation a new instance of the action has to be created and populated.
> So we can not simply export the Action as a service and call it like a normal
> service. I experimented with a whiteboard pattern where a central module
> cares about this but it bends the service model a bit as Guillaume Nodet
> correctly stated in a karaf thread.
>
> Fortunately he pointed me to the felix gogo command style where one command
> is mapped to one method with parameters instead of one class with attributes
> in the karaf Action. So I am pretty positive that we can transition to the
> felix gogo commands if the karaf community agrees. These commands then work
> very well with DS. At the moment these new felix commands are not yet first
> class citizens in karaf as completion and help system do not work with them
> but I will work on that. So with that solved there should be no real blocker
> for the transition to DS.
>
> Best regards
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
