Re: CDI support improvements

[Romain Manni-Bucau]

Le lun. 17 juin 2019 à 16:17, Rémy Maucherat  a écrit :

> On Mon, Jun 17, 2019 at 10:52 AM Romain Manni-Bucau 
> 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  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

[Rémy Maucherat]

On Mon, Jun 17, 2019 at 10:52 AM Romain Manni-Bucau 
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

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 17 juin 2019 à 10:52, Romain Manni-Bucau  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  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le lun. 17 juin 2019 à 10:29, Rémy Maucherat  a écrit :
>
>> Hi Romain,
>>
>> On Thu, Jun 13, 2019 at 6:52 PM Romain Manni-Bucau 
>> 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 extends JsonbJaxrsProvider {}
>>>
>>> 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

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 17 juin 2019 à 10:29, Rémy Maucherat  a écrit :

> Hi Romain,
>
> On Thu, Jun 13, 2019 at 6:52 PM Romain Manni-Bucau 
> 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 extends JsonbJaxrsProvider {}
>>
>> 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

[Rémy Maucherat]

Hi Romain,

On Thu, Jun 13, 2019 at 6:52 PM Romain Manni-Bucau 
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 extends JsonbJaxrsProvider {}
>
> 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

[Rémy Maucherat]

On Thu, Jun 13, 2019 at 6:52 PM Romain Manni-Bucau 
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 extends JsonbJaxrsProvider {}
>
> 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

[Romain Manni-Bucau]

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 extends JsonbJaxrsProvider {}

Should be enough if it is the issue (or use delegation instead of
inheritance)

Le jeu. 13 juin 2019 à 18:45, Rémy Maucherat  a écrit :

> On Thu, Jun 13, 2019 at 5:31 PM Romain Manni-Bucau 
> 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  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>>
>>
>> Le jeu. 13 juin 2019 à 17:26, Rémy Maucherat  a écrit :
>>
>>> On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau <
>>> rmannibu...@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

[Rémy Maucherat]

On Thu, Jun 13, 2019 at 5:31 PM Romain Manni-Bucau 
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  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le jeu. 13 juin 2019 à 17:26, Rémy Maucherat  a écrit :
>
>> On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau 
>> 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

[Romain Manni-Bucau]

can you drop johnzon-jsonb (+-core + -mapper + jsonp and jsonb specs jars)
too?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 13 juin 2019 à 17:26, Rémy Maucherat  a écrit :

> On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau 
> 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

[Rémy Maucherat]

On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau 
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

[David Blevins]

> On Jun 12, 2019, at 6:35 AM, Rémy Maucherat  wrote:
> 
> On Wed, Jun 12, 2019 at 11:11 AM Mark Struberg  
> 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

[Romain Manni-Bucau]

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  a
écrit :

>
>
> > Am 12.06.2019 um 15:35 schrieb Rémy Maucherat :
> >
>
> > 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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: CDI support improvements

[Mark Struberg]

> Am 12.06.2019 um 15:35 schrieb Rémy Maucherat :
> 

> 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: CDI support improvements

[Rémy Maucherat]

On Wed, Jun 12, 2019 at 11:11 AM Mark Struberg 
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  >:
> >
> > Hell Rémy,
> >
> > I commented inline
> >
> > Le mar. 11 juin 2019 à 23:29, Rémy Maucherat  a écrit :
> > On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau <
> rmannibu...@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 

Re: CDI support improvements

[Mark Struberg]

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 :
> 
> Hell Rémy,
> 
> I commented inline
> 
> Le mar. 11 juin 2019 à 23:29, Rémy Maucherat  a écrit :
> On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau  
> 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 
> 

Re: CDI support improvements

[Rémy Maucherat]

On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau 
wrote:

> Hell Rémy,
>
> I commented inline
>
> Le mar. 11 juin 2019 à 23:29, Rémy Maucherat  a écrit :
>
>> On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau 
>> 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 

Re: CDI support improvements

[Romain Manni-Bucau]

Hell Rémy,

I commented inline

Le mar. 11 juin 2019 à 23:29, Rémy Maucherat  a écrit :

> On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau 
> 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

Re: CDI support improvements

[Rémy Maucherat]

On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau 
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  to the  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.

Re: CDI support improvements

[David Blevins]

> On Jun 11, 2019, at 12:02 PM, Mark Thomas  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  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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: CDI support improvements

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 11 juin 2019 à 21:22, Rémy Maucherat  a écrit :

