You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@gmail.com> on 2020/09/04 02:39:26 UTC
New TomEE embedded/serverless prototype (was Re: 9 Years of Startup
times & Ideas for Improvement)
> On May 25, 2019, at 6:27 PM, David Blevins <da...@gmail.com> wrote:
>
> # Revisiting TomEE Embedded
>
> Already in the data, we can see 50% of our "new startup" time is extracting the server from the tar.gz. We could speed things up by 50% for our build and everyone's build, just by skipping that step.
>
> We have always had a TomEE Embedded distribution, but we've approached it with a completely different mindset than regular TomEE and therefore it has less functionality and simply could not complete with a TomEE zip.
>
> I believe we took a wrong turn at the start.
>
> In a plain Tomcat zip the server is started with an incredibly small classpath, basically just what is the bin/ dir. Tomcat will then load everything in the lib/ dir into a new classloader, grab a class from that new classloader and tell it to finish the job.
>
> It would be possible for us to write an "embedded" version that does exactly this, but using jars from the local Maven repo and would result in is being able to start stop many Tomcat/TomEE instances in one JVM. We would have a slightly different version of the Tomcat bootstrap jar, but everything after that point would be 100% the same. The embedded version would start 2x faster than a "remote" version but have the same functionality and cost us very little in terms of maintenance.
I've created a prototype of the above idea on a new embedded version of TomEE.
The concepts at the heart of it are:
- create a pom.xml for each server.zip that has a 1-to-1 mapping of every library in that zip
- create a bootstrapper based on `org.apache.catalina.startup.Bootstrap` that can bootstrap a server using the classpath created by that pom
- enjoy a server environment identical to the standalone zip, but running inside your JVM in an embedded or "serverless" fashion
See the following two docs for an overview of what it looks like:
- https://github.com/apache/tomee/tree/master/examples/serverless-tomee-webprofile#serverless-tomee-webprofile
- https://github.com/apache/tomee/tree/master/examples/serverless-builder#serverless-builder-api
Essentially there is a functional API that allows you to build an embedded server instance by passing in lambdas and method references that assist in the building. The approach still involves a very small number of config files in a temporary directory that represents the catalina.base.
Where many embedded/serverless APIs go wrong is taking the perspective that any kind of configuration file is bad. When this perspective is taken, users must learn an elaborate API, usually a DSL, to build every aspect of the server instance by hand.
The problem with this approach is that it takes an enormous effort to create these DSLs and get them to cover all possibilities in how a server can be configured. It sounds neat until you realize that you'd need a DSL to cover all the configuration files below:
- catalina.policy
- catalina.properties
- context.xml
- jaspic-providers.xml
- logging.properties
- server.xml
- system.properties
- tomcat-users.xml
- tomee.xml
- web.xml
The effort to cover all that and properly document it is high. The documentation required is also enormously high. And while it's all very neat, the amount of effort a user must spend to learn it all is also quite high.
And we go through all this effort as creators and users, just to get a version of the server we love that runs in our same VM as opposed to being a separate process.
If the goal is simply to get a Tomcat/TomEE running in your JVM so you can right a test case or serverless app, there is a shorter path.
When you boot Tomcat from the command line there is actually a very intentionally thin class called `Bootstrap` that does very little aside from constructing a ClassLoader out of the jars in lib/*.jar and bin/*.jar and then constructs an instance of `Catalina` and starts it. The real heavy lifting is done by Catalina from inside the newly constructed ClassLoader.
The groundbreaking idea is that the simplest possible version of a Tomcat embedded is just a version of Bootstrap with some of those steps removed.
When you take `Bootstrap` and pull out the classloader construction and the reflection needed to call `Catalina`, you really only have this code left:
- https://github.com/apache/tomee/blob/master/tomee/tomee-bootstrap/src/main/java/org/apache/tomee/bootstrap/Server.java#L239-L247
From there you really only have two challenges, 1) ensure the right jars are in the classpath and 2) ensure there are config files on disk somewhere Tomcat can find.
For challenge #1, the art of perfectly constructing a classpath that would be 100% identical to the corresponding Apache TomEE zip is actually a bit hard. The primary reason is Maven's transitive dependencies. To tackle this I wrote a tool that will extract a TomEE zip, analyze the libraries in it, map them back to Maven coordinates, then generate a pom.xml that includes *only* those jars with all transitive dependencies excluded.
The class that will do it is here (first link) and an example of its results are here (second link):
- https://github.com/apache/tomee/blob/master/tomee/tomee-bootstrap/src/test/java/org/apache/tomee/bootstrap/GenerateBoms.java
- https://github.com/apache/tomee/blob/master/boms/tomee-webprofile/pom.xml#L48-L1379
For challenge #2, we leverage the fact that Tomcat is already very happy to look anywhere for configuration files and webbaps. Tomcat has the concept of a home and a base. Home being where all the server libraries live and base being where the configuration and application lives. Instead of elaborate DSLs we simply create a very tiny catalina.base in a temp directory. To do that we just need to make adding and modifying files to that catalina.base a little easier. Here's where `Archive` enters the picture and effectively is a very tiny API that allows a directory structure to be built in memory.
- https://github.com/apache/tomee/blob/master/tomee/tomee-bootstrap/src/main/java/org/apache/tomee/bootstrap/Archive.java
Between the two it gets the job done.
This is beta quality at the moment, but looking great. There seems to be an issue getting the tomee-micorprofile, tomee-plus and tomee-plume version to work, however tomee-webprofile appears to be operating flawlessly.
I backported this to TomEE 7.0.x and there all distributions work perfectly. There seems to be something with our MicroProfile support that causes a CDI conflict on load. I'll post about this separately.
If you managed to make it to the end of this, let me know. :)
I suspect there's so much here people won't even know where to start with questions and likely I'll nothing from anyone. I'm truly happy to hear any feedback at all. It always feels great to hear people's thoughts and have discussion after a big coding bender.
Though I've documented it and tried to make it look polished, none of this is set in stone and there is ample room for rewrites, different ideas and big changes.
-David
Re: New TomEE embedded/serverless prototype (was Re: 9 Years of
Startup times & Ideas for Improvement)
Posted by David Blevins <da...@gmail.com>.
> On Sep 4, 2020, at 1:34 PM, David Blevins <da...@gmail.com> wrote:
>
>> On Sep 4, 2020, at 11:10 AM, Jonathan Gallimore <jo...@gmail.com> wrote:
>>
>> This is the specific part of the code where the Geronimo OpenAPI service is
>> filtered out:
>> https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/cdi/OptimizedLoaderService.java#L164-L165
>> .
>>
>> I hope that helps.
>
> It definitely did. I found a way to get it to pass. I don't know if there are other consequences.
>
> It's effectively these three lines of code (first link) added in this commit (second link)
>
> - https://github.com/apache/tomee/blob/142f035e454b43192c51db7a66b9395982502d47/container/openejb-core/src/main/java/org/apache/openejb/cdi/OptimizedLoaderService.java#L159-L161
> - https://github.com/apache/tomee/commit/1ebb0ee181622cd101df64a82f8af3bcb27211bf#diff-da64938534b0686bfc3d264149fac1f2R106-R108
>
> There's no test or javadoc and the commit message says its for jcache.
>
> I'm going to try to get the build green again and then yank.
>
Ok, yanked those lines and added in the MicroProfile, Plus and Plume examples. Build looks happy!
- https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8/builds/1426
These look good to go. From here I think it's just a matter of starting to use this more and more and see what if any issues arise.
Might be nice to have an Arquillian version and potentially deprecate/remove the old incomplete embedded adapter.
-David
Re: New TomEE embedded/serverless prototype (was Re: 9 Years of
Startup times & Ideas for Improvement)
Posted by David Blevins <da...@gmail.com>.
> On Sep 4, 2020, at 11:10 AM, Jonathan Gallimore <jo...@gmail.com> wrote:
>
> This is the specific part of the code where the Geronimo OpenAPI service is
> filtered out:
> https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/cdi/OptimizedLoaderService.java#L164-L165
> .
>
> I hope that helps.
It definitely did. I found a way to get it to pass. I don't know if there are other consequences.
It's effectively these three lines of code (first link) added in this commit (second link)
- https://github.com/apache/tomee/blob/142f035e454b43192c51db7a66b9395982502d47/container/openejb-core/src/main/java/org/apache/openejb/cdi/OptimizedLoaderService.java#L159-L161
- https://github.com/apache/tomee/commit/1ebb0ee181622cd101df64a82f8af3bcb27211bf#diff-da64938534b0686bfc3d264149fac1f2R106-R108
There's no test or javadoc and the commit message says its for jcache.
I'm going to try to get the build green again and then yank.
-David
>
> Jon
>
> On Fri, 4 Sep 2020, 18:40 David Blevins, <db...@tomitribe.com> wrote:
>
>> If the commit did have some means to handle the duplicate classes, it's
>> the exact insight I'm looking for even if it isn't working.
>>
>> Even knowing that there was something that was supposed to handle it is
>> useful as that means I just need to find what was supposed to work and then
>> figure out why it doesn't.
>>
>> If you didn't have to do anything at all and things just magically worked,
>> then the starting point is less clear.
>>
>>
>> -David
>>
>>> On Sep 4, 2020, at 10:12 AM, Jonathan Gallimore <
>> jonathan.gallimore@gmail.com> wrote:
>>>
>>> It definitely sounds like fun :)
>>>
>>> On Fri, 4 Sep 2020, 18:10 David Blevins, <db...@tomitribe.com> wrote:
>>>
>>>>
>>>>> On Sep 4, 2020, at 8:48 AM, Jonathan Gallimore <
>>>> jonathan.gallimore@gmail.com> wrote:
>>>>>
>>>>> Off the top of my head - I don't know. I'll run your test and dig
>> through
>>>>> over the weekend.
>>>>
>>>> No worries, I'll continue digging. I thought there might be a "I had
>> that
>>>> issue and did the thing with the thing, you probably need to adjust it."
>>>>
>>>> If nothing jumps out, no need to dig unless that sounds fun :)
>>>>
>>>>
>>>> -David
>>>>
>>>>
>>>>>
>>>>> On Fri, Sep 4, 2020 at 4:16 AM David Blevins <da...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Ok, so here's the error that keeps the TomEE MicroProfile, Plus and
>>>> Plume
>>>>>> examples from booting.
>>>>>>
>>>>>> It appears we get an AmbiguousResolutionException from OpenWebBeans
>>>>>> because we have these two beans getting picked up and they conflict
>> with
>>>>>> each other:
>>>>>>
>>>>>>
>>>>>> - TomEEOpenAPIExtension, WebBeansType:EXTENSION, Name:null, API
>>>>>> Types:[java.lang.Object,javax.enterprise.inject.spi.Extension,
>>>>>> org.apache.tomee.microprofile.config.TomEEOpenAPIExtension,
>>>>>>
>>>>>>
>> org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension],
>>>>>>
>>>>>>
>> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]
>>>>>> from
>>>>>>
>>>>>>
>>>>
>> jar:file:/Users/dblevins/.m2/repository/org/apache/tomee/mp-common/8.0.5-SNAPSHOT/mp-common-8.0.5-SNAPSHOT.jar
>>>>>>
>>>> !/org/apache/tomee/microprofile/config/TomEEOpenAPIExtension.class
>>>>>>
>>>>>>
>>>>>> - GeronimoOpenAPIExtension, WebBeansType:EXTENSION, Name:null, API
>>>>>> Types:[java.lang.Object,javax.enterprise.inject.spi.Extension,
>>>>>>
>>>>>>
>> org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension],
>>>>>>
>>>>>>
>> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]
>>>>>> from
>>>>>>
>>>>>>
>>>>
>> jar:file:/Users/dblevins/.m2/repository/org/apache/geronimo/geronimo-openapi-impl/1.0.12/geronimo-openapi-impl-1.0.12.jar
>>>>>>
>>>>>>
>>>>
>> !/org/apache/geronimo/microprofile/openapi/cdi/GeronimoOpenAPIExtension.class
>>>>>>
>>>>>>
>>>>>> It looks like TomEEOpenAPIExtension was added in this commit:
>>>>>>
>>>>>> -
>>>>>>
>>>>
>> https://github.com/apache/tomee/commit/10265708029ab2d0576f03aa1d5bb0a8a20bfffd
>>>>>>
>>>>>> Jon, looks like you added TomEEOpenAPIExtension. Is there any trick
>> you
>>>>>> needed to do to avoid the above conflict in our standalone servers?
>>>>>>
>>>>>> If anyone has any insight, it's very appreciated. This can be
>>>> reproduced
>>>>>> with this example:
>>>>>>
>>>>>> -
>>>>>>
>>>>
>> https://github.com/apache/tomee/tree/master/examples/serverless-tomee-microprofile
>>>>>>
>>>>>>
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: New TomEE embedded/serverless prototype (was Re: 9 Years of
Startup times & Ideas for Improvement)
Posted by Jonathan Gallimore <jo...@gmail.com>.
This is the specific part of the code where the Geronimo OpenAPI service is
filtered out:
https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/cdi/OptimizedLoaderService.java#L164-L165
.
I hope that helps. I'm happy to look at your test over the weekend.
Jon
On Fri, 4 Sep 2020, 18:40 David Blevins, <db...@tomitribe.com> wrote:
> If the commit did have some means to handle the duplicate classes, it's
> the exact insight I'm looking for even if it isn't working.
>
> Even knowing that there was something that was supposed to handle it is
> useful as that means I just need to find what was supposed to work and then
> figure out why it doesn't.
>
> If you didn't have to do anything at all and things just magically worked,
> then the starting point is less clear.
>
>
> -David
>
> > On Sep 4, 2020, at 10:12 AM, Jonathan Gallimore <
> jonathan.gallimore@gmail.com> wrote:
> >
> > It definitely sounds like fun :)
> >
> > On Fri, 4 Sep 2020, 18:10 David Blevins, <db...@tomitribe.com> wrote:
> >
> >>
> >>> On Sep 4, 2020, at 8:48 AM, Jonathan Gallimore <
> >> jonathan.gallimore@gmail.com> wrote:
> >>>
> >>> Off the top of my head - I don't know. I'll run your test and dig
> through
> >>> over the weekend.
> >>
> >> No worries, I'll continue digging. I thought there might be a "I had
> that
> >> issue and did the thing with the thing, you probably need to adjust it."
> >>
> >> If nothing jumps out, no need to dig unless that sounds fun :)
> >>
> >>
> >> -David
> >>
> >>
> >>>
> >>> On Fri, Sep 4, 2020 at 4:16 AM David Blevins <da...@gmail.com>
> >>> wrote:
> >>>
> >>>> Ok, so here's the error that keeps the TomEE MicroProfile, Plus and
> >> Plume
> >>>> examples from booting.
> >>>>
> >>>> It appears we get an AmbiguousResolutionException from OpenWebBeans
> >>>> because we have these two beans getting picked up and they conflict
> with
> >>>> each other:
> >>>>
> >>>>
> >>>> - TomEEOpenAPIExtension, WebBeansType:EXTENSION, Name:null, API
> >>>> Types:[java.lang.Object,javax.enterprise.inject.spi.Extension,
> >>>> org.apache.tomee.microprofile.config.TomEEOpenAPIExtension,
> >>>>
> >>>>
> org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension],
> >>>>
> >>>>
> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]
> >>>> from
> >>>>
> >>>>
> >>
> jar:file:/Users/dblevins/.m2/repository/org/apache/tomee/mp-common/8.0.5-SNAPSHOT/mp-common-8.0.5-SNAPSHOT.jar
> >>>>
> >> !/org/apache/tomee/microprofile/config/TomEEOpenAPIExtension.class
> >>>>
> >>>>
> >>>> - GeronimoOpenAPIExtension, WebBeansType:EXTENSION, Name:null, API
> >>>> Types:[java.lang.Object,javax.enterprise.inject.spi.Extension,
> >>>>
> >>>>
> org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension],
> >>>>
> >>>>
> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]
> >>>> from
> >>>>
> >>>>
> >>
> jar:file:/Users/dblevins/.m2/repository/org/apache/geronimo/geronimo-openapi-impl/1.0.12/geronimo-openapi-impl-1.0.12.jar
> >>>>
> >>>>
> >>
> !/org/apache/geronimo/microprofile/openapi/cdi/GeronimoOpenAPIExtension.class
> >>>>
> >>>>
> >>>> It looks like TomEEOpenAPIExtension was added in this commit:
> >>>>
> >>>> -
> >>>>
> >>
> https://github.com/apache/tomee/commit/10265708029ab2d0576f03aa1d5bb0a8a20bfffd
> >>>>
> >>>> Jon, looks like you added TomEEOpenAPIExtension. Is there any trick
> you
> >>>> needed to do to avoid the above conflict in our standalone servers?
> >>>>
> >>>> If anyone has any insight, it's very appreciated. This can be
> >> reproduced
> >>>> with this example:
> >>>>
> >>>> -
> >>>>
> >>
> https://github.com/apache/tomee/tree/master/examples/serverless-tomee-microprofile
> >>>>
> >>>>
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>
> >>
>
>
Re: New TomEE embedded/serverless prototype (was Re: 9 Years of
Startup times & Ideas for Improvement)
Posted by David Blevins <db...@tomitribe.com>.
If the commit did have some means to handle the duplicate classes, it's the exact insight I'm looking for even if it isn't working.
Even knowing that there was something that was supposed to handle it is useful as that means I just need to find what was supposed to work and then figure out why it doesn't.
If you didn't have to do anything at all and things just magically worked, then the starting point is less clear.
-David
> On Sep 4, 2020, at 10:12 AM, Jonathan Gallimore <jo...@gmail.com> wrote:
>
> It definitely sounds like fun :)
>
> On Fri, 4 Sep 2020, 18:10 David Blevins, <db...@tomitribe.com> wrote:
>
>>
>>> On Sep 4, 2020, at 8:48 AM, Jonathan Gallimore <
>> jonathan.gallimore@gmail.com> wrote:
>>>
>>> Off the top of my head - I don't know. I'll run your test and dig through
>>> over the weekend.
>>
>> No worries, I'll continue digging. I thought there might be a "I had that
>> issue and did the thing with the thing, you probably need to adjust it."
>>
>> If nothing jumps out, no need to dig unless that sounds fun :)
>>
>>
>> -David
>>
>>
>>>
>>> On Fri, Sep 4, 2020 at 4:16 AM David Blevins <da...@gmail.com>
>>> wrote:
>>>
>>>> Ok, so here's the error that keeps the TomEE MicroProfile, Plus and
>> Plume
>>>> examples from booting.
>>>>
>>>> It appears we get an AmbiguousResolutionException from OpenWebBeans
>>>> because we have these two beans getting picked up and they conflict with
>>>> each other:
>>>>
>>>>
>>>> - TomEEOpenAPIExtension, WebBeansType:EXTENSION, Name:null, API
>>>> Types:[java.lang.Object,javax.enterprise.inject.spi.Extension,
>>>> org.apache.tomee.microprofile.config.TomEEOpenAPIExtension,
>>>>
>>>> org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension],
>>>>
>>>> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]
>>>> from
>>>>
>>>>
>> jar:file:/Users/dblevins/.m2/repository/org/apache/tomee/mp-common/8.0.5-SNAPSHOT/mp-common-8.0.5-SNAPSHOT.jar
>>>>
>> !/org/apache/tomee/microprofile/config/TomEEOpenAPIExtension.class
>>>>
>>>>
>>>> - GeronimoOpenAPIExtension, WebBeansType:EXTENSION, Name:null, API
>>>> Types:[java.lang.Object,javax.enterprise.inject.spi.Extension,
>>>>
>>>> org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension],
>>>>
>>>> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]
>>>> from
>>>>
>>>>
>> jar:file:/Users/dblevins/.m2/repository/org/apache/geronimo/geronimo-openapi-impl/1.0.12/geronimo-openapi-impl-1.0.12.jar
>>>>
>>>>
>> !/org/apache/geronimo/microprofile/openapi/cdi/GeronimoOpenAPIExtension.class
>>>>
>>>>
>>>> It looks like TomEEOpenAPIExtension was added in this commit:
>>>>
>>>> -
>>>>
>> https://github.com/apache/tomee/commit/10265708029ab2d0576f03aa1d5bb0a8a20bfffd
>>>>
>>>> Jon, looks like you added TomEEOpenAPIExtension. Is there any trick you
>>>> needed to do to avoid the above conflict in our standalone servers?
>>>>
>>>> If anyone has any insight, it's very appreciated. This can be
>> reproduced
>>>> with this example:
>>>>
>>>> -
>>>>
>> https://github.com/apache/tomee/tree/master/examples/serverless-tomee-microprofile
>>>>
>>>>
>>>>
>>>> -David
>>>>
>>>>
>>
>>
Re: New TomEE embedded/serverless prototype (was Re: 9 Years of
Startup times & Ideas for Improvement)
Posted by Jonathan Gallimore <jo...@gmail.com>.
It definitely sounds like fun :)
On Fri, 4 Sep 2020, 18:10 David Blevins, <db...@tomitribe.com> wrote:
>
> > On Sep 4, 2020, at 8:48 AM, Jonathan Gallimore <
> jonathan.gallimore@gmail.com> wrote:
> >
> > Off the top of my head - I don't know. I'll run your test and dig through
> > over the weekend.
>
> No worries, I'll continue digging. I thought there might be a "I had that
> issue and did the thing with the thing, you probably need to adjust it."
>
> If nothing jumps out, no need to dig unless that sounds fun :)
>
>
> -David
>
>
> >
> > On Fri, Sep 4, 2020 at 4:16 AM David Blevins <da...@gmail.com>
> > wrote:
> >
> >> Ok, so here's the error that keeps the TomEE MicroProfile, Plus and
> Plume
> >> examples from booting.
> >>
> >> It appears we get an AmbiguousResolutionException from OpenWebBeans
> >> because we have these two beans getting picked up and they conflict with
> >> each other:
> >>
> >>
> >> - TomEEOpenAPIExtension, WebBeansType:EXTENSION, Name:null, API
> >> Types:[java.lang.Object,javax.enterprise.inject.spi.Extension,
> >> org.apache.tomee.microprofile.config.TomEEOpenAPIExtension,
> >>
> >> org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension],
> >>
> >> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]
> >> from
> >>
> >>
> jar:file:/Users/dblevins/.m2/repository/org/apache/tomee/mp-common/8.0.5-SNAPSHOT/mp-common-8.0.5-SNAPSHOT.jar
> >>
> !/org/apache/tomee/microprofile/config/TomEEOpenAPIExtension.class
> >>
> >>
> >> - GeronimoOpenAPIExtension, WebBeansType:EXTENSION, Name:null, API
> >> Types:[java.lang.Object,javax.enterprise.inject.spi.Extension,
> >>
> >> org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension],
> >>
> >> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]
> >> from
> >>
> >>
> jar:file:/Users/dblevins/.m2/repository/org/apache/geronimo/geronimo-openapi-impl/1.0.12/geronimo-openapi-impl-1.0.12.jar
> >>
> >>
> !/org/apache/geronimo/microprofile/openapi/cdi/GeronimoOpenAPIExtension.class
> >>
> >>
> >> It looks like TomEEOpenAPIExtension was added in this commit:
> >>
> >> -
> >>
> https://github.com/apache/tomee/commit/10265708029ab2d0576f03aa1d5bb0a8a20bfffd
> >>
> >> Jon, looks like you added TomEEOpenAPIExtension. Is there any trick you
> >> needed to do to avoid the above conflict in our standalone servers?
> >>
> >> If anyone has any insight, it's very appreciated. This can be
> reproduced
> >> with this example:
> >>
> >> -
> >>
> https://github.com/apache/tomee/tree/master/examples/serverless-tomee-microprofile
> >>
> >>
> >>
> >> -David
> >>
> >>
>
>
Re: New TomEE embedded/serverless prototype (was Re: 9 Years of
Startup times & Ideas for Improvement)
Posted by David Blevins <db...@tomitribe.com>.
> On Sep 4, 2020, at 8:48 AM, Jonathan Gallimore <jo...@gmail.com> wrote:
>
> Off the top of my head - I don't know. I'll run your test and dig through
> over the weekend.
No worries, I'll continue digging. I thought there might be a "I had that issue and did the thing with the thing, you probably need to adjust it."
If nothing jumps out, no need to dig unless that sounds fun :)
-David
>
> On Fri, Sep 4, 2020 at 4:16 AM David Blevins <da...@gmail.com>
> wrote:
>
>> Ok, so here's the error that keeps the TomEE MicroProfile, Plus and Plume
>> examples from booting.
>>
>> It appears we get an AmbiguousResolutionException from OpenWebBeans
>> because we have these two beans getting picked up and they conflict with
>> each other:
>>
>>
>> - TomEEOpenAPIExtension, WebBeansType:EXTENSION, Name:null, API
>> Types:[java.lang.Object,javax.enterprise.inject.spi.Extension,
>> org.apache.tomee.microprofile.config.TomEEOpenAPIExtension,
>>
>> org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension],
>>
>> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]
>> from
>>
>> jar:file:/Users/dblevins/.m2/repository/org/apache/tomee/mp-common/8.0.5-SNAPSHOT/mp-common-8.0.5-SNAPSHOT.jar
>> !/org/apache/tomee/microprofile/config/TomEEOpenAPIExtension.class
>>
>>
>> - GeronimoOpenAPIExtension, WebBeansType:EXTENSION, Name:null, API
>> Types:[java.lang.Object,javax.enterprise.inject.spi.Extension,
>>
>> org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension],
>>
>> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]
>> from
>>
>> jar:file:/Users/dblevins/.m2/repository/org/apache/geronimo/geronimo-openapi-impl/1.0.12/geronimo-openapi-impl-1.0.12.jar
>>
>> !/org/apache/geronimo/microprofile/openapi/cdi/GeronimoOpenAPIExtension.class
>>
>>
>> It looks like TomEEOpenAPIExtension was added in this commit:
>>
>> -
>> https://github.com/apache/tomee/commit/10265708029ab2d0576f03aa1d5bb0a8a20bfffd
>>
>> Jon, looks like you added TomEEOpenAPIExtension. Is there any trick you
>> needed to do to avoid the above conflict in our standalone servers?
>>
>> If anyone has any insight, it's very appreciated. This can be reproduced
>> with this example:
>>
>> -
>> https://github.com/apache/tomee/tree/master/examples/serverless-tomee-microprofile
>>
>>
>>
>> -David
>>
>>
Re: New TomEE embedded/serverless prototype (was Re: 9 Years of
Startup times & Ideas for Improvement)
Posted by Jonathan Gallimore <jo...@gmail.com>.
Off the top of my head - I don't know. I'll run your test and dig through
over the weekend.
Jon
On Fri, Sep 4, 2020 at 4:16 AM David Blevins <da...@gmail.com>
wrote:
> Ok, so here's the error that keeps the TomEE MicroProfile, Plus and Plume
> examples from booting.
>
> It appears we get an AmbiguousResolutionException from OpenWebBeans
> because we have these two beans getting picked up and they conflict with
> each other:
>
>
> - TomEEOpenAPIExtension, WebBeansType:EXTENSION, Name:null, API
> Types:[java.lang.Object,javax.enterprise.inject.spi.Extension,
> org.apache.tomee.microprofile.config.TomEEOpenAPIExtension,
>
> org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension],
>
> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]
> from
>
> jar:file:/Users/dblevins/.m2/repository/org/apache/tomee/mp-common/8.0.5-SNAPSHOT/mp-common-8.0.5-SNAPSHOT.jar
> !/org/apache/tomee/microprofile/config/TomEEOpenAPIExtension.class
>
>
> - GeronimoOpenAPIExtension, WebBeansType:EXTENSION, Name:null, API
> Types:[java.lang.Object,javax.enterprise.inject.spi.Extension,
>
> org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension],
>
> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]
> from
>
> jar:file:/Users/dblevins/.m2/repository/org/apache/geronimo/geronimo-openapi-impl/1.0.12/geronimo-openapi-impl-1.0.12.jar
>
> !/org/apache/geronimo/microprofile/openapi/cdi/GeronimoOpenAPIExtension.class
>
>
> It looks like TomEEOpenAPIExtension was added in this commit:
>
> -
> https://github.com/apache/tomee/commit/10265708029ab2d0576f03aa1d5bb0a8a20bfffd
>
> Jon, looks like you added TomEEOpenAPIExtension. Is there any trick you
> needed to do to avoid the above conflict in our standalone servers?
>
> If anyone has any insight, it's very appreciated. This can be reproduced
> with this example:
>
> -
> https://github.com/apache/tomee/tree/master/examples/serverless-tomee-microprofile
>
>
>
> -David
>
>
Re: New TomEE embedded/serverless prototype (was Re: 9 Years of
Startup times & Ideas for Improvement)
Posted by David Blevins <da...@gmail.com>.
Ok, so here's the error that keeps the TomEE MicroProfile, Plus and Plume examples from booting.
It appears we get an AmbiguousResolutionException from OpenWebBeans because we have these two beans getting picked up and they conflict with each other:
- TomEEOpenAPIExtension, WebBeansType:EXTENSION, Name:null, API
Types:[java.lang.Object,javax.enterprise.inject.spi.Extension,
org.apache.tomee.microprofile.config.TomEEOpenAPIExtension,
org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension],
Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]
from
jar:file:/Users/dblevins/.m2/repository/org/apache/tomee/mp-common/8.0.5-SNAPSHOT/mp-common-8.0.5-SNAPSHOT.jar
!/org/apache/tomee/microprofile/config/TomEEOpenAPIExtension.class
- GeronimoOpenAPIExtension, WebBeansType:EXTENSION, Name:null, API
Types:[java.lang.Object,javax.enterprise.inject.spi.Extension,
org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension],
Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]
from
jar:file:/Users/dblevins/.m2/repository/org/apache/geronimo/geronimo-openapi-impl/1.0.12/geronimo-openapi-impl-1.0.12.jar
!/org/apache/geronimo/microprofile/openapi/cdi/GeronimoOpenAPIExtension.class
It looks like TomEEOpenAPIExtension was added in this commit:
- https://github.com/apache/tomee/commit/10265708029ab2d0576f03aa1d5bb0a8a20bfffd
Jon, looks like you added TomEEOpenAPIExtension. Is there any trick you needed to do to avoid the above conflict in our standalone servers?
If anyone has any insight, it's very appreciated. This can be reproduced with this example:
- https://github.com/apache/tomee/tree/master/examples/serverless-tomee-microprofile
-David