karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: A Blueprint Free Karaf
Date Sat, 07 Dec 2013 07:18:43 GMT
You might want to educate yourself on DS before dismissing it.  

david jencks

On Dec 6, 2013, at 2:05 PM, Łukasz Dywicki <luke@code-house.org> wrote:

> Yes Joed,
> You got the point I wanted to reflect. DS and SCR is still dependency which, for sure,
may be optional. Switching to poorer replacement from feature rich blueprint will bring bigger
cost than moving to plain osgi. For me it will look like stopping in half of the way.
> Most of us knows well core spec plus something about blueprint. Very few from us knows
anything more about SCR, except the fact, that it's exists. This kind of change may decrese
number of maintaners to these who already know SCR. From drawbacks of another DI I may throw
that it requires, if I'm not wrong, additional bundle header which lists all components. Also
integration with maven bundle plugin seems missing. Ie for blueprint we get imports for free
and validation, because when this plugin fails to read XML prevents build from passing.
> 
> The idea of extender, shared earlier in this topic, which install necessary features
is very good. It might be used in similar way as deployers or feature resolvers to preprocess
bundles before installation to automatically enable certain features.
> 
> Łukasz Dywicki
> --
> Code-House
> http://code-house.org
> 
> Dnia 6 gru 2013 o godz. 21:12 Johan Edstrom <seijoed@gmail.com> napisał(a):
> 
>> I think Łukasz meant - use pure Java/OSGi, i.e no 
>> deps on SCR / DS at all?
>> 
>> 
>> On Dec 6, 2013, at 12:42 AM, Guillaume Nodet <gnodet@apache.org> wrote:
>> 
>>> 2013/12/5 Daniel Kulp <dkulp@apache.org>
>>> 
>>>> 
>>>> On Dec 5, 2013, at 11:03 AM, Achim Nierbeck <bcanhome@googlemail.com>
>>>> wrote:
>>>> 
>>>>> Hi Johan,
>>>>> 
>>>>> I'm fully with you for the client side I wouldn't walk that path for
a
>>>>> Karaf without Blueprint.
>>>>> I just have the feeling that especially for the minimal bundle it could
>>>> be
>>>>> really helpful to start without
>>>>> blueprint.
>>>>> @Dan regarding minimal and blueprint, yes though I think since we'd still
>>>>> provide the blueprint feature it would be viable way of doing minimal
>>>>> without blueprint but the user who still needs it
>>>>> needs to depend on that blueprint feature.
>>>> 
>>>> The issues is what to do about frameworks that need blueprint, but the
>>>> user may not.     The user may not even know that Blueprint is needed.
>>>> Their app may be completely spring-dm based or something.  However, if they
>>>> depend on CXF, they would also need blueprint or CXF won’t work (CXF uses
>>>> Blueprint in many places).   (Yes, changing CXF to use DS or something is
>>>> certainly a possible enhancement, anyone want to tackle that?)
>>>> 
>>>> Right now, there isn’t a “blueprint” feature that CXF can depend on.
  We
