You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rémy Maucherat <re...@apache.org> on 2019/06/11 14:57:26 UTC
Re: CDI support improvements
On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Once done it can be hosted on both side.Owb has the advantage to be know
> by users, tomcat to be a more natural home for an integration. At the end
> it is mainly synchronizing both projects for a consistent communication and
> code "move" IMHO.
>
> For deep tomcat/cxf integration, you can use
> http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core
> module. Technically it uses an embedded flavor but it would be easy to move
> to a standalone one through a listener based on a small refactoring in
> Meecrowave#start. The good part are the lifecycle and scanning integrations
> + the tooling to make testing and dev simple -
> http://openwebbeans.apache.org/meecrowave/.
>
Ok, I think things look reasonably good using CDI extensions (looking at
the Geronimo mp implementation you did) except the default CXF "servlet"
integration. I think right now the "servlet" integration from the
cxf-rt-transports-http package is "bad" and that the one from Meecrowave
(in org.apache.meecrowave.cxf) is more likely to be the way to go (it
derives from cxf-integration-cdi).
So this looks a lot closer to Meecrowave than I originally expected, with a
lot of "buts" though:
- Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal here
is a "Meecrowave for Tomcat"
- The JAR has all of Tomcat, log4j, API JARs, etc, while it should here be
based off Tomcat, the javax APIs and OWB already present in the Tomcat OWB
implementation JAR (the classic "tomcat7" or the modernized "tomcat-owb")
- log4j would need to be removed as well
- plenty of configuration files and options in the JARs, but I guess that's
the way it is since all the subcomponents are so flexible
>
>
>>> More technically: openwebbeans does not need properties files you can
>>> pass Properties when you create the WebBeansContext, this is what tomee
>>> does. Same for cxf and its bus ;).
>>>
>>
>> Ok, I'll have a look at that, it's better than properties files (but
>> similar).
>>
>
>>> Biggest short term challenge is to align scanners but it is very doable,
>>> long term it is to drop big core jars in all 3 libs for smaller bundles ;).
>>>
>>
>> Ok.
>>
>>>
>>> Feel free to shout if you need help or more precise pointers.
>>>
>>
Rémy
Re: CDI support improvements
Posted by David Blevins <da...@gmail.com>.
> On Jun 11, 2019, at 12:02 PM, Mark Thomas <ma...@apache.org> wrote:
>
> On 11/06/2019 19:37, David Blevins wrote:
>>
>> At a high level, is there a desire to start supporting more "EE" like specs such as CDI, JAX-RS, JPA, etc?
>
> Make it easier to integrate? Sure.
>
> Implement additional specs? No.
That's been my understanding as well.
> On Jun 11, 2019, at 12:21 PM, Rémy Maucherat <re...@apache.org> wrote:
>
> Ok, so the plan (my plan, actually) here is that I noticed CDI (and JAX-RS) is the building block of many other APIs (like the Microprofile), so there's a need to be able to use it in a "clean and light [and] in Tomcat spirit" way (as you said). I had a look at OWB and CXF and while the support is there, it needs some work (especially for the latter) and is certainly not user friendly (again, esp for the latter). Note that the work is also in Tomcat itself, since I'm in a good position to make changes and improvements as needed.
>
> As for the answer, it would still be "no" at this point, since at most these could be considered as a couple extra optional modules like the jdbc pool, or maybe "build them yourself" poms.
If CDI integration code were to live here, I'd probably want to see us rebase TomEE on top of it. That would probably mean occasional CDI-related PRs, documentation, dev threads, user questions, etc. It's a bit of a can of worms even if it's an add-on, which is why I ask the above.
In the event people here prefer not to open that can of worms of supporting Tomcat+CDI integration code, it and you would be more than welcome in TomEE. We could have a "Tomcat+CDI" dist of TomEE that used just the new code. As noted above, we'd probably rebase the other TomEE dists on that one. It's been 8 years and I definitely have appetite for a fresh perspective (just like you, speaking for myself only not all of TomEE).
I'm a fan wherever it lives. My concern would be if it happens here and isn't actually welcome. I would feel very awkward sending people over to help maintain it.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: CDI support improvements
Posted by Mark Thomas <ma...@apache.org>.
On 11/06/2019 19:37, David Blevins wrote:
> Hi All,
>
> At a high level, is there a desire to start supporting more "EE" like specs such as CDI, JAX-RS, JPA, etc?
>
> Completely understood if the answer is "depends." I suspect it would depend on if the code is clean and light in Tomcat spirit.
>
> I write this not from the perspective of "let's move a bunch of TomEE code into Tomcat", but more of "let's write cleaner newer code in Tomcat and retire equivalent TomEE code."
>
> That's not a specific proposal, just curious if appetite has developed in recent years to entertain tip-toeing beyond the same set of specs.
Make it easier to integrate? Sure.
Implement additional specs? No.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: CDI support improvements
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Jun 13, 2019 at 6:52 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
>
> https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1412
> is likely the one but looks like johnzon was not scanned nor registered
> programmatically
>
> Maybe code this bean:
>
> @Produces("application/json") // jaxrs import
> @Provider //jaxrs import
> @Dependent // cdi import
> public class MyJson<T> extends JsonbJaxrsProvider<T> {}
>
> Should be enough if it is the issue (or use delegation instead of
> inheritance)
>
Thanks for the debug method, it worked very well :) So there's now a lot of
possible improvements I can look at.
Rémy
Re: CDI support improvements
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le lun. 17 juin 2019 à 16:17, Rémy Maucherat <re...@apache.org> a écrit :
> On Mon, Jun 17, 2019 at 10:52 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Hi Rémy,
>>
>> Great progression! Congrats!
>>
>> I have a few (details) notes - guess i'm opening an open door but just to
>> ensure:
>>
>> 1. Is it intended to bind cxf to /rest/* in any case? I tend to see it
>> bound on on /api but generally thanks to an Application
>> (+ @ApplicationPath("api")) so cxf is bound on /*. Wonder if the listener
>> shouldn't host that config and we would link it through a context listener
>> or servletcontextinitializer (both will work and rely on tomcat internals)
>>
>
> I am not comfortable mapping a servlet on /* by default, it would be
> annoying, so I changed the mapping to /api/*. I used a web-fragment for now
> since it's a decent Servlet API feature and has plenty of configuration
> flexibility.
> Adding additional CXF integration would be good but is work, a filter
> could useful. Moving CXF to a container integration is even more work and
> doesn't looks that practical to me.
>
> The CDI context listener configuring CXF if is present sounds possible (it
> can programmatically add the CDI CXF servlet, no problem), it does sound a
> bit weird conceptually but it's a good option.
>
>
>> 2. In beans.xml, rather than annotated mode - which skips a lot of
>> classes which can be used in CDI - we tend to prefer discovery mode
>> "full" + trim:
>> https://github.com/apache/geronimo-health/blob/master/geronimo-health/src/main/resources/META-INF/beans.xml
>>
>
> I don't understand how that works, if I add scanning to tomcat-cxf.jar, it
> loads all classes (which fails). So that's why I'm not doing it.
>
If you can detail that, I can surely help.
If you can change the code, adding @Vetoed on classes you don't want to be
CDI beans can help too.
The annotated mode - default in cxf - was here to "work out of the box",
however the defaults were not that great and it is easy to fall in a case
where "it should work". All mode is more reliable and aligned on the "old"
(1.0) scanning where all beans are here, the <trim/> addition was there to
drop the useless types and ensure the deployment stays "light".
So long story short, full+trim is likely the less error prone and
priviledged mode today.
>
>
>> 3. Why not merging SPI files thanks to maven? (shade part, end of
>> http://openwebbeans.apache.org/meecrowave/meecrowave-maven/index.html)
>> 4. You have a spring config (cxf.xml), not sure it is intended?
>> 5. jettison is not needed since it is not the one used for json
>> serialization (guess you can drop several cxf deps)
>>
>
> Very good idea, I made changes and fixed these items.
>
👍
BTW, is the assembly available?
>
> Rémy
>
>
Re: CDI support improvements
Posted by Rémy Maucherat <re...@apache.org>.
On Mon, Jun 17, 2019 at 10:52 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi Rémy,
>
> Great progression! Congrats!
>
> I have a few (details) notes - guess i'm opening an open door but just to
> ensure:
>
> 1. Is it intended to bind cxf to /rest/* in any case? I tend to see it
> bound on on /api but generally thanks to an Application
> (+ @ApplicationPath("api")) so cxf is bound on /*. Wonder if the listener
> shouldn't host that config and we would link it through a context listener
> or servletcontextinitializer (both will work and rely on tomcat internals)
>
I am not comfortable mapping a servlet on /* by default, it would be
annoying, so I changed the mapping to /api/*. I used a web-fragment for now
since it's a decent Servlet API feature and has plenty of configuration
flexibility.
Adding additional CXF integration would be good but is work, a filter could
useful. Moving CXF to a container integration is even more work and doesn't
looks that practical to me.
The CDI context listener configuring CXF if is present sounds possible (it
can programmatically add the CDI CXF servlet, no problem), it does sound a
bit weird conceptually but it's a good option.
> 2. In beans.xml, rather than annotated mode - which skips a lot of classes
> which can be used in CDI - we tend to prefer discovery mode "full" + trim:
> https://github.com/apache/geronimo-health/blob/master/geronimo-health/src/main/resources/META-INF/beans.xml
>
I don't understand how that works, if I add scanning to tomcat-cxf.jar, it
loads all classes (which fails). So that's why I'm not doing it.
> 3. Why not merging SPI files thanks to maven? (shade part, end of
> http://openwebbeans.apache.org/meecrowave/meecrowave-maven/index.html)
> 4. You have a spring config (cxf.xml), not sure it is intended?
> 5. jettison is not needed since it is not the one used for json
> serialization (guess you can drop several cxf deps)
>
Very good idea, I made changes and fixed these items.
Rémy
Re: CDI support improvements
Posted by Romain Manni-Bucau <rm...@gmail.com>.
PS/FYI: just noticed jetty did the same kind of work with weld 4 years ago:
https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-cdi/cdi-servlet/src/main/config/etc/jetty-cdi.xml,
great Tomcat is catching up :).
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 17 juin 2019 à 10:52, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
> Hi Rémy,
>
> Great progression! Congrats!
>
> I have a few (details) notes - guess i'm opening an open door but just to
> ensure:
>
> 1. Is it intended to bind cxf to /rest/* in any case? I tend to see it
> bound on on /api but generally thanks to an Application
> (+ @ApplicationPath("api")) so cxf is bound on /*. Wonder if the listener
> shouldn't host that config and we would link it through a context listener
> or servletcontextinitializer (both will work and rely on tomcat internals)
> 2. In beans.xml, rather than annotated mode - which skips a lot of classes
> which can be used in CDI - we tend to prefer discovery mode "full" + trim:
> https://github.com/apache/geronimo-health/blob/master/geronimo-health/src/main/resources/META-INF/beans.xml
> 3. Why not merging SPI files thanks to maven? (shade part, end of
> http://openwebbeans.apache.org/meecrowave/meecrowave-maven/index.html)
> 4. You have a spring config (cxf.xml), not sure it is intended?
> 5. jettison is not needed since it is not the one used for json
> serialization (guess you can drop several cxf deps)
>
> Hope it makes sense.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le lun. 17 juin 2019 à 10:29, Rémy Maucherat <re...@apache.org> a écrit :
>
>> Hi Romain,
>>
>> On Thu, Jun 13, 2019 at 6:52 PM Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>
>>>
>>> https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1412
>>> is likely the one but looks like johnzon was not scanned nor registered
>>> programmatically
>>>
>>> Maybe code this bean:
>>>
>>> @Produces("application/json") // jaxrs import
>>> @Provider //jaxrs import
>>> @Dependent // cdi import
>>> public class MyJson<T> extends JsonbJaxrsProvider<T> {}
>>>
>>> Should be enough if it is the issue (or use delegation instead of
>>> inheritance)
>>>
>>
>> Thanks for your help, I was able to make cxf work for me, and then
>> package it in a less error prone way (
>> https://github.com/rmaucher/tomcat-cxf ).
>> It does the following:
>> - Use a bean to add the json provider
>> - Package the necessary dependencies for json, jax-rs and cdi
>> - Bundle the web-fragment for the cxf cdi servlet (I wasted quite a lot
>> of time by using the regular cxf servlet, ultimately noticing that the
>> trace wasn't using cdi)
>> tomcat-owb should then be placed in lib, add the Server listener. It will
>> CDI enable all webapps (if they use the support). CXF then uses that
>> support. Due to its intricacies (and also the fact that it's not
>> lightweight), I don't think CXF is a good choice to put in the main Tomcat
>> lib folder (and at the moment, it won't work out of the box in that case).
>>
>> I tested with a health bean from the "tck":
>> @Health
>> @ApplicationScoped
>> public class SuccessfulHealth implements HealthCheck {
>> @Override
>> public HealthCheckResponse call() {
>> return HealthCheckResponse.named("successful-check").up().build();
>> }
>> }
>> With the addition of the geronimo-health (which is a CDI extension),
>> geronimo-health-common, microprofile-health-api-1.0, and the fat jar
>> tomcat-cxf to /WEB-INF/lib, the bean is processed and runs (on
>> /rest/health). I expect the other mp APIs like metrics to work in a similar
>> way.
>>
>> Rémy
>>
>>
Re: CDI support improvements
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Rémy,
Great progression! Congrats!
I have a few (details) notes - guess i'm opening an open door but just to
ensure:
1. Is it intended to bind cxf to /rest/* in any case? I tend to see it
bound on on /api but generally thanks to an Application
(+ @ApplicationPath("api")) so cxf is bound on /*. Wonder if the listener
shouldn't host that config and we would link it through a context listener
or servletcontextinitializer (both will work and rely on tomcat internals)
2. In beans.xml, rather than annotated mode - which skips a lot of classes
which can be used in CDI - we tend to prefer discovery mode "full" + trim:
https://github.com/apache/geronimo-health/blob/master/geronimo-health/src/main/resources/META-INF/beans.xml
3. Why not merging SPI files thanks to maven? (shade part, end of
http://openwebbeans.apache.org/meecrowave/meecrowave-maven/index.html)
4. You have a spring config (cxf.xml), not sure it is intended?
5. jettison is not needed since it is not the one used for json
serialization (guess you can drop several cxf deps)
Hope it makes sense.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 17 juin 2019 à 10:29, Rémy Maucherat <re...@apache.org> a écrit :
> Hi Romain,
>
> On Thu, Jun 13, 2019 at 6:52 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>>
>> https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1412
>> is likely the one but looks like johnzon was not scanned nor registered
>> programmatically
>>
>> Maybe code this bean:
>>
>> @Produces("application/json") // jaxrs import
>> @Provider //jaxrs import
>> @Dependent // cdi import
>> public class MyJson<T> extends JsonbJaxrsProvider<T> {}
>>
>> Should be enough if it is the issue (or use delegation instead of
>> inheritance)
>>
>
> Thanks for your help, I was able to make cxf work for me, and then package
> it in a less error prone way ( https://github.com/rmaucher/tomcat-cxf ).
> It does the following:
> - Use a bean to add the json provider
> - Package the necessary dependencies for json, jax-rs and cdi
> - Bundle the web-fragment for the cxf cdi servlet (I wasted quite a lot of
> time by using the regular cxf servlet, ultimately noticing that the trace
> wasn't using cdi)
> tomcat-owb should then be placed in lib, add the Server listener. It will
> CDI enable all webapps (if they use the support). CXF then uses that
> support. Due to its intricacies (and also the fact that it's not
> lightweight), I don't think CXF is a good choice to put in the main Tomcat
> lib folder (and at the moment, it won't work out of the box in that case).
>
> I tested with a health bean from the "tck":
> @Health
> @ApplicationScoped
> public class SuccessfulHealth implements HealthCheck {
> @Override
> public HealthCheckResponse call() {
> return HealthCheckResponse.named("successful-check").up().build();
> }
> }
> With the addition of the geronimo-health (which is a CDI extension),
> geronimo-health-common, microprofile-health-api-1.0, and the fat jar
> tomcat-cxf to /WEB-INF/lib, the bean is processed and runs (on
> /rest/health). I expect the other mp APIs like metrics to work in a similar
> way.
>
> Rémy
>
>
Re: CDI support improvements
Posted by Rémy Maucherat <re...@apache.org>.
Hi Romain,
On Thu, Jun 13, 2019 at 6:52 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
>
> https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1412
> is likely the one but looks like johnzon was not scanned nor registered
> programmatically
>
> Maybe code this bean:
>
> @Produces("application/json") // jaxrs import
> @Provider //jaxrs import
> @Dependent // cdi import
> public class MyJson<T> extends JsonbJaxrsProvider<T> {}
>
> Should be enough if it is the issue (or use delegation instead of
> inheritance)
>
Thanks for your help, I was able to make cxf work for me, and then package
it in a less error prone way ( https://github.com/rmaucher/tomcat-cxf ).
It does the following:
- Use a bean to add the json provider
- Package the necessary dependencies for json, jax-rs and cdi
- Bundle the web-fragment for the cxf cdi servlet (I wasted quite a lot of
time by using the regular cxf servlet, ultimately noticing that the trace
wasn't using cdi)
tomcat-owb should then be placed in lib, add the Server listener. It will
CDI enable all webapps (if they use the support). CXF then uses that
support. Due to its intricacies (and also the fact that it's not
lightweight), I don't think CXF is a good choice to put in the main Tomcat
lib folder (and at the moment, it won't work out of the box in that case).
I tested with a health bean from the "tck":
@Health
@ApplicationScoped
public class SuccessfulHealth implements HealthCheck {
@Override
public HealthCheckResponse call() {
return HealthCheckResponse.named("successful-check").up().build();
}
}
With the addition of the geronimo-health (which is a CDI extension),
geronimo-health-common, microprofile-health-api-1.0, and the fat jar
tomcat-cxf to /WEB-INF/lib, the bean is processed and runs (on
/rest/health). I expect the other mp APIs like metrics to work in a similar
way.
Rémy
Re: CDI support improvements
Posted by Romain Manni-Bucau <rm...@gmail.com>.
https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1412
is likely the one but looks like johnzon was not scanned nor registered
programmatically
Maybe code this bean:
@Produces("application/json") // jaxrs import
@Provider //jaxrs import
@Dependent // cdi import
public class MyJson<T> extends JsonbJaxrsProvider<T> {}
Should be enough if it is the issue (or use delegation instead of
inheritance)
Le jeu. 13 juin 2019 à 18:45, Rémy Maucherat <re...@apache.org> a écrit :
> On Thu, Jun 13, 2019 at 5:31 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> can you drop johnzon-jsonb (+-core + -mapper + jsonp and jsonb specs
>> jars) too?
>>
>
> Ok, thanks. Still not working though, and this part of the code doesn't
> have debug logs of any kind, so I'll now have to trace the whole thing. It
> feels bad I have to do that as serializing json didn't seem *so* complex
> overall in the first place.
>
> Rémy
>
>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le jeu. 13 juin 2019 à 17:26, Rémy Maucherat <re...@apache.org> a écrit :
>>
>>> On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau <
>>> rmannibucau@gmail.com> wrote:
>>>
>>>> Joke apart, and assuming you grabbed the spec yourself (geronimo, javax
>>>> or jakarta jars) you just need:
>>>>
>>>> org.apache.cxf:cxf-core:3.3.2
>>>> org.apache.cxf:cxf-rt-security:3.3.2
>>>> org.apache.cxf:cxf-rt-transports-http:3.3.2
>>>> org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
>>>> org.apache.cxf:cxf-integration-cdi:3.3.2
>>>> org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target
>>>> Microprofile you need it)
>>>>
>>>
>>> About CXF, I still have one issue related to json.
>>> org.apache.cxf.jaxrs.utils.JAXRSUtils.logMessageHandlerProblem No
>>> message body writer has been found for class
>>> org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint$AggregatedResponse,
>>> ContentType: application/json
>>> It should be very simple, but for whatever reason I cannot get it to
>>> work (I added cxf-rt-rs-extension-providers which has the json provider).
>>> Anyway it's mostly a cosmetic issue at this point.
>>>
>>> I now know what I want to do with CXF, but it's certainly harder than
>>> for OWN (no surprise).
>>>
>>> Rémy
>>>
>>>
Re: CDI support improvements
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Jun 13, 2019 at 5:31 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> can you drop johnzon-jsonb (+-core + -mapper + jsonp and jsonb specs jars)
> too?
>
Ok, thanks. Still not working though, and this part of the code doesn't
have debug logs of any kind, so I'll now have to trace the whole thing. It
feels bad I have to do that as serializing json didn't seem *so* complex
overall in the first place.
Rémy
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le jeu. 13 juin 2019 à 17:26, Rémy Maucherat <re...@apache.org> a écrit :
>
>> On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>
>>> Joke apart, and assuming you grabbed the spec yourself (geronimo, javax
>>> or jakarta jars) you just need:
>>>
>>> org.apache.cxf:cxf-core:3.3.2
>>> org.apache.cxf:cxf-rt-security:3.3.2
>>> org.apache.cxf:cxf-rt-transports-http:3.3.2
>>> org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
>>> org.apache.cxf:cxf-integration-cdi:3.3.2
>>> org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target
>>> Microprofile you need it)
>>>
>>
>> About CXF, I still have one issue related to json.
>> org.apache.cxf.jaxrs.utils.JAXRSUtils.logMessageHandlerProblem No message
>> body writer has been found for class
>> org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint$AggregatedResponse,
>> ContentType: application/json
>> It should be very simple, but for whatever reason I cannot get it to work
>> (I added cxf-rt-rs-extension-providers which has the json provider). Anyway
>> it's mostly a cosmetic issue at this point.
>>
>> I now know what I want to do with CXF, but it's certainly harder than for
>> OWN (no surprise).
>>
>> Rémy
>>
>>
Re: CDI support improvements
Posted by Romain Manni-Bucau <rm...@gmail.com>.
can you drop johnzon-jsonb (+-core + -mapper + jsonp and jsonb specs jars)
too?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le jeu. 13 juin 2019 à 17:26, Rémy Maucherat <re...@apache.org> a écrit :
> On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Joke apart, and assuming you grabbed the spec yourself (geronimo, javax
>> or jakarta jars) you just need:
>>
>> org.apache.cxf:cxf-core:3.3.2
>> org.apache.cxf:cxf-rt-security:3.3.2
>> org.apache.cxf:cxf-rt-transports-http:3.3.2
>> org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
>> org.apache.cxf:cxf-integration-cdi:3.3.2
>> org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target
>> Microprofile you need it)
>>
>
> About CXF, I still have one issue related to json.
> org.apache.cxf.jaxrs.utils.JAXRSUtils.logMessageHandlerProblem No message
> body writer has been found for class
> org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint$AggregatedResponse,
> ContentType: application/json
> It should be very simple, but for whatever reason I cannot get it to work
> (I added cxf-rt-rs-extension-providers which has the json provider). Anyway
> it's mostly a cosmetic issue at this point.
>
> I now know what I want to do with CXF, but it's certainly harder than for
> OWN (no surprise).
>
> Rémy
>
>
Re: CDI support improvements
Posted by Rémy Maucherat <re...@apache.org>.
On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Joke apart, and assuming you grabbed the spec yourself (geronimo, javax or
> jakarta jars) you just need:
>
> org.apache.cxf:cxf-core:3.3.2
> org.apache.cxf:cxf-rt-security:3.3.2
> org.apache.cxf:cxf-rt-transports-http:3.3.2
> org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
> org.apache.cxf:cxf-integration-cdi:3.3.2
> org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target
> Microprofile you need it)
>
About CXF, I still have one issue related to json.
org.apache.cxf.jaxrs.utils.JAXRSUtils.logMessageHandlerProblem No message
body writer has been found for class
org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint$AggregatedResponse,
ContentType: application/json
It should be very simple, but for whatever reason I cannot get it to work
(I added cxf-rt-rs-extension-providers which has the json provider). Anyway
it's mostly a cosmetic issue at this point.
I now know what I want to do with CXF, but it's certainly harder than for
OWN (no surprise).
Rémy
Re: CDI support improvements
Posted by Rémy Maucherat <re...@apache.org>.
On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hell Rémy,
>
> I commented inline
>
> Le mar. 11 juin 2019 à 23:29, Rémy Maucherat <re...@apache.org> a écrit :
>
>> On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>
>>> My 2cts would be that we have the luck to be fully ASF here so each
>>> project can likely get back its missing piece(s) and we stay overall
>>> consistent instead of creating yet another fork in our beloved foundation
>>> (we already have some concurrent servers or even jdbc pools which does not
>>> help much user land).
>>>
>>> @Rémy do you track the issues you encounter somewhere?
>>> For instance "CXF is not user friendly" but once you have CDI you get
>>> CXF set up just adding a servlet. Here, an initializer would have been
>>> friendly but then you would encounter the servlet initializer ordering
>>> issue.
>>>
>>
>> Ok :)
>>
>> So:
>> - When downloading CXF, I'm facing a myriad of JARs, and I cannot really
>> figure out what's mandatory (there's a WHICH_JARS file, so that cannot be
>> that good).
>>
>
> Depends, if you use maven it is fine ;).
>
> Joke apart, and assuming you grabbed the spec yourself (geronimo, javax or
> jakarta jars) you just need:
>
> org.apache.cxf:cxf-core:3.3.2
> org.apache.cxf:cxf-rt-security:3.3.2
> org.apache.cxf:cxf-rt-transports-http:3.3.2
> org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
> org.apache.cxf:cxf-integration-cdi:3.3.2
> org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target
> Microprofile you need it)
>
>
>> - (Ok I figured it out) Looking at the integration(s), I quickly notice
>> there are plenty I can use: cxf-integration-cdi, cxf-rt-rs-http-sci and
>> cxf-rt-transports-http (did I miss any ?). They all need that I define a
>> Servlet it seems (no idea why at least some of these don't do it for me).
>>
>
> There are two main concepts: the integration (cdi, spring, blueprint,
> ....) and the transport (http, jms, ...). Http transport goes through the
> servlet and the integration relies on the transport to forward the messages
> (request) to the CXF server which does the link with the beans.
>
Ok.
>
>
>> - After getting somewhere and trying a mp health test with your Geronimo
>> Health CDI bundle, I got:
>> 11-Jun-2019 17:28:34.004 WARNING [http-nio2-8080-exec-2]
>> org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare Both
>> org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint#getChecks
>> and
>> org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint#getChecks
>> are equal candidates for handling the current request which can lead to
>> unpredictable results
>> 11-Jun-2019 17:28:34.016 WARNING [http-nio2-8080-exec-2]
>> org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper.toResponse
>> javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error
>> at
>> org.apache.cxf.jaxrs.utils.SpecExceptions.toInternalServerErrorException(SpecExceptions.java:79)
>> at
>> org.apache.cxf.jaxrs.utils.ExceptionUtils.toInternalServerErrorException(ExceptionUtils.java:111)
>> at
>> org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1450)
>> at
>> org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.createInstance(PerRequestResourceProvider.java:89)
>> at
>> org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.getInstance(PerRequestResourceProvider.java:78)
>> at
>> org.apache.cxf.jaxrs.JAXRSInvoker.getServiceObject(JAXRSInvoker.java:420)
>> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:101)
>> ...
>> Caused by: java.lang.IllegalAccessException: Class
>> org.apache.cxf.jaxrs.utils.InjectionUtils can not access a member of class
>> org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint
>> with modifiers "private"
>> at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102)
>> at
>> java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:296)
>> at
>> java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:288)
>> at java.lang.reflect.Method.invoke(Method.java:491)
>> at
>> org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1442)
>> ... 47 more
>>
>> That's where I am right now. The way to use CXF with Tomcat should be
>> more obvious.
>>
>
> Geronimo Health has a common and a cdi modules (cdi one being not suffixed
> in terms of naming). Both are exactly the same except cdi one uses CDI
> beans for the wiring and common is reusable in an OSGi container.
> Common is not intended to be scanned.
> I will add a scan=none in the jar since it is not done today and leads to
> that issue if not excluded from the scanned jar - can be done through
> openwebbeans.properties.
>
> -> https://issues.apache.org/jira/browse/GERONIMO-6734 if you want to
> give another try with a snapshot
>
I will continue experimenting !
>
>
>>
>> OWB did not have most of these issues, the amount of libraries is
>> manageable and the integration was labelled as "tomcat7". The main issue
>> with OWB is that integration had issues [it needed some adjustments in
>> Tomcat to avoid instance manager replacement timing issues; other more
>> cosmetic problems were the use of both Catalina internal components and
>> Servlet level components, an integration should try to choose one or the
>> other unless there's a showstopper which forces both], so I tried to
>> modernize and improve it.
>>
>
> Not needed but owb-web mainly intends to be portable so relies on servlet.
> Not sure we would gain a lot moving it to catalina but not technical
> blocker AFAIK
>
>
>>
>>
>>>
>>> In other words I wonder if we can't cumulate our efforts instead of
>>> working isolated and moreover if we can avoid to split the code and
>>> deliverables more than necessary - sounds like overlapping will be very
>>> high without more details.
>>>
>>
>> I understand but CXF has too many constraints like the need to support
>> many many different kind of deployments and uses, so I'm not really blaming
>> anyone here.
>>
>
> Well, it can be improove so no issue blaming it while it converges ;).
> For example, I'm happy we encourage CXF to clarify its status on the
> dependencies and modularity (core can be split a loootttt), dependencies
> are very opiniated and transitive even when sometimes it shouldn't (spec
> should be a dedicated pom easily excludable IMHO etc),
> Also note that Wink (~fork from CXF) kinf of fail to simplify it keeping a
> living ecosystem -
> https://svn.apache.org/repos/infra/websites/production/wink/content/index.html -
> this is why interacting can be sane here IMHO.
>
>
>>
>>
>>> Do we have a functional showcase app already? Can help building one if
>>> needed.
>>> Do you have an idea of where you want to land (in terms of config +
>>> deliverables)?
>>>
>>
>> Yes, ok. So for OWB as an example, here's what I have:
>> - Use Tomcat 9.0.21.
>> - Add <Listener
>> className="org.apache.tomcat.webbeans.OpenWebBeansListener" optional="true"
>> /> to the <Server> element in server.xml. If OWB is not present, the
>> missing dependency of the listener will be logged as INFO (without causing
>> further problems). The context listener can also be configured in
>> conf/context.xml and it would apply to all webapps, but I prefer avoiding
>> this if possible (it's more hidden).
>>
>
> Open question on tomcat side: I never really understood why we can't have
> SPI listeners (Server and Context levels), I understand it as being a
> legacy part of the impl, is it time to revisit it?
> Typically I would have OpenWebBeansListener and a ServiceLoader auto
> installing it.
> The issue here - we had it on TomEE - is how you select it is enabled
> explicitly or disabled explicitly since you do it on an instance.
> In TomEE we used a context param but i'm sure a context listener can do
> the trick as well.
>
It would be easy to add a Catalina service for JARs to be used by the
service loader, I almost did it for Server listeners while I was improving
embedded last time. But I didn't like the end result vs server.xml (how to
remove the listener without removing the JAR, how to configure it further),
so I didn't add the feature.
>
>
>> - Add the JAR from tomcat-owb to the lib folder, then this should CDI
>> enable all webapps. One thing I'm not sure about yet is the separate
>> javax.* JARs, so let's ignore that "detail" for now ...
>> - The integration can also be used at the individual webapp level (as
>> before) using context.xml.
>>
>
> Is it needed? What it brings is only the servlet component integration
> (injections) AFAIK - since the other integration is the principal and this
> one can be done through a filter in owb-web "portably".
> So if we can configure the instance manager from the context.xml then we
> would be good and not need anything else - assuming activating it from the
> webapp is equivalent to letting the user run it from the webapp which is
> already done by several users.
>
Hum, well at this point I'm "happy" with the listener configuring the
instance manager, I'd rather not add more configuration that can be done
with the listener.
>
>
>> - It only uses Catalina components.
>>
>
> Hmm, Tomcat moves valves to filters so why would we revert it for its CDI
> integration? Not sure I got this one right.
>
If some parts and configuration are already Tomcat specific, I prefer using
Tomcat specific components for the rest as well (valves are a lot less
complex than filters and are faster). If everything can be portable and
there's a user benefit, then portable components are better, so that's why
some valves got redone as filters. That's not the case for CDI since it
will need some non portable components.
Rémy
>
>
>> Does that look better to you ?
>>
>> Getting there with CXF is harder.
>>
>>
>>> Answering both can be a way to move forward and see how we can converge.
>>> To complete David's answer, I kind of see that even without integrating
>>> some EE things in Tomcat itself, it can benefit to TomEE and enable it to
>>> align even more on Tomcat in terms of user facing configuration for
>>> instance.
>>>
>>
>> Right.
>>
>> Rémy
>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github
>>> <https://github.com/rmannibucau> | LinkedIn
>>> <https://www.linkedin.com/in/rmannibucau> | Book
>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>>
>>>
>>> Le mar. 11 juin 2019 à 21:22, Rémy Maucherat <re...@apache.org> a écrit :
>>>
>>>> Hi David,
>>>>
>>>> On Tue, Jun 11, 2019 at 8:37 PM David Blevins <da...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> At a high level, is there a desire to start supporting more "EE" like
>>>>> specs such as CDI, JAX-RS, JPA, etc?
>>>>>
>>>>> Completely understood if the answer is "depends." I suspect it would
>>>>> depend on if the code is clean and light in Tomcat spirit.
>>>>>
>>>>
>>>> Ok, so the plan (my plan, actually) here is that I noticed CDI (and
>>>> JAX-RS) is the building block of many other APIs (like the Microprofile),
>>>> so there's a need to be able to use it in a "clean and light [and] in
>>>> Tomcat spirit" way (as you said). I had a look at OWB and CXF and while the
>>>> support is there, it needs some work (especially for the latter) and is
>>>> certainly not user friendly (again, esp for the latter). Note that the work
>>>> is also in Tomcat itself, since I'm in a good position to make changes and
>>>> improvements as needed.
>>>>
>>>> As for the answer, it would still be "no" at this point, since at most
>>>> these could be considered as a couple extra optional modules like the jdbc
>>>> pool, or maybe "build them yourself" poms.
>>>>
>>>>
>>>>>
>>>>> I write this not from the perspective of "let's move a bunch of TomEE
>>>>> code into Tomcat", but more of "let's write cleaner newer code in Tomcat
>>>>> and retire equivalent TomEE code."
>>>>>
>>>>> That's not a specific proposal, just curious if appetite has developed
>>>>> in recent years to entertain tip-toeing beyond the same set of specs.
>>>>>
>>>>
>>>> Rémy
>>>>
>>>>>
>>>>>
>>>>> --
>>>>> David Blevins
>>>>> http://twitter.com/dblevins
>>>>> http://www.tomitribe.com
>>>>>
>>>>> > On Jun 11, 2019, at 8:06 AM, Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com> wrote:
>>>>> >
>>>>> >
>>>>> >
>>>>> > Le mar. 11 juin 2019 à 16:57, Rémy Maucherat <re...@apache.org> a
>>>>> écrit :
>>>>> > On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com> wrote:
>>>>> >
>>>>> > Once done it can be hosted on both side.Owb has the advantage to be
>>>>> know by users, tomcat to be a more natural home for an integration. At the
>>>>> end it is mainly synchronizing both projects for a consistent communication
>>>>> and code "move" IMHO.
>>>>> >
>>>>> > For deep tomcat/cxf integration, you can use
>>>>> http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core
>>>>> module. Technically it uses an embedded flavor but it would be easy to move
>>>>> to a standalone one through a listener based on a small refactoring in
>>>>> Meecrowave#start. The good part are the lifecycle and scanning integrations
>>>>> + the tooling to make testing and dev simple -
>>>>> http://openwebbeans.apache.org/meecrowave/.
>>>>> >
>>>>> > Ok, I think things look reasonably good using CDI extensions
>>>>> (looking at the Geronimo mp implementation you did) except the default CXF
>>>>> "servlet" integration. I think right now the "servlet" integration from the
>>>>> cxf-rt-transports-http package is "bad" and that the one from Meecrowave
>>>>> (in org.apache.meecrowave.cxf) is more likely to be the way to go (it
>>>>> derives from cxf-integration-cdi).
>>>>> >
>>>>> > So this looks a lot closer to Meecrowave than I originally expected,
>>>>> with a lot of "buts" though:
>>>>> > - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal
>>>>> here is a "Meecrowave for Tomcat"
>>>>> >
>>>>> > Guess this one can converge - at least for TomEE it did and we have
>>>>> a tons of flavors, I dont see a blocker to unify it here to.
>>>>> >
>>>>> > - The JAR has all of Tomcat, log4j, API JARs, etc, while it should
>>>>> here be based off Tomcat, the javax APIs and OWB already present in the
>>>>> Tomcat OWB implementation JAR (the classic "tomcat7" or the modernized
>>>>> "tomcat-owb")
>>>>> >
>>>>> > The jar is just one flavor of meecrowave - assuming you reference
>>>>> the fatjar, you should still be able to use it as plain unitary
>>>>> dependencies.
>>>>> > The missing part here is to extract from Meecrowave master class all
>>>>> the logic to "glue" the stack in Tomcat (mainly extracting it in a Listener
>>>>> I guess and ignoring the specific launcher config?)
>>>>> >
>>>>> > - log4j would need to be removed as well
>>>>> >
>>>>> > It is already supported, in this IT we drop log4j, johnzon, cxf:
>>>>> https://github.com/apache/meecrowave/blob/trunk/integration-tests/no-cxf/pom.xml#L32
>>>>> >
>>>>> > - plenty of configuration files and options in the JARs, but I guess
>>>>> that's the way it is since all the subcomponents are so flexible
>>>>> >
>>>>> > Yep, but all are also settable from a listener or a centralized
>>>>> file, we are really free here.
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > More technically: openwebbeans does not need properties files you
>>>>> can pass Properties when you create the WebBeansContext, this is what tomee
>>>>> does. Same for cxf and its bus ;).
>>>>> >
>>>>> > Ok, I'll have a look at that, it's better than properties files (but
>>>>> similar).
>>>>> >
>>>>> > Biggest short term challenge is to align scanners but it is very
>>>>> doable, long term it is to drop big core jars in all 3 libs for smaller
>>>>> bundles ;).
>>>>> >
>>>>> > Ok.
>>>>> >
>>>>> > Feel free to shout if you need help or more precise pointers.
>>>>> >
>>>>> > Rémy
>>>>> >
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>>
>>>>>
Re: CDI support improvements
Posted by David Blevins <da...@gmail.com>.
> On Jun 12, 2019, at 6:35 AM, Rémy Maucherat <re...@apache.org> wrote:
>
> On Wed, Jun 12, 2019 at 11:11 AM Mark Struberg <st...@yahoo.de.invalid> wrote:
>
> Rémy's enhancements are great - the better and cleaner the integration, the better for all those projects.
> But Romain and David are also correct: it's very easy to become a committer on all the involved projects, especially for people known to deliver outstanding code and to be excellent community players!
I'll restate my position below just to be clear I am a fan of the effort.
> Having a build reference to TomEE or OWB in Tomcat would introduce cycles in our builds. This is not really a good thing.
>
> That did not seem very practical to me so the said code is quite Tomcat-like right now and most importantly it needs the fixes made in 9.0.21, so it won't work with any older Tomcat. If you really can take it over (and un-Tomcatize the code, I suppose), no problem.
The "Tomcat-like" is the part I really like. Some historical perspective from my eyes:
- In Geronimo we did the integration "outside" Tomcat, by stripping it down
- In TomEE we did the integration "inside" Tomcat, but making no changes
I see this as a first attempt to potentially make some things easier in Tomcat itself and that is exciting and worth encouraging.
>
>
> B.) We should also try to keep code and responsibilities at a single place and shall try to avoid duplications. This has nothing to do with 'ownership' - shuch a concept doesn't exist at the ASF anyway. But it has a lot to do with users knowing exactly where to look at if they are searching for a bug or even want to contribute a new feature.
>
> Ok, so I guess I don't need to do anything further in that area since you prefer to continue covering it. I'll move on to other items on my todo list then.
I personally wouldn't want to see that. I restate that from my perspective, I'd be happy to make every attempt to drop no-longer-needed code from TomEE and uptake the newer code in Tomcat.
My only pause is if people actually want a CDI integration here. If people think it's worth at least a poke, however, I'm all in.
Is this something people would want and what is the best way to do it here-here? (not in one of our personal repos)
-David
Re: CDI support improvements
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Current owb-tomcat module is stable and could be used if some people need
it but it does not prevent us to make trunk 9.last based IMHO.
Maybe give a shout to owb dev list when you have something you want to
integrate and Ill be happy to review and support it.
Le mer. 12 juin 2019 à 18:13, Mark Struberg <st...@yahoo.de.invalid> a
écrit :
>
>
> > Am 12.06.2019 um 15:35 schrieb Rémy Maucherat <re...@apache.org>:
> >
>
> > That did not seem very practical to me so the said code is quite
> Tomcat-like
> > right now and most importantly it needs the fixes made in 9.0.21, so it
> won't
> > work with any older Tomcat. If you really can take it over
> > (and un-Tomcatize the code, I suppose), no problem.
>
> There are multiple options on the table.
> One would be to have this code checked via reflection.
> The other is to just add a new module which is for tomcat9++
>
> >
> > > B.) We should also try to keep code and responsibilities at a single
> place and shall try to avoid duplications. This has nothing to do with
> > > 'ownership' - shuch a concept doesn't exist at the ASF anyway. But it
> has a lot to do with users knowing exactly where to look at if they
> > > are searching for a bug or even want to contribute a new feature.
> >
> > Ok, so I guess I don't need to do anything further in that area since
> you prefer to continue covering it. I'll move on to other items on my todo
> list then.
> >
>
> We need a JIRA ticket in OWB with a description of the suggested
> improvements.
> After all we'd love to understand and document what improvements you would
> like to implement.
>
> And of course a patch would also be highly welcome!
>
> txs and LieGrue,
> strub
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: CDI support improvements
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
> Am 12.06.2019 um 15:35 schrieb Rémy Maucherat <re...@apache.org>:
>
> That did not seem very practical to me so the said code is quite Tomcat-like
> right now and most importantly it needs the fixes made in 9.0.21, so it won't
> work with any older Tomcat. If you really can take it over
> (and un-Tomcatize the code, I suppose), no problem.
There are multiple options on the table.
One would be to have this code checked via reflection.
The other is to just add a new module which is for tomcat9++
>
> > B.) We should also try to keep code and responsibilities at a single place and shall try to avoid duplications. This has nothing to do with
> > 'ownership' - shuch a concept doesn't exist at the ASF anyway. But it has a lot to do with users knowing exactly where to look at if they
> > are searching for a bug or even want to contribute a new feature.
>
> Ok, so I guess I don't need to do anything further in that area since you prefer to continue covering it. I'll move on to other items on my todo list then.
>
We need a JIRA ticket in OWB with a description of the suggested improvements.
After all we'd love to understand and document what improvements you would like to implement.
And of course a patch would also be highly welcome!
txs and LieGrue,
strub
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: CDI support improvements
Posted by Rémy Maucherat <re...@apache.org>.
On Wed, Jun 12, 2019 at 11:11 AM Mark Struberg <st...@yahoo.de.invalid>
wrote:
> Hi folks!
>
> Really happy to see so much love and interest for all those awesome ASF
> projects!
>
> Rémy's enhancements are great - the better and cleaner the integration,
> the better for all those projects.
> But Romain and David are also correct: it's very easy to become a
> committer on all the involved projects, especially for people known to
> deliver outstanding code and to be excellent community players!
>
> So at the end I really don't care much in which project stuff ends up.
> There are just a few ideas I'd like to have you think about:
>
> A.) There should be a clear 'dependency graph'.
> This is not so much a maven issue but really more a question of clear
> design.
> Tomcat is clearly the foundation of an EE server. It provides the
> ClassLoader setup, the servlet engine, etc.
> Tomcat provides abstract ways to integrate whatever wants to integrate
> with it via abstraction mechanisms. This might be CDI or Spring or Guice,
> or whatever!
>
> On top of this comes the CDI container who manages the instances. So all
> those parts live in OWB. Including the integration. So I'd keep the Tomcat
> integration as part of OWB.
>
> Even further up in the chain is Meecrowave as smallish Tomcat + CXF + CDI
> container and TomEE as fully blown JavaEE server.
>
> Having a build reference to TomEE or OWB in Tomcat would introduce cycles
> in our builds. This is not really a good thing.
>
That did not seem very practical to me so the said code is quite
Tomcat-like right now and most importantly it needs the fixes made in
9.0.21, so it won't work with any older Tomcat. If you really can take it
over (and un-Tomcatize the code, I suppose), no problem.
>
> B.) We should also try to keep code and responsibilities at a single place
> and shall try to avoid duplications. This has nothing to do with
> 'ownership' - shuch a concept doesn't exist at the ASF anyway. But it has a
> lot to do with users knowing exactly where to look at if they are searching
> for a bug or even want to contribute a new feature.
>
Ok, so I guess I don't need to do anything further in that area since you
prefer to continue covering it. I'll move on to other items on my todo list
then.
Rémy
>
> makes sense?
>
> txs and LieGrue,
> strub
>
>
>
> > Am 12.06.2019 um 08:31 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Hell Rémy,
> >
> > I commented inline
> >
> > Le mar. 11 juin 2019 à 23:29, Rémy Maucherat <re...@apache.org> a écrit :
> > On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
> > My 2cts would be that we have the luck to be fully ASF here so each
> project can likely get back its missing piece(s) and we stay overall
> consistent instead of creating yet another fork in our beloved foundation
> (we already have some concurrent servers or even jdbc pools which does not
> help much user land).
> >
> > @Rémy do you track the issues you encounter somewhere?
> > For instance "CXF is not user friendly" but once you have CDI you get
> CXF set up just adding a servlet. Here, an initializer would have been
> friendly but then you would encounter the servlet initializer ordering
> issue.
> >
> > Ok :)
> >
> > So:
> > - When downloading CXF, I'm facing a myriad of JARs, and I cannot really
> figure out what's mandatory (there's a WHICH_JARS file, so that cannot be
> that good).
> >
> > Depends, if you use maven it is fine ;).
> >
> > Joke apart, and assuming you grabbed the spec yourself (geronimo, javax
> or jakarta jars) you just need:
> >
> > org.apache.cxf:cxf-core:3.3.2
> > org.apache.cxf:cxf-rt-security:3.3.2
> > org.apache.cxf:cxf-rt-transports-http:3.3.2
> > org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
> > org.apache.cxf:cxf-integration-cdi:3.3.2
> > org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target
> Microprofile you need it)
> >
> > - (Ok I figured it out) Looking at the integration(s), I quickly notice
> there are plenty I can use: cxf-integration-cdi, cxf-rt-rs-http-sci and
> cxf-rt-transports-http (did I miss any ?). They all need that I define a
> Servlet it seems (no idea why at least some of these don't do it for me).
> >
> > There are two main concepts: the integration (cdi, spring, blueprint,
> ....) and the transport (http, jms, ...). Http transport goes through the
> servlet and the integration relies on the transport to forward the messages
> (request) to the CXF server which does the link with the beans.
> >
> > - After getting somewhere and trying a mp health test with your Geronimo
> Health CDI bundle, I got:
> > 11-Jun-2019 17:28:34.004 WARNING [http-nio2-8080-exec-2]
> org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare Both
> org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint#getChecks
> and
> org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint#getChecks
> are equal candidates for handling the current request which can lead to
> unpredictable results
> > 11-Jun-2019 17:28:34.016 WARNING [http-nio2-8080-exec-2]
> org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper.toResponse
> javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error
> > at
> org.apache.cxf.jaxrs.utils.SpecExceptions.toInternalServerErrorException(SpecExceptions.java:79)
> > at
> org.apache.cxf.jaxrs.utils.ExceptionUtils.toInternalServerErrorException(ExceptionUtils.java:111)
> > at
> org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1450)
> > at
> org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.createInstance(PerRequestResourceProvider.java:89)
> > at
> org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.getInstance(PerRequestResourceProvider.java:78)
> > at
> org.apache.cxf.jaxrs.JAXRSInvoker.getServiceObject(JAXRSInvoker.java:420)
> > at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:101)
> > ...
> > Caused by: java.lang.IllegalAccessException: Class
> org.apache.cxf.jaxrs.utils.InjectionUtils can not access a member of class
> org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint
> with modifiers "private"
> > at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102)
> > at
> java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:296)
> > at
> java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:288)
> > at java.lang.reflect.Method.invoke(Method.java:491)
> > at
> org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1442)
> > ... 47 more
> >
> > That's where I am right now. The way to use CXF with Tomcat should be
> more obvious.
> >
> > Geronimo Health has a common and a cdi modules (cdi one being not
> suffixed in terms of naming). Both are exactly the same except cdi one uses
> CDI beans for the wiring and common is reusable in an OSGi container.
> > Common is not intended to be scanned.
> > I will add a scan=none in the jar since it is not done today and leads
> to that issue if not excluded from the scanned jar - can be done through
> openwebbeans.properties.
> >
> > -> https://issues.apache.org/jira/browse/GERONIMO-6734 if you want to
> give another try with a snapshot
> >
> >
> > OWB did not have most of these issues, the amount of libraries is
> manageable and the integration was labelled as "tomcat7". The main issue
> with OWB is that integration had issues [it needed some adjustments in
> Tomcat to avoid instance manager replacement timing issues; other more
> cosmetic problems were the use of both Catalina internal components and
> Servlet level components, an integration should try to choose one or the
> other unless there's a showstopper which forces both], so I tried to
> modernize and improve it.
> >
> > Not needed but owb-web mainly intends to be portable so relies on
> servlet. Not sure we would gain a lot moving it to catalina but not
> technical blocker AFAIK
> >
> >
> >
> > In other words I wonder if we can't cumulate our efforts instead of
> working isolated and moreover if we can avoid to split the code and
> deliverables more than necessary - sounds like overlapping will be very
> high without more details.
> >
> > I understand but CXF has too many constraints like the need to support
> many many different kind of deployments and uses, so I'm not really blaming
> anyone here.
> >
> > Well, it can be improove so no issue blaming it while it converges ;).
> > For example, I'm happy we encourage CXF to clarify its status on the
> dependencies and modularity (core can be split a loootttt), dependencies
> are very opiniated and transitive even when sometimes it shouldn't (spec
> should be a dedicated pom easily excludable IMHO etc),
> > Also note that Wink (~fork from CXF) kinf of fail to simplify it keeping
> a living ecosystem -
> https://svn.apache.org/repos/infra/websites/production/wink/content/index.html
> - this is why interacting can be sane here IMHO.
> >
> >
> >
> > Do we have a functional showcase app already? Can help building one if
> needed.
> > Do you have an idea of where you want to land (in terms of config +
> deliverables)?
> >
> > Yes, ok. So for OWB as an example, here's what I have:
> > - Use Tomcat 9.0.21.
> > - Add <Listener
> className="org.apache.tomcat.webbeans.OpenWebBeansListener" optional="true"
> /> to the <Server> element in server.xml. If OWB is not present, the
> missing dependency of the listener will be logged as INFO (without causing
> further problems). The context listener can also be configured in
> conf/context.xml and it would apply to all webapps, but I prefer avoiding
> this if possible (it's more hidden).
> >
> > Open question on tomcat side: I never really understood why we can't
> have SPI listeners (Server and Context levels), I understand it as being a
> legacy part of the impl, is it time to revisit it?
> > Typically I would have OpenWebBeansListener and a ServiceLoader auto
> installing it.
> > The issue here - we had it on TomEE - is how you select it is enabled
> explicitly or disabled explicitly since you do it on an instance.
> > In TomEE we used a context param but i'm sure a context listener can do
> the trick as well.
> >
> > - Add the JAR from tomcat-owb to the lib folder, then this should CDI
> enable all webapps. One thing I'm not sure about yet is the separate
> javax.* JARs, so let's ignore that "detail" for now ...
> > - The integration can also be used at the individual webapp level (as
> before) using context.xml.
> >
> > Is it needed? What it brings is only the servlet component integration
> (injections) AFAIK - since the other integration is the principal and this
> one can be done through a filter in owb-web "portably".
> > So if we can configure the instance manager from the context.xml then we
> would be good and not need anything else - assuming activating it from the
> webapp is equivalent to letting the user run it from the webapp which is
> already done by several users.
> >
> > - It only uses Catalina components.
> >
> > Hmm, Tomcat moves valves to filters so why would we revert it for its
> CDI integration? Not sure I got this one right.
> >
> > Does that look better to you ?
> >
> > Getting there with CXF is harder.
> >
> >
> > Answering both can be a way to move forward and see how we can converge.
> > To complete David's answer, I kind of see that even without integrating
> some EE things in Tomcat itself, it can benefit to TomEE and enable it to
> align even more on Tomcat in terms of user facing configuration for
> instance.
> >
> > Right.
> >
> > Rémy
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
> >
> >
> > Le mar. 11 juin 2019 à 21:22, Rémy Maucherat <re...@apache.org> a écrit :
> > Hi David,
> >
> > On Tue, Jun 11, 2019 at 8:37 PM David Blevins <da...@gmail.com>
> wrote:
> > Hi All,
> >
> > At a high level, is there a desire to start supporting more "EE" like
> specs such as CDI, JAX-RS, JPA, etc?
> >
> > Completely understood if the answer is "depends." I suspect it would
> depend on if the code is clean and light in Tomcat spirit.
> >
> > Ok, so the plan (my plan, actually) here is that I noticed CDI (and
> JAX-RS) is the building block of many other APIs (like the Microprofile),
> so there's a need to be able to use it in a "clean and light [and] in
> Tomcat spirit" way (as you said). I had a look at OWB and CXF and while the
> support is there, it needs some work (especially for the latter) and is
> certainly not user friendly (again, esp for the latter). Note that the work
> is also in Tomcat itself, since I'm in a good position to make changes and
> improvements as needed.
> >
> > As for the answer, it would still be "no" at this point, since at most
> these could be considered as a couple extra optional modules like the jdbc
> pool, or maybe "build them yourself" poms.
> >
> >
> > I write this not from the perspective of "let's move a bunch of TomEE
> code into Tomcat", but more of "let's write cleaner newer code in Tomcat
> and retire equivalent TomEE code."
> >
> > That's not a specific proposal, just curious if appetite has developed
> in recent years to entertain tip-toeing beyond the same set of specs.
> >
> > Rémy
> >
> >
> > --
> > David Blevins
> > http://twitter.com/dblevins
> > http://www.tomitribe.com
> >
> > > On Jun 11, 2019, at 8:06 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> > >
> > >
> > >
> > > Le mar. 11 juin 2019 à 16:57, Rémy Maucherat <re...@apache.org> a
> écrit :
> > > On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
> > >
> > > Once done it can be hosted on both side.Owb has the advantage to be
> know by users, tomcat to be a more natural home for an integration. At the
> end it is mainly synchronizing both projects for a consistent communication
> and code "move" IMHO.
> > >
> > > For deep tomcat/cxf integration, you can use
> http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core
> module. Technically it uses an embedded flavor but it would be easy to move
> to a standalone one through a listener based on a small refactoring in
> Meecrowave#start. The good part are the lifecycle and scanning integrations
> + the tooling to make testing and dev simple -
> http://openwebbeans.apache.org/meecrowave/.
> > >
> > > Ok, I think things look reasonably good using CDI extensions (looking
> at the Geronimo mp implementation you did) except the default CXF "servlet"
> integration. I think right now the "servlet" integration from the
> cxf-rt-transports-http package is "bad" and that the one from Meecrowave
> (in org.apache.meecrowave.cxf) is more likely to be the way to go (it
> derives from cxf-integration-cdi).
> > >
> > > So this looks a lot closer to Meecrowave than I originally expected,
> with a lot of "buts" though:
> > > - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal
> here is a "Meecrowave for Tomcat"
> > >
> > > Guess this one can converge - at least for TomEE it did and we have a
> tons of flavors, I dont see a blocker to unify it here to.
> > >
> > > - The JAR has all of Tomcat, log4j, API JARs, etc, while it should
> here be based off Tomcat, the javax APIs and OWB already present in the
> Tomcat OWB implementation JAR (the classic "tomcat7" or the modernized
> "tomcat-owb")
> > >
> > > The jar is just one flavor of meecrowave - assuming you reference the
> fatjar, you should still be able to use it as plain unitary dependencies.
> > > The missing part here is to extract from Meecrowave master class all
> the logic to "glue" the stack in Tomcat (mainly extracting it in a Listener
> I guess and ignoring the specific launcher config?)
> > >
> > > - log4j would need to be removed as well
> > >
> > > It is already supported, in this IT we drop log4j, johnzon, cxf:
> https://github.com/apache/meecrowave/blob/trunk/integration-tests/no-cxf/pom.xml#L32
> > >
> > > - plenty of configuration files and options in the JARs, but I guess
> that's the way it is since all the subcomponents are so flexible
> > >
> > > Yep, but all are also settable from a listener or a centralized file,
> we are really free here.
> > >
> > >
> > >
> > >
> > > More technically: openwebbeans does not need properties files you can
> pass Properties when you create the WebBeansContext, this is what tomee
> does. Same for cxf and its bus ;).
> > >
> > > Ok, I'll have a look at that, it's better than properties files (but
> similar).
> > >
> > > Biggest short term challenge is to align scanners but it is very
> doable, long term it is to drop big core jars in all 3 libs for smaller
> bundles ;).
> > >
> > > Ok.
> > >
> > > Feel free to shout if you need help or more precise pointers.
> > >
> > > Rémy
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: CDI support improvements
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Hi folks!
Really happy to see so much love and interest for all those awesome ASF projects!
Rémy's enhancements are great - the better and cleaner the integration, the better for all those projects.
But Romain and David are also correct: it's very easy to become a committer on all the involved projects, especially for people known to deliver outstanding code and to be excellent community players!
So at the end I really don't care much in which project stuff ends up. There are just a few ideas I'd like to have you think about:
A.) There should be a clear 'dependency graph'.
This is not so much a maven issue but really more a question of clear design.
Tomcat is clearly the foundation of an EE server. It provides the ClassLoader setup, the servlet engine, etc.
Tomcat provides abstract ways to integrate whatever wants to integrate with it via abstraction mechanisms. This might be CDI or Spring or Guice, or whatever!
On top of this comes the CDI container who manages the instances. So all those parts live in OWB. Including the integration. So I'd keep the Tomcat integration as part of OWB.
Even further up in the chain is Meecrowave as smallish Tomcat + CXF + CDI container and TomEE as fully blown JavaEE server.
Having a build reference to TomEE or OWB in Tomcat would introduce cycles in our builds. This is not really a good thing.
B.) We should also try to keep code and responsibilities at a single place and shall try to avoid duplications. This has nothing to do with 'ownership' - shuch a concept doesn't exist at the ASF anyway. But it has a lot to do with users knowing exactly where to look at if they are searching for a bug or even want to contribute a new feature.
makes sense?
txs and LieGrue,
strub
> Am 12.06.2019 um 08:31 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Hell Rémy,
>
> I commented inline
>
> Le mar. 11 juin 2019 à 23:29, Rémy Maucherat <re...@apache.org> a écrit :
> On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau <rm...@gmail.com> wrote:
> My 2cts would be that we have the luck to be fully ASF here so each project can likely get back its missing piece(s) and we stay overall consistent instead of creating yet another fork in our beloved foundation (we already have some concurrent servers or even jdbc pools which does not help much user land).
>
> @Rémy do you track the issues you encounter somewhere?
> For instance "CXF is not user friendly" but once you have CDI you get CXF set up just adding a servlet. Here, an initializer would have been friendly but then you would encounter the servlet initializer ordering issue.
>
> Ok :)
>
> So:
> - When downloading CXF, I'm facing a myriad of JARs, and I cannot really figure out what's mandatory (there's a WHICH_JARS file, so that cannot be that good).
>
> Depends, if you use maven it is fine ;).
>
> Joke apart, and assuming you grabbed the spec yourself (geronimo, javax or jakarta jars) you just need:
>
> org.apache.cxf:cxf-core:3.3.2
> org.apache.cxf:cxf-rt-security:3.3.2
> org.apache.cxf:cxf-rt-transports-http:3.3.2
> org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
> org.apache.cxf:cxf-integration-cdi:3.3.2
> org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target Microprofile you need it)
>
> - (Ok I figured it out) Looking at the integration(s), I quickly notice there are plenty I can use: cxf-integration-cdi, cxf-rt-rs-http-sci and cxf-rt-transports-http (did I miss any ?). They all need that I define a Servlet it seems (no idea why at least some of these don't do it for me).
>
> There are two main concepts: the integration (cdi, spring, blueprint, ....) and the transport (http, jms, ...). Http transport goes through the servlet and the integration relies on the transport to forward the messages (request) to the CXF server which does the link with the beans.
>
> - After getting somewhere and trying a mp health test with your Geronimo Health CDI bundle, I got:
> 11-Jun-2019 17:28:34.004 WARNING [http-nio2-8080-exec-2] org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare Both org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint#getChecks and org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint#getChecks are equal candidates for handling the current request which can lead to unpredictable results
> 11-Jun-2019 17:28:34.016 WARNING [http-nio2-8080-exec-2] org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper.toResponse javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error
> at org.apache.cxf.jaxrs.utils.SpecExceptions.toInternalServerErrorException(SpecExceptions.java:79)
> at org.apache.cxf.jaxrs.utils.ExceptionUtils.toInternalServerErrorException(ExceptionUtils.java:111)
> at org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1450)
> at org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.createInstance(PerRequestResourceProvider.java:89)
> at org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.getInstance(PerRequestResourceProvider.java:78)
> at org.apache.cxf.jaxrs.JAXRSInvoker.getServiceObject(JAXRSInvoker.java:420)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:101)
> ...
> Caused by: java.lang.IllegalAccessException: Class org.apache.cxf.jaxrs.utils.InjectionUtils can not access a member of class org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint with modifiers "private"
> at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102)
> at java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:296)
> at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:288)
> at java.lang.reflect.Method.invoke(Method.java:491)
> at org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1442)
> ... 47 more
>
> That's where I am right now. The way to use CXF with Tomcat should be more obvious.
>
> Geronimo Health has a common and a cdi modules (cdi one being not suffixed in terms of naming). Both are exactly the same except cdi one uses CDI beans for the wiring and common is reusable in an OSGi container.
> Common is not intended to be scanned.
> I will add a scan=none in the jar since it is not done today and leads to that issue if not excluded from the scanned jar - can be done through openwebbeans.properties.
>
> -> https://issues.apache.org/jira/browse/GERONIMO-6734 if you want to give another try with a snapshot
>
>
> OWB did not have most of these issues, the amount of libraries is manageable and the integration was labelled as "tomcat7". The main issue with OWB is that integration had issues [it needed some adjustments in Tomcat to avoid instance manager replacement timing issues; other more cosmetic problems were the use of both Catalina internal components and Servlet level components, an integration should try to choose one or the other unless there's a showstopper which forces both], so I tried to modernize and improve it.
>
> Not needed but owb-web mainly intends to be portable so relies on servlet. Not sure we would gain a lot moving it to catalina but not technical blocker AFAIK
>
>
>
> In other words I wonder if we can't cumulate our efforts instead of working isolated and moreover if we can avoid to split the code and deliverables more than necessary - sounds like overlapping will be very high without more details.
>
> I understand but CXF has too many constraints like the need to support many many different kind of deployments and uses, so I'm not really blaming anyone here.
>
> Well, it can be improove so no issue blaming it while it converges ;).
> For example, I'm happy we encourage CXF to clarify its status on the dependencies and modularity (core can be split a loootttt), dependencies are very opiniated and transitive even when sometimes it shouldn't (spec should be a dedicated pom easily excludable IMHO etc),
> Also note that Wink (~fork from CXF) kinf of fail to simplify it keeping a living ecosystem - https://svn.apache.org/repos/infra/websites/production/wink/content/index.html - this is why interacting can be sane here IMHO.
>
>
>
> Do we have a functional showcase app already? Can help building one if needed.
> Do you have an idea of where you want to land (in terms of config + deliverables)?
>
> Yes, ok. So for OWB as an example, here's what I have:
> - Use Tomcat 9.0.21.
> - Add <Listener className="org.apache.tomcat.webbeans.OpenWebBeansListener" optional="true" /> to the <Server> element in server.xml. If OWB is not present, the missing dependency of the listener will be logged as INFO (without causing further problems). The context listener can also be configured in conf/context.xml and it would apply to all webapps, but I prefer avoiding this if possible (it's more hidden).
>
> Open question on tomcat side: I never really understood why we can't have SPI listeners (Server and Context levels), I understand it as being a legacy part of the impl, is it time to revisit it?
> Typically I would have OpenWebBeansListener and a ServiceLoader auto installing it.
> The issue here - we had it on TomEE - is how you select it is enabled explicitly or disabled explicitly since you do it on an instance.
> In TomEE we used a context param but i'm sure a context listener can do the trick as well.
>
> - Add the JAR from tomcat-owb to the lib folder, then this should CDI enable all webapps. One thing I'm not sure about yet is the separate javax.* JARs, so let's ignore that "detail" for now ...
> - The integration can also be used at the individual webapp level (as before) using context.xml.
>
> Is it needed? What it brings is only the servlet component integration (injections) AFAIK - since the other integration is the principal and this one can be done through a filter in owb-web "portably".
> So if we can configure the instance manager from the context.xml then we would be good and not need anything else - assuming activating it from the webapp is equivalent to letting the user run it from the webapp which is already done by several users.
>
> - It only uses Catalina components.
>
> Hmm, Tomcat moves valves to filters so why would we revert it for its CDI integration? Not sure I got this one right.
>
> Does that look better to you ?
>
> Getting there with CXF is harder.
>
>
> Answering both can be a way to move forward and see how we can converge.
> To complete David's answer, I kind of see that even without integrating some EE things in Tomcat itself, it can benefit to TomEE and enable it to align even more on Tomcat in terms of user facing configuration for instance.
>
> Right.
>
> Rémy
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>
>
> Le mar. 11 juin 2019 à 21:22, Rémy Maucherat <re...@apache.org> a écrit :
> Hi David,
>
> On Tue, Jun 11, 2019 at 8:37 PM David Blevins <da...@gmail.com> wrote:
> Hi All,
>
> At a high level, is there a desire to start supporting more "EE" like specs such as CDI, JAX-RS, JPA, etc?
>
> Completely understood if the answer is "depends." I suspect it would depend on if the code is clean and light in Tomcat spirit.
>
> Ok, so the plan (my plan, actually) here is that I noticed CDI (and JAX-RS) is the building block of many other APIs (like the Microprofile), so there's a need to be able to use it in a "clean and light [and] in Tomcat spirit" way (as you said). I had a look at OWB and CXF and while the support is there, it needs some work (especially for the latter) and is certainly not user friendly (again, esp for the latter). Note that the work is also in Tomcat itself, since I'm in a good position to make changes and improvements as needed.
>
> As for the answer, it would still be "no" at this point, since at most these could be considered as a couple extra optional modules like the jdbc pool, or maybe "build them yourself" poms.
>
>
> I write this not from the perspective of "let's move a bunch of TomEE code into Tomcat", but more of "let's write cleaner newer code in Tomcat and retire equivalent TomEE code."
>
> That's not a specific proposal, just curious if appetite has developed in recent years to entertain tip-toeing beyond the same set of specs.
>
> Rémy
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Jun 11, 2019, at 8:06 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
> >
> >
> >
> > Le mar. 11 juin 2019 à 16:57, Rémy Maucherat <re...@apache.org> a écrit :
> > On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <rm...@gmail.com> wrote:
> >
> > Once done it can be hosted on both side.Owb has the advantage to be know by users, tomcat to be a more natural home for an integration. At the end it is mainly synchronizing both projects for a consistent communication and code "move" IMHO.
> >
> > For deep tomcat/cxf integration, you can use http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core module. Technically it uses an embedded flavor but it would be easy to move to a standalone one through a listener based on a small refactoring in Meecrowave#start. The good part are the lifecycle and scanning integrations + the tooling to make testing and dev simple - http://openwebbeans.apache.org/meecrowave/.
> >
> > Ok, I think things look reasonably good using CDI extensions (looking at the Geronimo mp implementation you did) except the default CXF "servlet" integration. I think right now the "servlet" integration from the cxf-rt-transports-http package is "bad" and that the one from Meecrowave (in org.apache.meecrowave.cxf) is more likely to be the way to go (it derives from cxf-integration-cdi).
> >
> > So this looks a lot closer to Meecrowave than I originally expected, with a lot of "buts" though:
> > - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal here is a "Meecrowave for Tomcat"
> >
> > Guess this one can converge - at least for TomEE it did and we have a tons of flavors, I dont see a blocker to unify it here to.
> >
> > - The JAR has all of Tomcat, log4j, API JARs, etc, while it should here be based off Tomcat, the javax APIs and OWB already present in the Tomcat OWB implementation JAR (the classic "tomcat7" or the modernized "tomcat-owb")
> >
> > The jar is just one flavor of meecrowave - assuming you reference the fatjar, you should still be able to use it as plain unitary dependencies.
> > The missing part here is to extract from Meecrowave master class all the logic to "glue" the stack in Tomcat (mainly extracting it in a Listener I guess and ignoring the specific launcher config?)
> >
> > - log4j would need to be removed as well
> >
> > It is already supported, in this IT we drop log4j, johnzon, cxf: https://github.com/apache/meecrowave/blob/trunk/integration-tests/no-cxf/pom.xml#L32
> >
> > - plenty of configuration files and options in the JARs, but I guess that's the way it is since all the subcomponents are so flexible
> >
> > Yep, but all are also settable from a listener or a centralized file, we are really free here.
> >
> >
> >
> >
> > More technically: openwebbeans does not need properties files you can pass Properties when you create the WebBeansContext, this is what tomee does. Same for cxf and its bus ;).
> >
> > Ok, I'll have a look at that, it's better than properties files (but similar).
> >
> > Biggest short term challenge is to align scanners but it is very doable, long term it is to drop big core jars in all 3 libs for smaller bundles ;).
> >
> > Ok.
> >
> > Feel free to shout if you need help or more precise pointers.
> >
> > Rémy
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: CDI support improvements
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hell Rémy,
I commented inline
Le mar. 11 juin 2019 à 23:29, Rémy Maucherat <re...@apache.org> a écrit :
> On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> My 2cts would be that we have the luck to be fully ASF here so each
>> project can likely get back its missing piece(s) and we stay overall
>> consistent instead of creating yet another fork in our beloved foundation
>> (we already have some concurrent servers or even jdbc pools which does not
>> help much user land).
>>
>> @Rémy do you track the issues you encounter somewhere?
>> For instance "CXF is not user friendly" but once you have CDI you get CXF
>> set up just adding a servlet. Here, an initializer would have been friendly
>> but then you would encounter the servlet initializer ordering issue.
>>
>
> Ok :)
>
> So:
> - When downloading CXF, I'm facing a myriad of JARs, and I cannot really
> figure out what's mandatory (there's a WHICH_JARS file, so that cannot be
> that good).
>
Depends, if you use maven it is fine ;).
Joke apart, and assuming you grabbed the spec yourself (geronimo, javax or
jakarta jars) you just need:
org.apache.cxf:cxf-core:3.3.2
org.apache.cxf:cxf-rt-security:3.3.2
org.apache.cxf:cxf-rt-transports-http:3.3.2
org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
org.apache.cxf:cxf-integration-cdi:3.3.2
org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target
Microprofile you need it)
> - (Ok I figured it out) Looking at the integration(s), I quickly notice
> there are plenty I can use: cxf-integration-cdi, cxf-rt-rs-http-sci and
> cxf-rt-transports-http (did I miss any ?). They all need that I define a
> Servlet it seems (no idea why at least some of these don't do it for me).
>
There are two main concepts: the integration (cdi, spring, blueprint, ....)
and the transport (http, jms, ...). Http transport goes through the servlet
and the integration relies on the transport to forward the messages
(request) to the CXF server which does the link with the beans.
> - After getting somewhere and trying a mp health test with your Geronimo
> Health CDI bundle, I got:
> 11-Jun-2019 17:28:34.004 WARNING [http-nio2-8080-exec-2]
> org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare Both
> org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint#getChecks
> and
> org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint#getChecks
> are equal candidates for handling the current request which can lead to
> unpredictable results
> 11-Jun-2019 17:28:34.016 WARNING [http-nio2-8080-exec-2]
> org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper.toResponse
> javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error
> at
> org.apache.cxf.jaxrs.utils.SpecExceptions.toInternalServerErrorException(SpecExceptions.java:79)
> at
> org.apache.cxf.jaxrs.utils.ExceptionUtils.toInternalServerErrorException(ExceptionUtils.java:111)
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1450)
> at
> org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.createInstance(PerRequestResourceProvider.java:89)
> at
> org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.getInstance(PerRequestResourceProvider.java:78)
> at
> org.apache.cxf.jaxrs.JAXRSInvoker.getServiceObject(JAXRSInvoker.java:420)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:101)
> ...
> Caused by: java.lang.IllegalAccessException: Class
> org.apache.cxf.jaxrs.utils.InjectionUtils can not access a member of class
> org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint
> with modifiers "private"
> at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102)
> at
> java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:296)
> at
> java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:288)
> at java.lang.reflect.Method.invoke(Method.java:491)
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1442)
> ... 47 more
>
> That's where I am right now. The way to use CXF with Tomcat should be more
> obvious.
>
Geronimo Health has a common and a cdi modules (cdi one being not suffixed
in terms of naming). Both are exactly the same except cdi one uses CDI
beans for the wiring and common is reusable in an OSGi container.
Common is not intended to be scanned.
I will add a scan=none in the jar since it is not done today and leads to
that issue if not excluded from the scanned jar - can be done through
openwebbeans.properties.
-> https://issues.apache.org/jira/browse/GERONIMO-6734 if you want to give
another try with a snapshot
>
> OWB did not have most of these issues, the amount of libraries is
> manageable and the integration was labelled as "tomcat7". The main issue
> with OWB is that integration had issues [it needed some adjustments in
> Tomcat to avoid instance manager replacement timing issues; other more
> cosmetic problems were the use of both Catalina internal components and
> Servlet level components, an integration should try to choose one or the
> other unless there's a showstopper which forces both], so I tried to
> modernize and improve it.
>
Not needed but owb-web mainly intends to be portable so relies on servlet.
Not sure we would gain a lot moving it to catalina but not technical
blocker AFAIK
>
>
>>
>> In other words I wonder if we can't cumulate our efforts instead of
>> working isolated and moreover if we can avoid to split the code and
>> deliverables more than necessary - sounds like overlapping will be very
>> high without more details.
>>
>
> I understand but CXF has too many constraints like the need to support
> many many different kind of deployments and uses, so I'm not really blaming
> anyone here.
>
Well, it can be improove so no issue blaming it while it converges ;).
For example, I'm happy we encourage CXF to clarify its status on the
dependencies and modularity (core can be split a loootttt), dependencies
are very opiniated and transitive even when sometimes it shouldn't (spec
should be a dedicated pom easily excludable IMHO etc),
Also note that Wink (~fork from CXF) kinf of fail to simplify it keeping a
living ecosystem -
https://svn.apache.org/repos/infra/websites/production/wink/content/index.html
-
this is why interacting can be sane here IMHO.
>
>
>> Do we have a functional showcase app already? Can help building one if
>> needed.
>> Do you have an idea of where you want to land (in terms of config +
>> deliverables)?
>>
>
> Yes, ok. So for OWB as an example, here's what I have:
> - Use Tomcat 9.0.21.
> - Add <Listener
> className="org.apache.tomcat.webbeans.OpenWebBeansListener" optional="true"
> /> to the <Server> element in server.xml. If OWB is not present, the
> missing dependency of the listener will be logged as INFO (without causing
> further problems). The context listener can also be configured in
> conf/context.xml and it would apply to all webapps, but I prefer avoiding
> this if possible (it's more hidden).
>
Open question on tomcat side: I never really understood why we can't have
SPI listeners (Server and Context levels), I understand it as being a
legacy part of the impl, is it time to revisit it?
Typically I would have OpenWebBeansListener and a ServiceLoader auto
installing it.
The issue here - we had it on TomEE - is how you select it is enabled
explicitly or disabled explicitly since you do it on an instance.
In TomEE we used a context param but i'm sure a context listener can do the
trick as well.
> - Add the JAR from tomcat-owb to the lib folder, then this should CDI
> enable all webapps. One thing I'm not sure about yet is the separate
> javax.* JARs, so let's ignore that "detail" for now ...
> - The integration can also be used at the individual webapp level (as
> before) using context.xml.
>
Is it needed? What it brings is only the servlet component integration
(injections) AFAIK - since the other integration is the principal and this
one can be done through a filter in owb-web "portably".
So if we can configure the instance manager from the context.xml then we
would be good and not need anything else - assuming activating it from the
webapp is equivalent to letting the user run it from the webapp which is
already done by several users.
> - It only uses Catalina components.
>
Hmm, Tomcat moves valves to filters so why would we revert it for its CDI
integration? Not sure I got this one right.
> Does that look better to you ?
>
> Getting there with CXF is harder.
>
>
>> Answering both can be a way to move forward and see how we can converge.
>> To complete David's answer, I kind of see that even without integrating
>> some EE things in Tomcat itself, it can benefit to TomEE and enable it to
>> align even more on Tomcat in terms of user facing configuration for
>> instance.
>>
>
> Right.
>
> Rémy
>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le mar. 11 juin 2019 à 21:22, Rémy Maucherat <re...@apache.org> a écrit :
>>
>>> Hi David,
>>>
>>> On Tue, Jun 11, 2019 at 8:37 PM David Blevins <da...@gmail.com>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> At a high level, is there a desire to start supporting more "EE" like
>>>> specs such as CDI, JAX-RS, JPA, etc?
>>>>
>>>> Completely understood if the answer is "depends." I suspect it would
>>>> depend on if the code is clean and light in Tomcat spirit.
>>>>
>>>
>>> Ok, so the plan (my plan, actually) here is that I noticed CDI (and
>>> JAX-RS) is the building block of many other APIs (like the Microprofile),
>>> so there's a need to be able to use it in a "clean and light [and] in
>>> Tomcat spirit" way (as you said). I had a look at OWB and CXF and while the
>>> support is there, it needs some work (especially for the latter) and is
>>> certainly not user friendly (again, esp for the latter). Note that the work
>>> is also in Tomcat itself, since I'm in a good position to make changes and
>>> improvements as needed.
>>>
>>> As for the answer, it would still be "no" at this point, since at most
>>> these could be considered as a couple extra optional modules like the jdbc
>>> pool, or maybe "build them yourself" poms.
>>>
>>>
>>>>
>>>> I write this not from the perspective of "let's move a bunch of TomEE
>>>> code into Tomcat", but more of "let's write cleaner newer code in Tomcat
>>>> and retire equivalent TomEE code."
>>>>
>>>> That's not a specific proposal, just curious if appetite has developed
>>>> in recent years to entertain tip-toeing beyond the same set of specs.
>>>>
>>>
>>> Rémy
>>>
>>>>
>>>>
>>>> --
>>>> David Blevins
>>>> http://twitter.com/dblevins
>>>> http://www.tomitribe.com
>>>>
>>>> > On Jun 11, 2019, at 8:06 AM, Romain Manni-Bucau <
>>>> rmannibucau@gmail.com> wrote:
>>>> >
>>>> >
>>>> >
>>>> > Le mar. 11 juin 2019 à 16:57, Rémy Maucherat <re...@apache.org> a
>>>> écrit :
>>>> > On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <
>>>> rmannibucau@gmail.com> wrote:
>>>> >
>>>> > Once done it can be hosted on both side.Owb has the advantage to be
>>>> know by users, tomcat to be a more natural home for an integration. At the
>>>> end it is mainly synchronizing both projects for a consistent communication
>>>> and code "move" IMHO.
>>>> >
>>>> > For deep tomcat/cxf integration, you can use
>>>> http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core
>>>> module. Technically it uses an embedded flavor but it would be easy to move
>>>> to a standalone one through a listener based on a small refactoring in
>>>> Meecrowave#start. The good part are the lifecycle and scanning integrations
>>>> + the tooling to make testing and dev simple -
>>>> http://openwebbeans.apache.org/meecrowave/.
>>>> >
>>>> > Ok, I think things look reasonably good using CDI extensions (looking
>>>> at the Geronimo mp implementation you did) except the default CXF "servlet"
>>>> integration. I think right now the "servlet" integration from the
>>>> cxf-rt-transports-http package is "bad" and that the one from Meecrowave
>>>> (in org.apache.meecrowave.cxf) is more likely to be the way to go (it
>>>> derives from cxf-integration-cdi).
>>>> >
>>>> > So this looks a lot closer to Meecrowave than I originally expected,
>>>> with a lot of "buts" though:
>>>> > - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal
>>>> here is a "Meecrowave for Tomcat"
>>>> >
>>>> > Guess this one can converge - at least for TomEE it did and we have a
>>>> tons of flavors, I dont see a blocker to unify it here to.
>>>> >
>>>> > - The JAR has all of Tomcat, log4j, API JARs, etc, while it should
>>>> here be based off Tomcat, the javax APIs and OWB already present in the
>>>> Tomcat OWB implementation JAR (the classic "tomcat7" or the modernized
>>>> "tomcat-owb")
>>>> >
>>>> > The jar is just one flavor of meecrowave - assuming you reference the
>>>> fatjar, you should still be able to use it as plain unitary dependencies.
>>>> > The missing part here is to extract from Meecrowave master class all
>>>> the logic to "glue" the stack in Tomcat (mainly extracting it in a Listener
>>>> I guess and ignoring the specific launcher config?)
>>>> >
>>>> > - log4j would need to be removed as well
>>>> >
>>>> > It is already supported, in this IT we drop log4j, johnzon, cxf:
>>>> https://github.com/apache/meecrowave/blob/trunk/integration-tests/no-cxf/pom.xml#L32
>>>> >
>>>> > - plenty of configuration files and options in the JARs, but I guess
>>>> that's the way it is since all the subcomponents are so flexible
>>>> >
>>>> > Yep, but all are also settable from a listener or a centralized file,
>>>> we are really free here.
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > More technically: openwebbeans does not need properties files you can
>>>> pass Properties when you create the WebBeansContext, this is what tomee
>>>> does. Same for cxf and its bus ;).
>>>> >
>>>> > Ok, I'll have a look at that, it's better than properties files (but
>>>> similar).
>>>> >
>>>> > Biggest short term challenge is to align scanners but it is very
>>>> doable, long term it is to drop big core jars in all 3 libs for smaller
>>>> bundles ;).
>>>> >
>>>> > Ok.
>>>> >
>>>> > Feel free to shout if you need help or more precise pointers.
>>>> >
>>>> > Rémy
>>>> >
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>
>>>>
Re: CDI support improvements
Posted by Rémy Maucherat <re...@apache.org>.
On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> My 2cts would be that we have the luck to be fully ASF here so each
> project can likely get back its missing piece(s) and we stay overall
> consistent instead of creating yet another fork in our beloved foundation
> (we already have some concurrent servers or even jdbc pools which does not
> help much user land).
>
> @Rémy do you track the issues you encounter somewhere?
> For instance "CXF is not user friendly" but once you have CDI you get CXF
> set up just adding a servlet. Here, an initializer would have been friendly
> but then you would encounter the servlet initializer ordering issue.
>
Ok :)
So:
- When downloading CXF, I'm facing a myriad of JARs, and I cannot really
figure out what's mandatory (there's a WHICH_JARS file, so that cannot be
that good).
- (Ok I figured it out) Looking at the integration(s), I quickly notice
there are plenty I can use: cxf-integration-cdi, cxf-rt-rs-http-sci and
cxf-rt-transports-http (did I miss any ?). They all need that I define a
Servlet it seems (no idea why at least some of these don't do it for me).
- After getting somewhere and trying a mp health test with your Geronimo
Health CDI bundle, I got:
11-Jun-2019 17:28:34.004 WARNING [http-nio2-8080-exec-2]
org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare Both
org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint#getChecks
and
org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint#getChecks
are equal candidates for handling the current request which can lead to
unpredictable results
11-Jun-2019 17:28:34.016 WARNING [http-nio2-8080-exec-2]
org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper.toResponse
javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error
at
org.apache.cxf.jaxrs.utils.SpecExceptions.toInternalServerErrorException(SpecExceptions.java:79)
at
org.apache.cxf.jaxrs.utils.ExceptionUtils.toInternalServerErrorException(ExceptionUtils.java:111)
at
org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1450)
at
org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.createInstance(PerRequestResourceProvider.java:89)
at
org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.getInstance(PerRequestResourceProvider.java:78)
at org.apache.cxf.jaxrs.JAXRSInvoker.getServiceObject(JAXRSInvoker.java:420)
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:101)
...
Caused by: java.lang.IllegalAccessException: Class
org.apache.cxf.jaxrs.utils.InjectionUtils can not access a member of class
org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint
with modifiers "private"
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102)
at
java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:296)
at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:288)
at java.lang.reflect.Method.invoke(Method.java:491)
at
org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1442)
... 47 more
That's where I am right now. The way to use CXF with Tomcat should be more
obvious.
OWB did not have most of these issues, the amount of libraries is
manageable and the integration was labelled as "tomcat7". The main issue
with OWB is that integration had issues [it needed some adjustments in
Tomcat to avoid instance manager replacement timing issues; other more
cosmetic problems were the use of both Catalina internal components and
Servlet level components, an integration should try to choose one or the
other unless there's a showstopper which forces both], so I tried to
modernize and improve it.
>
> In other words I wonder if we can't cumulate our efforts instead of
> working isolated and moreover if we can avoid to split the code and
> deliverables more than necessary - sounds like overlapping will be very
> high without more details.
>
I understand but CXF has too many constraints like the need to support many
many different kind of deployments and uses, so I'm not really blaming
anyone here.
> Do we have a functional showcase app already? Can help building one if
> needed.
> Do you have an idea of where you want to land (in terms of config +
> deliverables)?
>
Yes, ok. So for OWB as an example, here's what I have:
- Use Tomcat 9.0.21.
- Add <Listener className="org.apache.tomcat.webbeans.OpenWebBeansListener"
optional="true" /> to the <Server> element in server.xml. If OWB is not
present, the missing dependency of the listener will be logged as INFO
(without causing further problems). The context listener can also be
configured in conf/context.xml and it would apply to all webapps, but I
prefer avoiding this if possible (it's more hidden).
- Add the JAR from tomcat-owb to the lib folder, then this should CDI
enable all webapps. One thing I'm not sure about yet is the separate
javax.* JARs, so let's ignore that "detail" for now ...
- The integration can also be used at the individual webapp level (as
before) using context.xml.
- It only uses Catalina components.
Does that look better to you ?
Getting there with CXF is harder.
> Answering both can be a way to move forward and see how we can converge.
> To complete David's answer, I kind of see that even without integrating
> some EE things in Tomcat itself, it can benefit to TomEE and enable it to
> align even more on Tomcat in terms of user facing configuration for
> instance.
>
Right.
Rémy
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mar. 11 juin 2019 à 21:22, Rémy Maucherat <re...@apache.org> a écrit :
>
>> Hi David,
>>
>> On Tue, Jun 11, 2019 at 8:37 PM David Blevins <da...@gmail.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> At a high level, is there a desire to start supporting more "EE" like
>>> specs such as CDI, JAX-RS, JPA, etc?
>>>
>>> Completely understood if the answer is "depends." I suspect it would
>>> depend on if the code is clean and light in Tomcat spirit.
>>>
>>
>> Ok, so the plan (my plan, actually) here is that I noticed CDI (and
>> JAX-RS) is the building block of many other APIs (like the Microprofile),
>> so there's a need to be able to use it in a "clean and light [and] in
>> Tomcat spirit" way (as you said). I had a look at OWB and CXF and while the
>> support is there, it needs some work (especially for the latter) and is
>> certainly not user friendly (again, esp for the latter). Note that the work
>> is also in Tomcat itself, since I'm in a good position to make changes and
>> improvements as needed.
>>
>> As for the answer, it would still be "no" at this point, since at most
>> these could be considered as a couple extra optional modules like the jdbc
>> pool, or maybe "build them yourself" poms.
>>
>>
>>>
>>> I write this not from the perspective of "let's move a bunch of TomEE
>>> code into Tomcat", but more of "let's write cleaner newer code in Tomcat
>>> and retire equivalent TomEE code."
>>>
>>> That's not a specific proposal, just curious if appetite has developed
>>> in recent years to entertain tip-toeing beyond the same set of specs.
>>>
>>
>> Rémy
>>
>>>
>>>
>>> --
>>> David Blevins
>>> http://twitter.com/dblevins
>>> http://www.tomitribe.com
>>>
>>> > On Jun 11, 2019, at 8:06 AM, Romain Manni-Bucau <rm...@gmail.com>
>>> wrote:
>>> >
>>> >
>>> >
>>> > Le mar. 11 juin 2019 à 16:57, Rémy Maucherat <re...@apache.org> a
>>> écrit :
>>> > On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <
>>> rmannibucau@gmail.com> wrote:
>>> >
>>> > Once done it can be hosted on both side.Owb has the advantage to be
>>> know by users, tomcat to be a more natural home for an integration. At the
>>> end it is mainly synchronizing both projects for a consistent communication
>>> and code "move" IMHO.
>>> >
>>> > For deep tomcat/cxf integration, you can use
>>> http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core
>>> module. Technically it uses an embedded flavor but it would be easy to move
>>> to a standalone one through a listener based on a small refactoring in
>>> Meecrowave#start. The good part are the lifecycle and scanning integrations
>>> + the tooling to make testing and dev simple -
>>> http://openwebbeans.apache.org/meecrowave/.
>>> >
>>> > Ok, I think things look reasonably good using CDI extensions (looking
>>> at the Geronimo mp implementation you did) except the default CXF "servlet"
>>> integration. I think right now the "servlet" integration from the
>>> cxf-rt-transports-http package is "bad" and that the one from Meecrowave
>>> (in org.apache.meecrowave.cxf) is more likely to be the way to go (it
>>> derives from cxf-integration-cdi).
>>> >
>>> > So this looks a lot closer to Meecrowave than I originally expected,
>>> with a lot of "buts" though:
>>> > - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal
>>> here is a "Meecrowave for Tomcat"
>>> >
>>> > Guess this one can converge - at least for TomEE it did and we have a
>>> tons of flavors, I dont see a blocker to unify it here to.
>>> >
>>> > - The JAR has all of Tomcat, log4j, API JARs, etc, while it should
>>> here be based off Tomcat, the javax APIs and OWB already present in the
>>> Tomcat OWB implementation JAR (the classic "tomcat7" or the modernized
>>> "tomcat-owb")
>>> >
>>> > The jar is just one flavor of meecrowave - assuming you reference the
>>> fatjar, you should still be able to use it as plain unitary dependencies.
>>> > The missing part here is to extract from Meecrowave master class all
>>> the logic to "glue" the stack in Tomcat (mainly extracting it in a Listener
>>> I guess and ignoring the specific launcher config?)
>>> >
>>> > - log4j would need to be removed as well
>>> >
>>> > It is already supported, in this IT we drop log4j, johnzon, cxf:
>>> https://github.com/apache/meecrowave/blob/trunk/integration-tests/no-cxf/pom.xml#L32
>>> >
>>> > - plenty of configuration files and options in the JARs, but I guess
>>> that's the way it is since all the subcomponents are so flexible
>>> >
>>> > Yep, but all are also settable from a listener or a centralized file,
>>> we are really free here.
>>> >
>>> >
>>> >
>>> >
>>> > More technically: openwebbeans does not need properties files you can
>>> pass Properties when you create the WebBeansContext, this is what tomee
>>> does. Same for cxf and its bus ;).
>>> >
>>> > Ok, I'll have a look at that, it's better than properties files (but
>>> similar).
>>> >
>>> > Biggest short term challenge is to align scanners but it is very
>>> doable, long term it is to drop big core jars in all 3 libs for smaller
>>> bundles ;).
>>> >
>>> > Ok.
>>> >
>>> > Feel free to shout if you need help or more precise pointers.
>>> >
>>> > Rémy
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
Re: CDI support improvements
Posted by Romain Manni-Bucau <rm...@gmail.com>.
My 2cts would be that we have the luck to be fully ASF here so each project
can likely get back its missing piece(s) and we stay overall consistent
instead of creating yet another fork in our beloved foundation (we already
have some concurrent servers or even jdbc pools which does not help much
user land).
@Rémy do you track the issues you encounter somewhere?
For instance "CXF is not user friendly" but once you have CDI you get CXF
set up just adding a servlet. Here, an initializer would have been friendly
but then you would encounter the servlet initializer ordering issue.
In other words I wonder if we can't cumulate our efforts instead of working
isolated and moreover if we can avoid to split the code and deliverables
more than necessary - sounds like overlapping will be very high without
more details.
Do we have a functional showcase app already? Can help building one if
needed.
Do you have an idea of where you want to land (in terms of config +
deliverables)?
Answering both can be a way to move forward and see how we can converge.
To complete David's answer, I kind of see that even without integrating
some EE things in Tomcat itself, it can benefit to TomEE and enable it to
align even more on Tomcat in terms of user facing configuration for
instance.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 11 juin 2019 à 21:22, Rémy Maucherat <re...@apache.org> a écrit :
> Hi David,
>
> On Tue, Jun 11, 2019 at 8:37 PM David Blevins <da...@gmail.com>
> wrote:
>
>> Hi All,
>>
>> At a high level, is there a desire to start supporting more "EE" like
>> specs such as CDI, JAX-RS, JPA, etc?
>>
>> Completely understood if the answer is "depends." I suspect it would
>> depend on if the code is clean and light in Tomcat spirit.
>>
>
> Ok, so the plan (my plan, actually) here is that I noticed CDI (and
> JAX-RS) is the building block of many other APIs (like the Microprofile),
> so there's a need to be able to use it in a "clean and light [and] in
> Tomcat spirit" way (as you said). I had a look at OWB and CXF and while the
> support is there, it needs some work (especially for the latter) and is
> certainly not user friendly (again, esp for the latter). Note that the work
> is also in Tomcat itself, since I'm in a good position to make changes and
> improvements as needed.
>
> As for the answer, it would still be "no" at this point, since at most
> these could be considered as a couple extra optional modules like the jdbc
> pool, or maybe "build them yourself" poms.
>
>
>>
>> I write this not from the perspective of "let's move a bunch of TomEE
>> code into Tomcat", but more of "let's write cleaner newer code in Tomcat
>> and retire equivalent TomEE code."
>>
>> That's not a specific proposal, just curious if appetite has developed in
>> recent years to entertain tip-toeing beyond the same set of specs.
>>
>
> Rémy
>
>>
>>
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>>
>> > On Jun 11, 2019, at 8:06 AM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>> >
>> >
>> >
>> > Le mar. 11 juin 2019 à 16:57, Rémy Maucherat <re...@apache.org> a écrit
>> :
>> > On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <
>> rmannibucau@gmail.com> wrote:
>> >
>> > Once done it can be hosted on both side.Owb has the advantage to be
>> know by users, tomcat to be a more natural home for an integration. At the
>> end it is mainly synchronizing both projects for a consistent communication
>> and code "move" IMHO.
>> >
>> > For deep tomcat/cxf integration, you can use
>> http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core
>> module. Technically it uses an embedded flavor but it would be easy to move
>> to a standalone one through a listener based on a small refactoring in
>> Meecrowave#start. The good part are the lifecycle and scanning integrations
>> + the tooling to make testing and dev simple -
>> http://openwebbeans.apache.org/meecrowave/.
>> >
>> > Ok, I think things look reasonably good using CDI extensions (looking
>> at the Geronimo mp implementation you did) except the default CXF "servlet"
>> integration. I think right now the "servlet" integration from the
>> cxf-rt-transports-http package is "bad" and that the one from Meecrowave
>> (in org.apache.meecrowave.cxf) is more likely to be the way to go (it
>> derives from cxf-integration-cdi).
>> >
>> > So this looks a lot closer to Meecrowave than I originally expected,
>> with a lot of "buts" though:
>> > - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal
>> here is a "Meecrowave for Tomcat"
>> >
>> > Guess this one can converge - at least for TomEE it did and we have a
>> tons of flavors, I dont see a blocker to unify it here to.
>> >
>> > - The JAR has all of Tomcat, log4j, API JARs, etc, while it should here
>> be based off Tomcat, the javax APIs and OWB already present in the Tomcat
>> OWB implementation JAR (the classic "tomcat7" or the modernized
>> "tomcat-owb")
>> >
>> > The jar is just one flavor of meecrowave - assuming you reference the
>> fatjar, you should still be able to use it as plain unitary dependencies.
>> > The missing part here is to extract from Meecrowave master class all
>> the logic to "glue" the stack in Tomcat (mainly extracting it in a Listener
>> I guess and ignoring the specific launcher config?)
>> >
>> > - log4j would need to be removed as well
>> >
>> > It is already supported, in this IT we drop log4j, johnzon, cxf:
>> https://github.com/apache/meecrowave/blob/trunk/integration-tests/no-cxf/pom.xml#L32
>> >
>> > - plenty of configuration files and options in the JARs, but I guess
>> that's the way it is since all the subcomponents are so flexible
>> >
>> > Yep, but all are also settable from a listener or a centralized file,
>> we are really free here.
>> >
>> >
>> >
>> >
>> > More technically: openwebbeans does not need properties files you can
>> pass Properties when you create the WebBeansContext, this is what tomee
>> does. Same for cxf and its bus ;).
>> >
>> > Ok, I'll have a look at that, it's better than properties files (but
>> similar).
>> >
>> > Biggest short term challenge is to align scanners but it is very
>> doable, long term it is to drop big core jars in all 3 libs for smaller
>> bundles ;).
>> >
>> > Ok.
>> >
>> > Feel free to shout if you need help or more precise pointers.
>> >
>> > Rémy
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
Re: CDI support improvements
Posted by Rémy Maucherat <re...@apache.org>.
Hi David,
On Tue, Jun 11, 2019 at 8:37 PM David Blevins <da...@gmail.com>
wrote:
> Hi All,
>
> At a high level, is there a desire to start supporting more "EE" like
> specs such as CDI, JAX-RS, JPA, etc?
>
> Completely understood if the answer is "depends." I suspect it would
> depend on if the code is clean and light in Tomcat spirit.
>
Ok, so the plan (my plan, actually) here is that I noticed CDI (and JAX-RS)
is the building block of many other APIs (like the Microprofile), so
there's a need to be able to use it in a "clean and light [and] in Tomcat
spirit" way (as you said). I had a look at OWB and CXF and while the
support is there, it needs some work (especially for the latter) and is
certainly not user friendly (again, esp for the latter). Note that the work
is also in Tomcat itself, since I'm in a good position to make changes and
improvements as needed.
As for the answer, it would still be "no" at this point, since at most
these could be considered as a couple extra optional modules like the jdbc
pool, or maybe "build them yourself" poms.
>
> I write this not from the perspective of "let's move a bunch of TomEE code
> into Tomcat", but more of "let's write cleaner newer code in Tomcat and
> retire equivalent TomEE code."
>
> That's not a specific proposal, just curious if appetite has developed in
> recent years to entertain tip-toeing beyond the same set of specs.
>
Rémy
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Jun 11, 2019, at 8:06 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> >
> >
> > Le mar. 11 juin 2019 à 16:57, Rémy Maucherat <re...@apache.org> a écrit :
> > On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
> >
> > Once done it can be hosted on both side.Owb has the advantage to be know
> by users, tomcat to be a more natural home for an integration. At the end
> it is mainly synchronizing both projects for a consistent communication and
> code "move" IMHO.
> >
> > For deep tomcat/cxf integration, you can use
> http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core
> module. Technically it uses an embedded flavor but it would be easy to move
> to a standalone one through a listener based on a small refactoring in
> Meecrowave#start. The good part are the lifecycle and scanning integrations
> + the tooling to make testing and dev simple -
> http://openwebbeans.apache.org/meecrowave/.
> >
> > Ok, I think things look reasonably good using CDI extensions (looking at
> the Geronimo mp implementation you did) except the default CXF "servlet"
> integration. I think right now the "servlet" integration from the
> cxf-rt-transports-http package is "bad" and that the one from Meecrowave
> (in org.apache.meecrowave.cxf) is more likely to be the way to go (it
> derives from cxf-integration-cdi).
> >
> > So this looks a lot closer to Meecrowave than I originally expected,
> with a lot of "buts" though:
> > - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal
> here is a "Meecrowave for Tomcat"
> >
> > Guess this one can converge - at least for TomEE it did and we have a
> tons of flavors, I dont see a blocker to unify it here to.
> >
> > - The JAR has all of Tomcat, log4j, API JARs, etc, while it should here
> be based off Tomcat, the javax APIs and OWB already present in the Tomcat
> OWB implementation JAR (the classic "tomcat7" or the modernized
> "tomcat-owb")
> >
> > The jar is just one flavor of meecrowave - assuming you reference the
> fatjar, you should still be able to use it as plain unitary dependencies.
> > The missing part here is to extract from Meecrowave master class all the
> logic to "glue" the stack in Tomcat (mainly extracting it in a Listener I
> guess and ignoring the specific launcher config?)
> >
> > - log4j would need to be removed as well
> >
> > It is already supported, in this IT we drop log4j, johnzon, cxf:
> https://github.com/apache/meecrowave/blob/trunk/integration-tests/no-cxf/pom.xml#L32
> >
> > - plenty of configuration files and options in the JARs, but I guess
> that's the way it is since all the subcomponents are so flexible
> >
> > Yep, but all are also settable from a listener or a centralized file, we
> are really free here.
> >
> >
> >
> >
> > More technically: openwebbeans does not need properties files you can
> pass Properties when you create the WebBeansContext, this is what tomee
> does. Same for cxf and its bus ;).
> >
> > Ok, I'll have a look at that, it's better than properties files (but
> similar).
> >
> > Biggest short term challenge is to align scanners but it is very doable,
> long term it is to drop big core jars in all 3 libs for smaller bundles ;).
> >
> > Ok.
> >
> > Feel free to shout if you need help or more precise pointers.
> >
> > Rémy
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: CDI support improvements
Posted by David Blevins <da...@gmail.com>.
Hi All,
At a high level, is there a desire to start supporting more "EE" like specs such as CDI, JAX-RS, JPA, etc?
Completely understood if the answer is "depends." I suspect it would depend on if the code is clean and light in Tomcat spirit.
I write this not from the perspective of "let's move a bunch of TomEE code into Tomcat", but more of "let's write cleaner newer code in Tomcat and retire equivalent TomEE code."
That's not a specific proposal, just curious if appetite has developed in recent years to entertain tip-toeing beyond the same set of specs.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Jun 11, 2019, at 8:06 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
>
>
> Le mar. 11 juin 2019 à 16:57, Rémy Maucherat <re...@apache.org> a écrit :
> On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Once done it can be hosted on both side.Owb has the advantage to be know by users, tomcat to be a more natural home for an integration. At the end it is mainly synchronizing both projects for a consistent communication and code "move" IMHO.
>
> For deep tomcat/cxf integration, you can use http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core module. Technically it uses an embedded flavor but it would be easy to move to a standalone one through a listener based on a small refactoring in Meecrowave#start. The good part are the lifecycle and scanning integrations + the tooling to make testing and dev simple - http://openwebbeans.apache.org/meecrowave/.
>
> Ok, I think things look reasonably good using CDI extensions (looking at the Geronimo mp implementation you did) except the default CXF "servlet" integration. I think right now the "servlet" integration from the cxf-rt-transports-http package is "bad" and that the one from Meecrowave (in org.apache.meecrowave.cxf) is more likely to be the way to go (it derives from cxf-integration-cdi).
>
> So this looks a lot closer to Meecrowave than I originally expected, with a lot of "buts" though:
> - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal here is a "Meecrowave for Tomcat"
>
> Guess this one can converge - at least for TomEE it did and we have a tons of flavors, I dont see a blocker to unify it here to.
>
> - The JAR has all of Tomcat, log4j, API JARs, etc, while it should here be based off Tomcat, the javax APIs and OWB already present in the Tomcat OWB implementation JAR (the classic "tomcat7" or the modernized "tomcat-owb")
>
> The jar is just one flavor of meecrowave - assuming you reference the fatjar, you should still be able to use it as plain unitary dependencies.
> The missing part here is to extract from Meecrowave master class all the logic to "glue" the stack in Tomcat (mainly extracting it in a Listener I guess and ignoring the specific launcher config?)
>
> - log4j would need to be removed as well
>
> It is already supported, in this IT we drop log4j, johnzon, cxf: https://github.com/apache/meecrowave/blob/trunk/integration-tests/no-cxf/pom.xml#L32
>
> - plenty of configuration files and options in the JARs, but I guess that's the way it is since all the subcomponents are so flexible
>
> Yep, but all are also settable from a listener or a centralized file, we are really free here.
>
>
>
>
> More technically: openwebbeans does not need properties files you can pass Properties when you create the WebBeansContext, this is what tomee does. Same for cxf and its bus ;).
>
> Ok, I'll have a look at that, it's better than properties files (but similar).
>
> Biggest short term challenge is to align scanners but it is very doable, long term it is to drop big core jars in all 3 libs for smaller bundles ;).
>
> Ok.
>
> Feel free to shout if you need help or more precise pointers.
>
> Rémy
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: CDI support improvements
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mar. 11 juin 2019 à 16:57, Rémy Maucherat <re...@apache.org> a écrit :
> On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>
>> Once done it can be hosted on both side.Owb has the advantage to be know
>> by users, tomcat to be a more natural home for an integration. At the end
>> it is mainly synchronizing both projects for a consistent communication and
>> code "move" IMHO.
>>
>> For deep tomcat/cxf integration, you can use
>> http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core
>> module. Technically it uses an embedded flavor but it would be easy to move
>> to a standalone one through a listener based on a small refactoring in
>> Meecrowave#start. The good part are the lifecycle and scanning integrations
>> + the tooling to make testing and dev simple -
>> http://openwebbeans.apache.org/meecrowave/.
>>
>
> Ok, I think things look reasonably good using CDI extensions (looking at
> the Geronimo mp implementation you did) except the default CXF "servlet"
> integration. I think right now the "servlet" integration from the
> cxf-rt-transports-http package is "bad" and that the one from Meecrowave
> (in org.apache.meecrowave.cxf) is more likely to be the way to go (it
> derives from cxf-integration-cdi).
>
> So this looks a lot closer to Meecrowave than I originally expected, with
> a lot of "buts" though:
> - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal here
> is a "Meecrowave for Tomcat"
>
Guess this one can converge - at least for TomEE it did and we have a tons
of flavors, I dont see a blocker to unify it here to.
> - The JAR has all of Tomcat, log4j, API JARs, etc, while it should here be
> based off Tomcat, the javax APIs and OWB already present in the Tomcat OWB
> implementation JAR (the classic "tomcat7" or the modernized "tomcat-owb")
>
The jar is just one flavor of meecrowave - assuming you reference the
fatjar, you should still be able to use it as plain unitary dependencies.
The missing part here is to extract from Meecrowave master class all the
logic to "glue" the stack in Tomcat (mainly extracting it in a Listener I
guess and ignoring the specific launcher config?)
> - log4j would need to be removed as well
>
It is already supported, in this IT we drop log4j, johnzon, cxf:
https://github.com/apache/meecrowave/blob/trunk/integration-tests/no-cxf/pom.xml#L32
> - plenty of configuration files and options in the JARs, but I guess
> that's the way it is since all the subcomponents are so flexible
>
Yep, but all are also settable from a listener or a centralized file, we
are really free here.
>
>
>>
>>
>>>> More technically: openwebbeans does not need properties files you can
>>>> pass Properties when you create the WebBeansContext, this is what tomee
>>>> does. Same for cxf and its bus ;).
>>>>
>>>
>>> Ok, I'll have a look at that, it's better than properties files (but
>>> similar).
>>>
>>
>>>> Biggest short term challenge is to align scanners but it is very
>>>> doable, long term it is to drop big core jars in all 3 libs for smaller
>>>> bundles ;).
>>>>
>>>
>>> Ok.
>>>
>>>>
>>>> Feel free to shout if you need help or more precise pointers.
>>>>
>>>
> Rémy
>
>