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
On 17 feb. 2014, at 10:55, Christian Schneider <[email protected]> wrote:
> I accidently exported all packages. I now changed the maven bundle plugin
> settings to not export any packages.
> Still I see no difference. So at least from the display side it can currently
> not distinguish between internal and public components.
>
> Would it make sense to define such a public / private property in DS and to
> set it either automatically or provide a way to configure it in the
> @Component annotation?
>
> I think with a lot of effort scr:list could also determine itself if a
> service is public by checking if the class or any interfaces it exports are
> public. Not sure if this would be a good idea though. I think I would prefer
> a property.
>
> Best regards
>
> Christian
>
>
> On 17.02.2014 10:32, Jean-Baptiste Onofré wrote:
>> Hi Christian,
>>
>> did you try to set the impl as private ?
>> I don't exactly remember what Karaf scr:list command does (I gonna check),
>> but it's maybe just a question of display.
>>
>> Regards
>> JB
>>
>> On 02/17/2014 10:10 AM, Christian Schneider wrote:
>>> This weekend I ported one of my examples from blueprint to declarative
>>> services.
>>> See https://github.com/cschneider/Karaf-Tutorial/tree/master/db/command2
>>>
>>> While it worked pretty well in general I have one concern with DS about
>>> public services vs internal component wiring.
>>>
>>> In my example I intended to export the components implementing Action to
>>> be exported as OSGi services as these have to be picked up by a karaf
>>> module. This worked fine of course.
>>> On the other hand I have some internal components like DbAccess and
>>> DbSelect that I simply wanted to wire into my public services but that
>>> should not be public.
>>> In blueprint I have a clear separation there. Only the beans I export
>>> with a service element are visible to the outside. For DS I have not
>>> found such a feature.
>>>
>>> How can I achieve the same hiding of internals in DS? I can imagine that
>>> I simply do not export the classes / interfaces that are internal. Still
>>> they will all appear in the list of components if I use the karaf
>>> command scr:list. Of course I want see the internal wirings sometimes
>>> but when I look at the whole OSGi framework I think it would be great to
>>> be able to only see the public components at first.
>>>
>>> Is this possible somehow?
>>>
>>> Christian
>>>
>>>
>>
>
>
> --
> 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
