Thx for all the answers and pointers. No more questions currently, have
to investigate a bit further, maybe just some input:
1. I did not notice the documentation is already in asciidoc. The single
page flavor of it could potentially be nice to have (like
http://www.crnk.io/documentation/).
2. "as it is pretty tightly bound to OWB." & "but a highly integrated
asf stack". It would be nice to see that EE4J or microprofile align a
bit in this direction. Standardizing the API from Meecroware and make it
accessible to all the vendors as one possibility. Spring Boot and
Dropwizard let the way in the area and are successful. And with Jigsaw
Java 9 moves in this direction as well. As you mentioned that seems
currently unlikely. Maybe one of the vendors opening up a bit could be a
start... :-) Or start to facilitate these manual approaches like Hammock
a bit more by splitting up the JTA spec and implementations (I barely
see anybody making use of the distributed features), avoiding
dependencies to APIs like JNDI or having a configuration/health/metrics
spec in place.
I will look at bit more into hammock and MB. But e.g. the depenency to
Hibernate for our applications is high. So flexibility is one of the
important things for us.
Regards Remo
Am 02.10.2017 um 09:26 schrieb Mark Struberg:
To answer a few questions:
Meecrowave will likely remain an OWB subproject as it is pretty tightly bound
to OWB.
As Thomas already explained: if you stick to the CDI spec then both should give
you the same features.
And yes, OWB still performs 2..3x better than Weld and is also much smaller.
Used to be 50..200x compared to former Weld versions.
If you want to use a Server which is portable between Weld and OWB then you
might enjoy looking at John Aments Hammock project.
Different goals, different pros and cons coming with it of course.
Do we plan to incorporate MP parts out of the box?
Hmm not sure myself to be honest as all this can easily added by just adding a
dependency. And that way you are totally flexible regarding versioning.
We might change is in the future probably, but for now it doesn't look that
way. Note that I'm saying this despite I'm one of the Microprofile spec authors
and I really like MP.
But it's really so easy to add that it doesn't put any burden to the user but
adds flexibility to _not_ have it by default.
Otoh add a few samples an also add some ITs in the future might be a good idea!
Oh and thanks for your question!
Just ping us if you have any question comint to your mind.
txs and LieGrue,
strub
Am 01.10.2017 um 22:22 schrieb Thomas Andraschko <[email protected]>:
Some additions about Weld <> OWB:
Please also note that there are almost no reasons that application code must
depend on Weld or OWB. The behavior of both implementations are almost
identical.
In the past OWB had (much) better performance, mem size and disk size. Not sure
how much is the difference today.
IMO there is no reason that you should stick to a specific CDI impl, nor that
we should support Weld.
2017-10-01 19:56 GMT+02:00 Romain Manni-Bucau <[email protected]>:
Hi Remo,
Le 1 oct. 2017 18:56, "Remo Meier" <[email protected]> a écrit :
Hi
I would have a number of questions and feedback about Meecrowave. I may also be
able to contribute a few things.
1. Is there any alignment planned with EE4J or micro-profile? In contrast to
other approaches like Wildfly Swarm, Meecrowave for sure is a big step in the
right direction for JEE IMHO.
No but since MP is just a set of cdi extensions no blocker to use it. FYI it is
done at geronimo project.
Same applies for JavaEE or EE4J. In particular since one goal of Meecrowave was
to keep only good things of EE we will probably not grow too much.
Anything special you are thinking about?
2. Will it stay a openwebbeans thing? Or are you also interested in contributions
from other JEE vendors? My company is married to Weld & Hibernate for example,
but likes Deltaspike, Tomcat and CXF from the Apache side. With CDI and Jigsaw I
would expect something like this to work in the future with JEE.
Not sure I get it, it will stay an OWB subproject which doesnt prevent
contributions - we already got some ;).
3. Asciidoc for documentation would be great.
It is the case, see doc module.
4. I'm not so familiar with the Apache guidelines regarding collaboration. But
Git, Github presence, Travis, Sonar, Gitter or similar would be great to have.
We are on github, we can have a sonar at asf - dont wait for me for that since
i have only bad experiences with it ;), no blocker for travis AFAIK.
5. In terms of missing features and contributions, for example JSR 352 Batch
(like jberet), Weld, metrics, health checks, configuration API, Hibernate and
opinionated Gradle plugins to create RPMs (with systemd integration) and docker
would be great to have.
Batchee works OOTB with meecrowave - for jbatch, weld will not be integrated
since we dont aim to be portable between spec vendors but a highly integrated
asf stack, others parts are already covered elsewhere with cdi extensions or
build tools (even if here we intentionally integrate more with mvn).
For the config deltaspike or geronimo config are good fit, sirona for the
monitoring works well - or metrics-cdi if you prefer, hibernate works well with
deltaspike or jpa meecrowave extension.
Regards Remo
.
