Hi Peter,
I agree, we had some discussion with Christian where he wanted to set
all as bundle, whereas we have some pieces in Karaf where we just embed
as private package.
The challenge is to find the right balance between visibility, API,
granularity, etc.
Regards
JB
On 02/18/2014 07:27 PM, Peter Kriens wrote:
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'. :-)
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.
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.
Don't hesitate to contact me if you have an actual use case and want to discuss
it.
Kind regards,
Peter Kriens
On 18 feb. 2014, at 10:16, Christian Schneider <[email protected]> wrote:
I think you are right that the number of classes to wire inside a bundle is
much lower than the number of classes in a spring application. So there is less
need for a DI solution.
The question is though how to do the wiring with java in practice. Do you have
some larger examples for this? What I am especially concerned with is the
handling of instance creation and DI setup when classes are partly created by
hand and partly by DS.
Christian
On 17.02.2014 20:19, Peter Kriens wrote:
I do not think this is the idea of DS. Spring was invented to handle the
byzantine complexity of an average Java application at the time. Trying to wire
it all together had become a nightmare because there are ordering issues in
initialization. The complexity of apps exploded because the complexity
increases exponentially with the number of dependencies. So Spring provided a
fantastic solution to this problem. However, it also introduced XML programming
which is fundamentally bad (it is probably the worst language to code in ever
devised by mankind). In the early naughties this was ok since Spring solved a
real problem.
I think a natural DS application uses normal plain run of the mill Java code to
wire the private beans. Since these are normally a small number, there are in
general no ordering issues, specifically since the scope is private, no
unexpected surprises. Also the wiring is much better done in Java because it
gives you 100% type safety, error checking in the compiler, and lots of context
help in your IDE. Since the problem is so much smaller and all your types are
in private scope and you really want automatic wiring then there are lots of
solutions: Picocontainer, Guice, etc.
DS works so well because it is highly cohesive. It basically does one thing,
wiring services, and it does that extremely well. I would really think it would
be shame if we try to turn it into another bloated monster ... :-)
Kind regards,
Peter Kriens
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
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