>>>> can add one for 3.1 or 4.0, but if CXF then depends on it, then it would
no
>>>> longer load into any 2.3.x Karaf without also doing a 2.3.x release.
>>>> That’s mostly my point, removing something that is there by default in
2.3
>>>> or 3.0 WILL have user impact.   It’s not a major one, but it is something
>>>> that needs to be considered on how to manage it, particularly for
>>>> frameworks that tend to try and keep a range of compatible Karaf versions
>>>> supported.
>>>> 
>>>> It could also be something like having a very small bundle listener or
>>>> bundle install hook or something in the core that when a bundle is loaded
>>>> (pre-resolve), if there is a "Bundle-Blueprint” manifest, it would
>>>> automatically start the blueprint feature.   Might have some timing quirks
>>>> that would need to be worked out, but possibly doable.
>>> Instead of using a bundle listener which would only be called after
>>> installation, it may be easier to just improve the FeaturesService
>>> implementation to automatically add those requirements at runtime.
>>> In short, we could easily rewrite the FeaturesServiceImpl#resolve(Feature)
>>> method and hack what we need there: look at bundles and if they have a
>>> blueprint header, add all the blueprint bundles.  This would be more robust
>>> than relying on a different bundle to kick in imho.
>>> In the same area, we could also get rid of the OBR resolver and build a new
>>> one using the real OSGi resolver, but that's a separate discussion I think.
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> Dan
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> regards, Achim
>>>>> 
>>>>> 
>>>>> 2013/12/5 Johan Edstrom <seijoed@gmail.com>
>>>>> 
>>>>>> Looking out there, I've seen one customer using DS in the last 3
years
>>>> or
>>>>>> so.
>>>>>> TX, JPA, Spring migrations, Spring only, BP only - sure.
>>>>>> Not to mention NS Handlers and so on.
>>>>>> 
>>>>>> It would make a "tiny" karaf viable, less deps and faster startup.
>>>>>> I doubt any developing user would (want to) be able to give up DI.
>>>>>> 
>>>>>> /je
>>>>>> 
>>>>>> On Dec 5, 2013, at 8:36 AM, Jean-Baptiste Onofré <jb@nanthrax.net>
>>>> wrote:
>>>>>> 
>>>>>>> You are right, but we should be careful about the side effects,
>>>> overlap,
>>>>>> etc ;)
>>>>>>> 
>>>>>>> On 12/05/2013 04:32 PM, Achim Nierbeck wrote:
>>>>>>>> As far as I understood the idea, it's
>>>>>>>> to use DS for Karaf itself, not to get rid of Blueprint.
>>>>>>>> Just so Karaf itself does have a smaller footprint.
>>>>>>>> @Ioannis did I get this right?
>>>>>>>> 
>>>>>>>> regards, Achim
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 2013/12/5 Jean-Baptiste Onofré <jb@nanthrax.net>
>>>>>>>> 
>>>>>>>>> Good point Dan.
>>>>>>>>> 
>>>>>>>>> I think you should not hurry about this.
>>>>>>>>> 
>>>>>>>>> Ioannis did a good PoC, but I quickly discussed with
him and his goal
>>>>>> is
>>>>>>>>> not to "force" the inclusion on Karaf 3.x.
>>>>>>>>> 
>>>>>>>>> I think it makes more sense (and it's wise ;)), to act
for a plan for
>>>>>>>>> Karaf 4.x.
>>>>>>>>> 
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 12/05/2013 04:26 PM, Daniel Kulp wrote:
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Dec 5, 2013, at 7:31 AM, Guillaume Nodet <gnodet@apache.org>
>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> I think that can be argued : it's a big internal
change, but not
>>>>>> really a
>>>>>>>>>>> user-facing one.  If the work is done in a compatible
way (which I
>>>>>> think
>>>>>>>>>>> is
>>>>>>>>>>> doable and should be the goal), it can be done
in a minor release,
>>>>>> as it
>>>>>>>>>>> would be almost transparent for the user: i.e.
a user should still
>>>> be
>>>>>>>>>>> able
>>>>>>>>>>> to deploy his own application without any changes.
 So I don't
>>>> think
>>>>>> it
>>>>>>>>>>> requires a major version change.
>>>>>>>>>> 
>>>>>>>>>> Well, there COULD be an impact….   Right now, some
of the
>>>> features.xml
>>>>>>>>>> files out there just assume blueprint is available.
  For example,
>>>>>> CXF’s
>>>>>>>>>> just assumes blueprint is there.   They don’t depend
on any
>>>>>> “blueprint”
>>>>>>>>>> feature.    Thus, an application (or CXF) that would
deploy fine on
>>>>>> the
>>>>>>>>>> minimal container out of the box right now would
not with 3.1 (or
>>>>>> whatever)
>>>>>>>>>> where blueprint isn’t there.
>>>>>>>>>> 
>>>>>>>>>> We COULD adjust for this by adding a “blueprint”
feature right now
>>>>>>>>>> (before 3.0 ships) that is relatively redundant with
the “framework”
>>>>>>>>>> feature (or have framework depend on the new blueprint)
that the
>>>> other
>>>>>>>>>> features.xml could start depending on.   That could
also be added
>>>> for
>>>>>> a
>>>>>>>>>> 2.3.x patch as well.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Dan
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 2013/12/5 Jamie G. <jamie.goodyear@gmail.com>
>>>>>>>>>>> 
>>>>>>>>>>> Just wanted to contribute my 2 cents -- I'd look
at a SCR Karaf for
>>>>>> 4.0
>>>>>>>>>>>> -
>>>>>>>>>>>> removing Blueprint dependencies from the
core is too major a
>>>> change
>>>>>> to
>>>>>>>>>>>> try
>>>>>>>>>>>> to introduce it to 2.3.x or 3.0 at this stage.
>>>>>>>>>>>> 
>>>>>>>>>>>> --Jamie
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, Dec 5, 2013 at 8:10 AM, Jean-Baptiste
Onofré <
>>>>>> jb@nanthrax.net
>>>>>>>>>>>> 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> I think we have to distinguish different
things:
>>>>>>>>>>>>> - the learn curve and usage "outside"
of Karaf for developers.
>>>> CDI
>>>>>> is
>>>>>>>>>>>> like
>>>>>>>>>>>> 
>>>>>>>>>>>>> EJB, and other framework.
>>>>>>>>>>>>> - the usage of CDI "inside" an OSGi application
or Karaf itself
>>>>>> (or for
>>>>>>>>>>>>> "native" OSGi applications).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The fact that Karaf now supports CDI
(via pax-cdi) is as good as
>>>>>>>>>>>>> supporting OpenEJB (in KarafEE), or Spring
(in Karaf "natively").
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I would not use OpenEJB in Karaf "itself",
nor Spring, nor CDI.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> If a developer wants to create a "generic"
application (that can
>>>>>> work
>>>>>>>>>>>>> in
>>>>>>>>>>>>> both OSGi or non-OSGi containers), CDI
is good.
>>>>>>>>>>>>> If a developer want to create a native
OSGi application, I would
>>>>>> use
>>>>>>>>>>>>> natively OSGi "specific" framework (like
blueprint).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> My 0.02€
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> JB
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 12/05/2013 12:06 PM, Christian Schneider
wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Probably you are right.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> The reason why I came up with CDI
is that it has the potential
>>>> to
>>>>>> be
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> core of user applications.
>>>>>>>>>>>>>> It is fully featured regarding web
and persistence if you
>>>> include
>>>>>>>>>>>>>> other
>>>>>>>>>>>>>> JavaEE stuff and also defines a standardized
extension
>>>> mechanism.
>>>>>>>>>>>>>> CDI is also well known to JavaEE
developers. So my point is/was
>>>>>> that
>>>>>>>>>>>>>> CDI
>>>>>>>>>>>>>> may be the only thing a developer
needs to learn regarding
>>>>>> dependency
>>>>>>>>>>>>>> injection.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On the other hand a programmer of
user applications running on
>>>>>> karaf
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> quite decoupled from the karaf services
and commands.
>>>>>>>>>>>>>> So it is probably not necessary that
he uses and understands the
>>>>>> karaf
>>>>>>>>>>>>>> internals. So from this perspective
minimum footprint counts
>>>> more
>>>>>> than
>>>>>>>>>>>>>> having only one framework. So from
this point of view DS really
>>>> is
>>>>>>>>>>>>>> better than CDI.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Another argument supporting this
is that while I see most
>>>>>> potential in
>>>>>>>>>>>>>> CDI to take over dependency injection
in user space it is far
>>>>>> from the
>>>>>>>>>>>>>> only solution. So there will always
be people who use something
>>>>>> else.
>>>>>>>>>>>>>> As
>>>>>>>>>>>>>> karaf needs to support a wide range
of frameworks this also
>>>>>> speaks for
>>>>>>>>>>>>>> minimum footprint for karaf's internals.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Christian
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 05.12.2013 11:49, Guillaume Nodet
wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 2013/12/5 Christian Schneider <chris@die-schneider.net>
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Good idea to look into alternatives
to blueprint.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> The big advantage I see for
DS is that it is very light
>>>> weight.
>>>>>> I am
>>>>>>>>>>>>>>> not
>>>>>>>>>>>> 
>>>>>>>>>>>>> so sure about its long term future though.
>>>>>>>>>>>>>>>> I personally think the future
of OSGi dependency injection is
>>>>>> CDI
>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>> pax-cdi + weld or openwebbeans.
>>>>>>>>>>>>>>>> Of course this is not really
near term and far from being a
>>>> sure
>>>>>>>>>>>>>>>> bet.
>>>>>>>>>>>>>>>> Still I think if we switch
the DI framework we should
>>>>>>>>>>>>>>>> also at least experiment
with CDI. I am currently working on a
>>>>>> karaf
>>>>>>>>>>>>>>>> tutorial for CDI. The service
injections already work very
>>>> well.
>>>>>>>>>>>>>>>> I am now looking into jpa
support.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I disagree.  CDI will have
the same problems as blueprint,
>>>> it's
>>>>>> an
>>>>>>>>>>>>>>> application level injection framework,
not focused *primarily*
>>>> on
>>>>>>>>>>>>>>> OSGi.
>>>>>>>>>>>>>>> The lifecycle of CDI beans has
to be static, so you have to use
>>>>>>>>>>>>>> proxies.
>>>>>>>>>>>> 
>>>>>>>>>>>>> Blueprint has the exact same problem
where the beans lifecycle
>>>> is
>>>>>>>>>>>>>>> bound to
>>>>>>>>>>>>>>> the lifecycle of the container.
   On the opposite, DS has a
>>>>>> better
>>>>>>>>>>>>>>> lifecycle mechanism for beans
which can naturally handle the
>>>> OSGi
>>>>>>>>>>>>>>> dynamism.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> And CDI would be even more heavyweight
than blueprint, so I'd
>>>>>> rather
>>>>>>>>>>>>>>> stick
>>>>>>>>>>>>>>> with blueprint than switching
to CDI, even if it were ready.
>>>>>>>>>>>>>>> The real benefit of DS is that
it has been designed to handle
>>>> the
>>>>>>>>>>>>>>> OSGi
>>>>>>>>>>>>>>> dynamism, so it does less, but
it does it better.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> In any case I think switching
the DI framework should be
>>>>>> considered
>>>>>>>>>>>>>> for
>>>>>>>>>>>> 
>>>>>>>>>>>>> karaf 4. So in this case we have a bit
of time to experiment.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Christian
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 04.12.2013 21:41, Ioannis
Canellos wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> For anyone curious on how
Karaf without Blueprint would look
>>>>>> like,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> here is a karaf branch
that is free of blueprint:
>>>>>>>>>>>>>>>>> https://github.com/iocanel/karaf/tree/karaf-light
(it's a
>>>>>> fork of
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>> 
>>>>>>>>>>>>> karat-2.3.x branch).
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> It is actually a refactored
karaf 2.3.x that removes
>>>> blueprint
>>>>>> from
>>>>>>>>>>>>>>>>> all modules (yet still
provides blueprint as feaures). Karaf
>>>>>>>>>>>>>>>>> specific
>>>>>>>>>>>>>>>>> blueprint namespace handlers
have moved to optional bundles
>>>> so
>>>>>> that
>>>>>>>>>>>>>>>>> they can still be used
if needed.
>>>>>>>>>>>>>>>>> Blueprint has been replaced
with Felix SCR (including the
>>>> shell
>>>>>>>>>>>>>>>>> commands). Moreover,
misc refactorings on features and
>>>> startup
>>>>>>>>>>>>>>>> bundles
>>>>>>>>>>>> 
>>>>>>>>>>>>> have been performed in order to reduce
the size and the amount of
>>>>>>>>>>>>>>>>> bundles in the minimal
distro.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> The result is a minimal
distribution that starts 12 bundles
>>>> [1]
>>>>>>>>>>>>>>>>> (out
>>>>>>>>>>>>>>>>> of 37 which were part
of karaf 2.3.3 minimal distro). 10 of
>>>>>> those
>>>>>>>>>>>>>>>>> bundle were blueprint
bundles and the rest are extra noise.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> My motivation behind
this refactoring was:
>>>>>>>>>>>>>>>>> i) I like declarative
services more than blueprint.
>>>>>>>>>>>>>>>>> ii) I've been working
on projects that are packaged inside
>>>> the
>>>>>>>>>>>>>>>>> karaf
>>>>>>>>>>>>>>>>> minimal distro which
would benefit from a smaller size (e.g.
>>>>>>>>>>>>>>>>> jclouds-cli).
>>>>>>>>>>>>>>>>> iii) I wanted to make
a karaf distro as flexible as possible.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Please note that my main
focus was the minimal distribution
>>>> and
>>>>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>>> this is not 100% polished.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Enjoy!
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> [1]: The bundle list
of the minimal distro:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>  ID   State         Level
 Name
