I think these decisions are at the heart of what design is all about ...
Kind regards,
Peter Kriens
On 19 feb. 2014, at 08:45, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> 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 <ch...@die-schneider.net>
>> 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
>>> 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
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - 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
