karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [DISCUSSION] Karaf Boot
Date Sun, 13 Sep 2015 20:25:00 GMT
I have already created two examples for enterprise projects on OSGi.
Both provide a UI, a service layer that implements a JPA based 
repository and a JPA based model.

This one is using CDI annotations and the maven-blueprint-plugin to 
create blueprint on the fly:
http://liquid-reality.de/display/liquid/2015/06/30/Apache+Karaf+Tutorial+part+10+-+Declarative+services
https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-blueprint-cdi


This one uses DS and the closure based JPA support:
http://liquid-reality.de/display/liquid/2015/03/05/Apache+Karaf+Tutorial+Part+9+-+Annotation+based+blueprint+and+JPA
https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds

I think in themselves the projects are already pretty simple. I do not 
see different annotations having a big impact on that.
Still these examples are nothing you could whip up from zero during a 
talk. What I would like to achieve is to have an environment where you 
can create such an application from an empty eclipse workspace during a 
typical talk duration live on stage.
This should include having a test and a near production ready deployment.

I am not sure how to get there but that is what we could discuss here. I 
know that Adam Bien is creating such applications based on JEE during 
his talks and I think this is pretty impressive.

Additionally I would like to add the requirement that the created 
application should show typical best practices that allow to scale up 
such a project to a real world project.
The motiviation for this is that many real life projects start like 
this. People see a cool technology on a conference and play with it at 
home. If it works smoothly they propose it at work. If it then scales up 
nicely to a real world prototype the decision is easy to go with it. I 
think that is the way to really make people switch to OSGi and karaf.

Christian

Am 13.09.2015 um 21:57 schrieb Milen Dyankov:
> 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" ;)
>
> Regards,
> Milen
>
>
>
> On Sun, Sep 13, 2015 at 7:51 PM, Christian Schneider 
> <chris@die-schneider.net <mailto: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
>
>
>
>
>
> -- 
> http://about.me/milen


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