> Hi David,
>
> On Tue, Jun 11, 2019 at 8:37 PM 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.
>>
>
> 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 
>> wrote:
>> >
>> >
>> >
>> > Le mar. 11 juin 2019 à 16:57, Rémy Maucherat  a écrit
>> :
>> > On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <
>> rmannibu...@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 

Re: CDI support improvements

[Rémy Maucherat]

Hi David,

On Tue, Jun 11, 2019 at 8:37 PM 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.
>

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 
> wrote:
> >
> >
> >
> > Le mar. 11 juin 2019 à 16:57, Rémy Maucherat  a écrit :
> > On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <
> rmannibu...@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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: CDI support improvements

[Mark Thomas]

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: CDI support improvements

[David Blevins]

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  wrote:
> 
> 
> 
> Le mar. 11 juin 2019 à 16:57, Rémy Maucherat  a écrit :
> On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau  
> 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: CDI support improvements

[Romain Manni-Bucau]

Le mar. 11 juin 2019 à 16:57, Rémy Maucherat  a écrit :

> On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau 
> 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
>
>

Re: CDI support improvements

[Rémy Maucherat]

On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau 
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

[Romain Manni-Bucau]

Hello Rémy,

Few precisions inline

Le jeu. 30 mai 2019 à 00:34, Rémy Maucherat  a écrit :

> Hi,
>
> On Wed, May 29, 2019 at 11:35 PM Romain Manni-Bucau 
> wrote:
>
>> Hi Rémy,
>>
>> Openwebbeans has a tomcat integration module - mainly standalone case,
>> and meecrowave subproject - embedded or ready to run fatjar. It looks like
>> it covers what you target. Where I am loosing track is why not improving
>> openwebbeans and forking the code in tomcat? At least i would expect to
>> discuss to move over tomcat the code on dev@owb - and I would support it
>> ;).
>>
>
> There's not a lot of code, so I don't call that a fork. The problem is
> that I need to make changes and adjustments in Tomcat, so in the end it
> can't be in owb. I used the code from webbeans-tomcat7, and didn't see any
> other modules (maybe you're referring to the ones in samples I just found).
>


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/.


>> 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
>
>>
>>
>> Le mer. 29 mai 2019 à 18:26, Rémy Maucherat  a écrit :
>>
>>> Hi,
>>>
>>> This was on my hackaton todo list, I guess I'm a bit late, but getting
>>> to it now ...
>>>
>>> CDI is the building brick for many other popular libraries and
>>> frameworks, including JAX-RS (Apache CXF), Eclipse Microprofile, etc.
>>> Looking at the CDI implementation from the ASF, I am not fully satisfied
>>> with the integration or packaging of OWB in the context of Tomcat. Since
>>> it's such an important building block, I wanted to do something about it
>>> and be able to have something that played better with Tomcat standalone, in
>>> addition to embedded (that is well covered !). As a result, I took on the
>>> task to take over the Tomcat(7 ;) ) integration that was in OWB.
>>>
>>> I'm working on it here: https://github.com/rmaucher/tomcat-owb
>>>
>>> The packaging is a big jar that is not done yet (the APIs would of
>>> course be separate JARs, but the goal is to have a big-OWB JAR tuned for
>>> Tomcat with the rest). Eventually if it works well enough, I would move it
>>> to https://github.com/apache/tomcat/tree/master/modules
>>>
>>> Note: I'm not a fan of the OWB configuration, it looks rather cryptic to
>>> me (properties files spread across all the JARs, I guess that's pluggable -
>>> even though it's not really needed here). I will look at that area for
>>> Tomcat specific improvements (the main listener could be used for
>>> configuration).
>>>
>>> Note 2: Apache CXF is quite the same first impression, when I download
>>> it I find a "lib/WHICH_JARS" file, which kind of says it all. So after OWB,
>>> it's possible there would be another tomcat-cxf module, which would be
>>> packaging only (I hope/expect the integration, which uses CDI and Servlets,
>>> will not need any real improvements).
>>>
>>> Comments ?
>>>
>>> Rémy
>>>
>>>

Re: CDI support improvements

[Rémy Maucherat]

Hi,

On Wed, May 29, 2019 at 11:35 PM Romain Manni-Bucau 
wrote:

> Hi Rémy,
>
> Openwebbeans has a tomcat integration module - mainly standalone case, and
> meecrowave subproject - embedded or ready to run fatjar. It looks like it
> covers what you target. Where I am loosing track is why not improving
> openwebbeans and forking the code in tomcat? At least i would expect to
> discuss to move over tomcat the code on dev@owb - and I would support it
> ;).
>

