We are always open mind and we share a lot at Apache Karaf ;)
Regards
JB
On 02/19/2014 08:34 AM, Peter Kriens wrote:
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 <[email protected]> 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
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
