karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milen Dyankov <milendyan...@gmail.com>
Subject Re: [DISCUSSION] Karaf Boot
Date Sun, 13 Sep 2015 19:57:20 GMT
Thanks for your examples Jean-Baptiste! I was tinning more about practical
business use cases, but let me comment on those.

First though a little disclaimer. Even though I'm familiar with how
Blueprint works in general, I have not used it for anything serious. For me
it has always been too Spring'ish and the amount of "magic" it uses is a
little bit too much. I moved from iPojo to DS and this is what I have been
using for the last couple of years. So I would leave aside the native OSGi
(I fully agree with Christian on that one) and Blueprint (I don't feel I'm
in a position to comment in a prejudice free way).

Now about the examples.  I don't think I need to comment on the first one
at all. Assuming you are right in your estimations I don't think 5% is
worth learning yet another approach. Especially one that tries to hide from
you how things actually work. And as the project grows I think those 5%
will quickly go down to 0 (if not in the negative range) because one can
hardly do anything serious in OSGi without good understanding of how
service registry (including filters, ratings, patterns, configadmin, ...)
works .

As for the second example - I think there is a huge difference between
remote services (REST, SOAP, ...) and persistence / transactions and we
should not consider those equal to automate / simplify. Remote services are
straightforward. You request a resource, something builds it for you (how,
is totally out of scope for the use case) and sends it back to you in the
form requested. This is very very easy to automate. In fact in one of my
demos (which btw I will present at ApacheCon) I do exactly that. It's
bundle with a single class using standard JAX-RS annotations. I don't see
how can you make it any easier than that.

JPA and JTA is a whole different story. It is complex. Not because of the
standard, framework or the implementation but because of the domain it
operates on. Developer need to know the model, relationships, constraints,
isolation levels, limitation of the underlying storage, ... thousands of
things. Honestly speaking I don't see
@jpa(provider="openjpa",dataSource="my") useful for anything but a very
simple use case (tempted to write a "hello world" equivalent). I still
remember the CMP EJB that was supposed to make this so simple and how it
died naturally because simple equals limited. Then Hibernate made ORM
useful. But let's be honest here, it was far from simple. And still people
were moving from EJB to Hibernete to get the job done. We (the Java
community) have walked a long way to bring ORM to what it is today and it's
still far from simple. That is because the problem it targets is complex
and flexibility is far more important for any real use case.

With all the respect, I don't believe a few high level annotations will
make anyone switch to Karaf for some serious projects. For personal
projects and initial attraction - may be. But if you want to introduce this
as a technology to be used in a real project - "it's easy" is not enough
argument  to convince your senior architects. In fact I would argue that if
the SpringBoot didn't have the word "Spring" in it (and all the trust and
marketing that goes with that) it could have existed for a number of years
and none of us would have heard about it.

On the other hand in the OSGi landscape we already have a bunch of projects
which goal is to make it easier for Java EE folks to move to OSGi world.
But even they have realized you can't completely ignore and hide OSGi. You
are probably familiar with Amdatu's projects. I must admit I find their web
services and DOSGi approach a lot easier than CXF. Also more flexible. But
it's not only that. Out of curiosity, I just had a look at Pax CDI and
surprise surprise there is a @OsgiService annotation there. There is also
an explanation of requirements and capabilities which one need to
understand. Sure those can be generated for you by the build tool and you
can completely ignore @OsgiService annotation and only wire your beans. But
in such case my question would be: why are you using OSGi ? There is also
bnd and bndtools that in many cases simplify development a lot (and you can
use them with ant, maven, gradle, whatever the build system of tomorrow
will be).

My point is, I wish we (OSGi community) were more united and more
collaborating. I think there is too much internal competition in the space
and efforts are focused in promoting particular projects (often by
attempting to compete with a well established JEE product) and not so much
the technology itself. I think OSGi (as of release 6) is simple enough. I
think there are plenty (IMHO too many) of choices for developing OSGi
applications to choose from to be as close as possible to what you already
know. I think it will never be the case that someone would develop
something serious with OSGi without investing in knowing how it works! I
think what is hard is hard because it has to be hard. When it is "hard" it
make you think about why you are doing what you are doing. Ultimately this
results in better design and solid architecture.

That is not to say there is nothing to improve. But I'm more on Christian's
side here. I would look around to see how to improve what is already there.
Whether that is CDI (really? people want that?) or (better) integrating
with bnd/bndtools or something else.  To quote Einstein "make as simple as
possible but not simpler" ;)


On Sun, Sep 13, 2015 at 7:51 PM, Christian Schneider <
chris@die-schneider.net> wrote:

> The CDI and JEE annotations are exactly taylored to the enterprise use
> cases. I doubt that we can create better ones.
> Abstracting away from the technology can only mean you introduce another
> layer of indirection. This can only make sense if the underlying technology
> is crappy which I think is not the case.
> I am looking forward to see what you propose but I think reinventing the
> whole set of annotations will probably not be the way to go. We saw this
> path in the karaf 4 commands and I think the result is not good.
> Instead I propose we look at the annotations and examples you provide and
> think how they could be implemented with existing standards + a minimal set
> of additional
> annotations that fit well into an existing technology.
> Christian
> Am 13.09.2015 um 19:13 schrieb Jean-Baptiste Onofré:
>> Hi Christian,
>> Workload is one thing, multi-dependencies/pom/etc is something.
>> In the annotations, even if the workload is the same, it's the kind of
>> annotations. The purpose is to provide more high level, use case centric
>> annotations, more than low level technical one.
>> I agree that we could extend the maven-blueprint-plugin, but I would
>> prefer to keep it more high level and decoupled from the underlying
>> technology involved.
>> karaf-boot purpose is to be straight forward and avoid the "big mess &
>> soup about what should I use, what the version, etc".
>> I'm still convince that at least a BoM provided by karaf-boot is
>> interesting.
>> I'm also still think that an abstract Karaf oriented is valid.
>> Regards
>> JB


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message