>>>>>>>>>>>>>>>>> [   0] [Active     ]
[    0] System Bundle (4.0.3)
>>>>>>>>>>>>>>>>> [   1] [Active     ]
[    5] OPS4J Pax Url - mvn: (1.3.6)
>>>>>>>>>>>>>>>>> [   2] [Active     ]
[    5] OPS4J Pax Url - wrap: (1.3.6)
>>>>>>>>>>>>>>>>> [   3] [Active     ]
[    8] OPS4J Pax Logging - API (1.7.1)
>>>>>>>>>>>>>>>>> [   4] [Active     ]
[    8] OPS4J Pax Logging - Service
>>>>>> (1.7.1)
>>>>>>>>>>>>>>>>> [   5] [Active     ]
[   10] Apache Felix Configuration Admin
>>>>>>>>>>>>>>>>> Service
>>>>>>>>>>>>>>>>> (1.6.0)
>>>>>>>>>>>>>>>>> [   6] [Active     ]
[   11] Apache Felix File Install
>>>> (3.2.6)
>>>>>>>>>>>>>>>>> [   7] [Active     ]
[   13] Apache Felix Declarative
>>>> Services
>>>>>>>>>>>>>>>> (1.6.2)
>>>>>>>>>>>> 
>>>>>>>>>>>>> [   8] [Active     ] [   25] Apache Karaf
:: Shell :: Console
>>>>>>>>>>>>>>>>> (2.3.4.SNAPSHOT)
>>>>>>>>>>>>>>>>> [   9] [Active     ]
[   30] Apache Karaf :: Features :: Core
>>>>>>>>>>>>>>>>> (2.3.4.SNAPSHOT)
>>>>>>>>>>>>>>>>> [  10] [Active     ]
[   30] Apache Karaf :: Features ::
>>>>>> Command
>>>>>>>>>>>>>>>>> (2.3.4.SNAPSHOT)
>>>>>>>>>>>>>>>>> [  11] [Active     ]
[   30] Apache Karaf :: Shell :: Log
>>>>>> Commands
>>>>>>>>>>>>>>>>> (2.3.4.SNAPSHOT)
>>>>>>>>>>>>>>>>> [  12] [Active     ]
[   30] Apache Karaf :: Shell :: OSGi
>>>>>> Commands
>>>>>>>>>>>>>>>>> (2.3.4.SNAPSHOT)
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Christian Schneider
>>>>>>>>>>>>>>>> http://www.liquid-reality.de
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Open Source Architect
>>>>>>>>>>>>>>>> http://www.talend.com
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>> --
>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>> jbonofre@apache.org
>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>> Talend - http://www.talend.com
>>>>>>> 
>>>>>>> --
>>>>>>> Jean-Baptiste Onofré
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>>>> &
>>>>> Project Lead
>>>>> OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
>>>>> Commiter & Project Lead
>>>>> blog <http://notizblog.nierbeck.de/>
>>>> 
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>> 


Mime
View raw message