On Wed, Jun 12, 2019 at 11:11 AM Mark Struberg <strub...@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 <rmannibu...@gmail.com
> >:
> >
> > Hell Rémy,
> >
> > I commented inline
> >
> > Le mar. 11 juin 2019 à 23:29, Rémy Maucherat <r...@apache.org> 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 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 <r...@apache.org> a écrit :
> > Hi David,
> >
> > On Tue, Jun 11, 2019 at 8:37 PM David Blevins <david.blev...@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 <rmannibu...@gmail.com>
> wrote:
> > >
> > >
> > >
> > > Le mar. 11 juin 2019 à 16:57, Rémy Maucherat <r...@apache.org> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Reply via email to