There's not a lot of code, so I don't call that a fork. The problem is that
I need to make changes and adjustments in Tomcat, so in the end it can't be
in owb. I used the code from webbeans-tomcat7, and didn't see any other
modules (maybe you're referring to the ones in samples I just found).

>
> 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

>
>
> Le mer. 29 mai 2019 à 18:26, Rémy Maucherat  a écrit :
>
>> Hi,
>>
>> This was on my hackaton todo list, I guess I'm a bit late, but getting to
>> it now ...
>>
>> CDI is the building brick for many other popular libraries and
>> frameworks, including JAX-RS (Apache CXF), Eclipse Microprofile, etc.
>> Looking at the CDI implementation from the ASF, I am not fully satisfied
>> with the integration or packaging of OWB in the context of Tomcat. Since
>> it's such an important building block, I wanted to do something about it
>> and be able to have something that played better with Tomcat standalone, in
>> addition to embedded (that is well covered !). As a result, I took on the
>> task to take over the Tomcat(7 ;) ) integration that was in OWB.
>>
>> I'm working on it here: https://github.com/rmaucher/tomcat-owb
>>
>> The packaging is a big jar that is not done yet (the APIs would of course
>> be separate JARs, but the goal is to have a big-OWB JAR tuned for Tomcat
>> with the rest). Eventually if it works well enough, I would move it to
>> https://github.com/apache/tomcat/tree/master/modules
>>
>> Note: I'm not a fan of the OWB configuration, it looks rather cryptic to
>> me (properties files spread across all the JARs, I guess that's pluggable -
>> even though it's not really needed here). I will look at that area for
>> Tomcat specific improvements (the main listener could be used for
>> configuration).
>>
>> Note 2: Apache CXF is quite the same first impression, when I download it
>> I find a "lib/WHICH_JARS" file, which kind of says it all. So after OWB,
>> it's possible there would be another tomcat-cxf module, which would be
>> packaging only (I hope/expect the integration, which uses CDI and Servlets,
>> will not need any real improvements).
>>
>> Comments ?
>>
>> Rémy
>>
>>

Re: CDI support improvements

[Romain Manni-Bucau]

Hi Rémy,

Openwebbeans has a tomcat integration module - mainly standalone case, and
meecrowave subproject - embedded or ready to run fatjar. It looks like it
covers what you target. Where I am loosing track is why not improving
openwebbeans and forking the code in tomcat? At least i would expect to
discuss to move over tomcat the code on dev@owb - and I would support it ;).

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 ;).

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 ;).

Feel free to shout if you need help or more precise pointers.


Le mer. 29 mai 2019 à 18:26, Rémy Maucherat  a écrit :

> Hi,
>
> This was on my hackaton todo list, I guess I'm a bit late, but getting to
> it now ...
>
> CDI is the building brick for many other popular libraries and frameworks,
> including JAX-RS (Apache CXF), Eclipse Microprofile, etc. Looking at the
> CDI implementation from the ASF, I am not fully satisfied with the
> integration or packaging of OWB in the context of Tomcat. Since it's such
> an important building block, I wanted to do something about it and be able
> to have something that played better with Tomcat standalone, in addition to
> embedded (that is well covered !). As a result, I took on the task to take
> over the Tomcat(7 ;) ) integration that was in OWB.
>
> I'm working on it here: https://github.com/rmaucher/tomcat-owb
>
> The packaging is a big jar that is not done yet (the APIs would of course
> be separate JARs, but the goal is to have a big-OWB JAR tuned for Tomcat
> with the rest). Eventually if it works well enough, I would move it to
> https://github.com/apache/tomcat/tree/master/modules
>
> Note: I'm not a fan of the OWB configuration, it looks rather cryptic to
> me (properties files spread across all the JARs, I guess that's pluggable -
> even though it's not really needed here). I will look at that area for
> Tomcat specific improvements (the main listener could be used for
> configuration).
>
> Note 2: Apache CXF is quite the same first impression, when I download it
> I find a "lib/WHICH_JARS" file, which kind of says it all. So after OWB,
> it's possible there would be another tomcat-cxf module, which would be
> packaging only (I hope/expect the integration, which uses CDI and Servlets,
> will not need any real improvements).
>
> Comments ?
>
> Rémy
>
>