You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by "rzo1 (via GitHub)" <gi...@apache.org> on 2025/04/14 08:00:04 UTC
Re: [PR] Bump io.opentelemetry.instrumentation:opentelemetry-instrumentation-api from 1.20.2 to 2.15.0 (tomee)
rzo1 closed pull request #1890: Bump io.opentelemetry.instrumentation:opentelemetry-instrumentation-api from 1.20.2 to 2.15.0
URL: https://github.com/apache/tomee/pull/1890
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tomee.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume
Posted by Richard Zowalla <rz...@apache.org>.
Hi Jon,
Yep, I agree!
It looks like the conclusion from this discussion is that we’ll leave MP in TomEE as is .
What we still need to figure out is whether we want to remove an existing flavor (like MicroProfile or Web) and/or introduce a new one (something along the lines of Plus without MP) but that might be a new discussion.
An option for TomEE Plus/Plume would also be to ship with this system.property: otel.sdk.disabled=true
Gruß
Richard
> Am 22.04.2025 um 16:15 schrieb Jonathan Gallimore <jo...@gmail.com>:
>
> Thanks for the info - I prefer understanding the root issue. It doesn't
> seem "friendly" of the JDBC driver to do that, but I still don't think that
> we should rip MicroProfile out of TomEE to "fix" that behavior. I'd prefer
> to see what other options are available.
>
> Jon
>
> On Tue, Apr 22, 2025 at 3:01 PM Markus Jung <ju...@apache.org> wrote:
>
>> Hey Jon,
>>
>>
>> for example, this is what happens when you use the MySQL JDBC connector
>> in TomEE Microprofile without any opentelemetry configuration:
>>
>> 22-Apr-2025 06:19:05.253 SEVERE [main]
>> io.opentelemetry.api.GlobalOpenTelemetry.maybeAutoConfigureAndSetGlobal
>> Error automatically configuring OpenTelemetry SDK. OpenTelemetry will
>> not be enabled.
>> io.opentelemetry.sdk.autoconfigure.spi.ConfigurationException: OTLP
>> gRPC Metrics Exporter enabled but opentelemetry-exporter-otlp not found
>> on classpath. Make sure to add it as a dependency to enable this feature.
>> at
>>
>> io.opentelemetry.sdk.autoconfigure.ClasspathUtil.checkClassExists(ClasspathUtil.java:17)
>> at
>>
>> io.opentelemetry.sdk.autoconfigure.MetricExporterConfiguration.configureOtlpMetrics(MetricExporterConfiguration.java:114)
>> at
>>
>> io.opentelemetry.sdk.autoconfigure.MetricExporterConfiguration.configureExporter(MetricExporterConfiguration.java:47)
>> at
>>
>> io.opentelemetry.sdk.autoconfigure.MeterProviderConfiguration.lambda$configureMetricReaders$0(MeterProviderConfiguration.java:70)
>> at
>> java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
>> at java.base/java.util.Collections$2.tryAdvance(Unknown Source)
>> at java.base/java.util.Collections$2.forEachRemaining(Unknown
>> Source)
>> at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown
>> Source)
>> at
>> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
>> at
>> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown
>> Source)
>> at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown
>> Source)
>> at java.base/java.util.stream.ReferencePipeline.collect(Unknown
>> Source)
>> at
>>
>> io.opentelemetry.sdk.autoconfigure.MeterProviderConfiguration.configureMetricReaders(MeterProviderConfiguration.java:72)
>> at
>>
>> io.opentelemetry.sdk.autoconfigure.MeterProviderConfiguration.configureMeterProvider(MeterProviderConfiguration.java:46)
>> at
>>
>> io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdkBuilder.build(AutoConfiguredOpenTelemetrySdkBuilder.java:341)
>> at
>>
>> io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdk.initialize(AutoConfiguredOpenTelemetrySdk.java:31)
>> at
>> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown
>> Source)
>> at java.base/java.lang.reflect.Method.invoke(Unknown Source)
>> at
>>
>> io.opentelemetry.api.GlobalOpenTelemetry.maybeAutoConfigureAndSetGlobal(GlobalOpenTelemetry.java:224)
>> at
>> io.opentelemetry.api.GlobalOpenTelemetry.get(GlobalOpenTelemetry.java:72)
>> at
>> com.mysql.cj.otel.OpenTelemetryHandler.<init>(OpenTelemetryHandler.java:67)
>> at com.mysql.cj.NativeSession.<init>(NativeSession.java:124)
>>
>>
>> Thanks
>>
>> Markus
>>
>> On 22.04.25 15:50, Jonathan Gallimore wrote:
>>> I would not be in favor of removing MicroProfile from TomEE - it provided
>>> useful features and we've put effort into integrating them over the
>> years.
>>>
>>> What are the JDBC drivers that actively scan for OTEL libraries?
>>>
>>> Jon
>>>
>>> On Tue, Apr 22, 2025 at 1:57 PM Richard Zowalla <rz...@apache.org> wrote:
>>>
>>>> Hi JL,
>>>>
>>>> Thanks for your reply :)
>>>>
>>>> The challenge we're facing is that some third-party libraries—such as
>>>> certain JDBC drivers—actively scan for OTEL libraries and automatically
>>>> enable related features based on their presence. This scanning process
>>>> happens independently of TomEE.
>>>>
>>>> Are you considering some kind of classloader-level workaround that would
>>>> make the visibility of OTEL classes or JARs configurable, perhaps via a
>>>> flag or similar mechanism?
>>>>
>>>> I agree, that we can shift the discussion towards distribution (perhaps
>>>> adding a new one without MicroProfile + transient libs) to replace the
>> MP
>>>> flavour. The only diff between MP and Plus (atm) is the system property
>> to
>>>> disable/enable MP integration.
>>>>
>>>> Gruß
>>>>
>>>> Richard
>>>>
>>>>> Am 22.04.2025 um 14:40 schrieb Jean-Louis Monteiro <
>>>> jlmonteiro@tomitribe.com>:
>>>>> Hi Richard,
>>>>>
>>>>> Sorry for the late reply.
>>>>>
>>>>> In terms of distribution only, I somehow agree that the MicroProfile
>>>> flavor
>>>>> isn't probably too useful. I'm not sure about the webprofile. The most
>>>> used
>>>>> being PLUME or PLUS. So, getting rid of the microprofile flavor seems
>>>>> probably better to discuss.
>>>>>
>>>>> Microprofile itself should still be part of TomEE Plus/Plume. If we
>> want
>>>> to
>>>>> add an additional flag to disable the scanning for the few milliseconds
>>>>> saved, I'm ok, but I'd still keep a microprofile integration in TomEE
>> by
>>>>> default.
>>>>>
>>>>> --
>>>>> Jean-Louis Monteiro
>>>>> http://twitter.com/jlouismonteiro
>>>>> http://www.tomitribe.com
>>>>>
>>>>>
>>>>> On Thu, Apr 17, 2025 at 12:59 PM Richard Zowalla <rz...@apache.org>
>>>> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Thanks for the active and constructive discussion!
>>>>>>
>>>>>> To summarize, here are the key considerations raised so far:
>>>>>>
>>>>>> Balancing leaner distributions against offering full feature sets
>>>>>> out-of-the-box related to MicroProfile and EclipseLink / Mojarra vs
>>>> MyFaces
>>>>>> Technical concerns around startup time, image size, and library
>>>>>> compatibility (MyFaces vs Mojarra; OpenJPA vs EclipseLink / Hibernate)
>>>>>>
>>>>>> Possibility of rebranding or restructuring distributions for greater
>>>>>> clarity and flexibility
>>>>>>
>>>>>> EE11 is approaching, which may already introduce breaking changes — we
>>>>>> should be mindful of the impact of multiple disruptive changes across
>>>>>> versions like removing MP support in 10.x or 10.1.x
>>>>>>
>>>>>>
>>>>>>
>>>>>> A compromise would be to introduce a new, additional distribution
>>>> starting
>>>>>> with TomEE 10.1.x that excludes MicroProfile libraries by default.
>>>>>>
>>>>>> This would allow users who prefer a leaner runtime to benefit
>>>> immediately,
>>>>>> while keeping existing distributions unchanged for those relying on MP
>>>>>> support.
>>>>>>
>>>>>> It would also give us valuable community feedback ahead of any broader
>>>>>> decisions for TomEE 11 onwards (like streamlining the distributions as
>>>>>> Thomas suggested).
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Gruß
>>>>>>
>>>>>> Richard
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Am 15.04.2025 um 10:17 schrieb Richard Zowalla <rz...@apache.org>:
>>>>>>>
>>>>>>> Short clarifications:
>>>>>>>
>>>>>>> - This is _not_ a vote. It is a discussion thread to get opinions /
>>>>>> different views :-)
>>>>>>> - I am not the chair of TomEE ;-)
>>>>>>>
>>>>>>> On a technical note:
>>>>>>>
>>>>>>> - We would still deliver TomEE MicroProfile with all its features.
>>>>>>>
>>>>>>>> Am 15.04.2025 um 10:10 schrieb Alex The Rocker <
>> alex.m3tal@gmail.com
>>>>> :
>>>>>>>> Hello Richard,
>>>>>>>>
>>>>>>>> [-1] for removing Microprofile from OOB TomEE 10.*
>>>>>>>>
>>>>>>>> Indeed:
>>>>>>>> 1. From a semantic versionning standpoint, it is not possible to
>>>>>>>> introduce a breaking change, so the earliest possible release to do
>>>>>>>> such major change would be TomEE 11
>>>>>>>> 2. Competing applications servers (Payara, OpenLiberty, JBoss,...)
>>>>>>>> seem to have OOTB MicroProfile support
>>>>>>>> 3. MicroProfile is often quoted as "the incubator for potential new
>>>>>>>> specifications [of Jakarta EE...]" (quoted from
>>>>>>>>
>>>>
>> https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee
>>>>>> ).
>>>>>>>> This last point is the key reason why I disagree with removing
>>>>>>>> MicroProfile from TomEE: enthousiatics developers willing to take
>>>>>>>> advantage of those ahead-of-time features brought by MicroProfile
>> will
>>>>>>>> be less eager to use TomEE if MicroProfile isn't anymore part of it.
>>>>>>>> They most likely they'll fall into other application servers' hands.
>>>>>>>>
>>>>>>>> That said, I welcome your initiative to cast such vote : your are
>>>>>>>> playing your role as TomEE's PMC chairman, which is to inspire the
>>>>>>>> future of this great community, with the democratic way to exchange
>> on
>>>>>>>> ideas. I will love seeying counter-arguments to my reply, and I'm
>> sure
>>>>>>>> that the more answers this proposal will get (whatever the final
>>>>>>>> outcome will be), the healtiest TomEE community will be!
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alex
>>>>>>>>
>>>>>>>> Le lun. 14 avr. 2025 à 10:07, Richard Zowalla <rz...@apache.org> a
>>>>>> écrit :
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Starting with TomEE 10.0.x, we've included MicroProfile 6.0 along
>>>> with
>>>>>> all the necessary OpenTelemetry classes and libraries.
>>>>>>>>> From what I've seen, many libraries—such as JDBC
>>>> drivers—automatically
>>>>>> enable OTEL features when the relevant libraries are present on the
>>>>>> classpath, regardless of any MicroProfile configuration settings.
>>>>>>>>> This puts us in a tricky position: we’re often forced to stick with
>>>>>> older library versions because upgrading from MP 6.0 to 6.1 tends to
>>>>>> introduce breaking changes. Moreover, MP 7 can only be supported once
>>>> CXF
>>>>>> provides a compatible client, which is currently being targeted for
>>>> Jakarta
>>>>>> EE 11.
>>>>>>>>> Given this, I’d like to propose dropping the (de-activated)
>>>>>> MicroProfile support from the Web, Plus, and Plume
>>>> distributions—meaning we
>>>>>> would no longer include the MP-related JARs by default. Instead, we
>>>> could
>>>>>> offer an optional script-based approach (e.g., via a zip/tar.gz
>> package)
>>>>>> that users can apply to add the MicroProfile flavor to Web/Plus/Plume
>> as
>>>>>> needed.
>>>>>>>>> Since this would be a breaking change, we could aim to roll it out
>>>>>> starting with version 10.1.x.
>>>>>>>>> WDYT? Any thoughts?
>>>>>>>>>
>>>>>>>>> Gruß
>>>>>>>>> Richard
>>>>>>
>>>>
>>
Re: [DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume
Posted by Jonathan Gallimore <jo...@gmail.com>.
Thanks for the info - I prefer understanding the root issue. It doesn't
seem "friendly" of the JDBC driver to do that, but I still don't think that
we should rip MicroProfile out of TomEE to "fix" that behavior. I'd prefer
to see what other options are available.
Jon
On Tue, Apr 22, 2025 at 3:01 PM Markus Jung <ju...@apache.org> wrote:
> Hey Jon,
>
>
> for example, this is what happens when you use the MySQL JDBC connector
> in TomEE Microprofile without any opentelemetry configuration:
>
> 22-Apr-2025 06:19:05.253 SEVERE [main]
> io.opentelemetry.api.GlobalOpenTelemetry.maybeAutoConfigureAndSetGlobal
> Error automatically configuring OpenTelemetry SDK. OpenTelemetry will
> not be enabled.
> io.opentelemetry.sdk.autoconfigure.spi.ConfigurationException: OTLP
> gRPC Metrics Exporter enabled but opentelemetry-exporter-otlp not found
> on classpath. Make sure to add it as a dependency to enable this feature.
> at
>
> io.opentelemetry.sdk.autoconfigure.ClasspathUtil.checkClassExists(ClasspathUtil.java:17)
> at
>
> io.opentelemetry.sdk.autoconfigure.MetricExporterConfiguration.configureOtlpMetrics(MetricExporterConfiguration.java:114)
> at
>
> io.opentelemetry.sdk.autoconfigure.MetricExporterConfiguration.configureExporter(MetricExporterConfiguration.java:47)
> at
>
> io.opentelemetry.sdk.autoconfigure.MeterProviderConfiguration.lambda$configureMetricReaders$0(MeterProviderConfiguration.java:70)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
> at java.base/java.util.Collections$2.tryAdvance(Unknown Source)
> at java.base/java.util.Collections$2.forEachRemaining(Unknown
> Source)
> at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown
> Source)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown
> Source)
> at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown
> Source)
> at java.base/java.util.stream.ReferencePipeline.collect(Unknown
> Source)
> at
>
> io.opentelemetry.sdk.autoconfigure.MeterProviderConfiguration.configureMetricReaders(MeterProviderConfiguration.java:72)
> at
>
> io.opentelemetry.sdk.autoconfigure.MeterProviderConfiguration.configureMeterProvider(MeterProviderConfiguration.java:46)
> at
>
> io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdkBuilder.build(AutoConfiguredOpenTelemetrySdkBuilder.java:341)
> at
>
> io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdk.initialize(AutoConfiguredOpenTelemetrySdk.java:31)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown
> Source)
> at java.base/java.lang.reflect.Method.invoke(Unknown Source)
> at
>
> io.opentelemetry.api.GlobalOpenTelemetry.maybeAutoConfigureAndSetGlobal(GlobalOpenTelemetry.java:224)
> at
> io.opentelemetry.api.GlobalOpenTelemetry.get(GlobalOpenTelemetry.java:72)
> at
> com.mysql.cj.otel.OpenTelemetryHandler.<init>(OpenTelemetryHandler.java:67)
> at com.mysql.cj.NativeSession.<init>(NativeSession.java:124)
>
>
> Thanks
>
> Markus
>
> On 22.04.25 15:50, Jonathan Gallimore wrote:
> > I would not be in favor of removing MicroProfile from TomEE - it provided
> > useful features and we've put effort into integrating them over the
> years.
> >
> > What are the JDBC drivers that actively scan for OTEL libraries?
> >
> > Jon
> >
> > On Tue, Apr 22, 2025 at 1:57 PM Richard Zowalla <rz...@apache.org> wrote:
> >
> >> Hi JL,
> >>
> >> Thanks for your reply :)
> >>
> >> The challenge we're facing is that some third-party libraries—such as
> >> certain JDBC drivers—actively scan for OTEL libraries and automatically
> >> enable related features based on their presence. This scanning process
> >> happens independently of TomEE.
> >>
> >> Are you considering some kind of classloader-level workaround that would
> >> make the visibility of OTEL classes or JARs configurable, perhaps via a
> >> flag or similar mechanism?
> >>
> >> I agree, that we can shift the discussion towards distribution (perhaps
> >> adding a new one without MicroProfile + transient libs) to replace the
> MP
> >> flavour. The only diff between MP and Plus (atm) is the system property
> to
> >> disable/enable MP integration.
> >>
> >> Gruß
> >>
> >> Richard
> >>
> >>> Am 22.04.2025 um 14:40 schrieb Jean-Louis Monteiro <
> >> jlmonteiro@tomitribe.com>:
> >>> Hi Richard,
> >>>
> >>> Sorry for the late reply.
> >>>
> >>> In terms of distribution only, I somehow agree that the MicroProfile
> >> flavor
> >>> isn't probably too useful. I'm not sure about the webprofile. The most
> >> used
> >>> being PLUME or PLUS. So, getting rid of the microprofile flavor seems
> >>> probably better to discuss.
> >>>
> >>> Microprofile itself should still be part of TomEE Plus/Plume. If we
> want
> >> to
> >>> add an additional flag to disable the scanning for the few milliseconds
> >>> saved, I'm ok, but I'd still keep a microprofile integration in TomEE
> by
> >>> default.
> >>>
> >>> --
> >>> Jean-Louis Monteiro
> >>> http://twitter.com/jlouismonteiro
> >>> http://www.tomitribe.com
> >>>
> >>>
> >>> On Thu, Apr 17, 2025 at 12:59 PM Richard Zowalla <rz...@apache.org>
> >> wrote:
> >>>> Hi all,
> >>>>
> >>>> Thanks for the active and constructive discussion!
> >>>>
> >>>> To summarize, here are the key considerations raised so far:
> >>>>
> >>>> Balancing leaner distributions against offering full feature sets
> >>>> out-of-the-box related to MicroProfile and EclipseLink / Mojarra vs
> >> MyFaces
> >>>> Technical concerns around startup time, image size, and library
> >>>> compatibility (MyFaces vs Mojarra; OpenJPA vs EclipseLink / Hibernate)
> >>>>
> >>>> Possibility of rebranding or restructuring distributions for greater
> >>>> clarity and flexibility
> >>>>
> >>>> EE11 is approaching, which may already introduce breaking changes — we
> >>>> should be mindful of the impact of multiple disruptive changes across
> >>>> versions like removing MP support in 10.x or 10.1.x
> >>>>
> >>>>
> >>>>
> >>>> A compromise would be to introduce a new, additional distribution
> >> starting
> >>>> with TomEE 10.1.x that excludes MicroProfile libraries by default.
> >>>>
> >>>> This would allow users who prefer a leaner runtime to benefit
> >> immediately,
> >>>> while keeping existing distributions unchanged for those relying on MP
> >>>> support.
> >>>>
> >>>> It would also give us valuable community feedback ahead of any broader
> >>>> decisions for TomEE 11 onwards (like streamlining the distributions as
> >>>> Thomas suggested).
> >>>>
> >>>> WDYT?
> >>>>
> >>>> Gruß
> >>>>
> >>>> Richard
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Am 15.04.2025 um 10:17 schrieb Richard Zowalla <rz...@apache.org>:
> >>>>>
> >>>>> Short clarifications:
> >>>>>
> >>>>> - This is _not_ a vote. It is a discussion thread to get opinions /
> >>>> different views :-)
> >>>>> - I am not the chair of TomEE ;-)
> >>>>>
> >>>>> On a technical note:
> >>>>>
> >>>>> - We would still deliver TomEE MicroProfile with all its features.
> >>>>>
> >>>>>> Am 15.04.2025 um 10:10 schrieb Alex The Rocker <
> alex.m3tal@gmail.com
> >>> :
> >>>>>> Hello Richard,
> >>>>>>
> >>>>>> [-1] for removing Microprofile from OOB TomEE 10.*
> >>>>>>
> >>>>>> Indeed:
> >>>>>> 1. From a semantic versionning standpoint, it is not possible to
> >>>>>> introduce a breaking change, so the earliest possible release to do
> >>>>>> such major change would be TomEE 11
> >>>>>> 2. Competing applications servers (Payara, OpenLiberty, JBoss,...)
> >>>>>> seem to have OOTB MicroProfile support
> >>>>>> 3. MicroProfile is often quoted as "the incubator for potential new
> >>>>>> specifications [of Jakarta EE...]" (quoted from
> >>>>>>
> >>
> https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee
> >>>> ).
> >>>>>> This last point is the key reason why I disagree with removing
> >>>>>> MicroProfile from TomEE: enthousiatics developers willing to take
> >>>>>> advantage of those ahead-of-time features brought by MicroProfile
> will
> >>>>>> be less eager to use TomEE if MicroProfile isn't anymore part of it.
> >>>>>> They most likely they'll fall into other application servers' hands.
> >>>>>>
> >>>>>> That said, I welcome your initiative to cast such vote : your are
> >>>>>> playing your role as TomEE's PMC chairman, which is to inspire the
> >>>>>> future of this great community, with the democratic way to exchange
> on
> >>>>>> ideas. I will love seeying counter-arguments to my reply, and I'm
> sure
> >>>>>> that the more answers this proposal will get (whatever the final
> >>>>>> outcome will be), the healtiest TomEE community will be!
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Alex
> >>>>>>
> >>>>>> Le lun. 14 avr. 2025 à 10:07, Richard Zowalla <rz...@apache.org> a
> >>>> écrit :
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> Starting with TomEE 10.0.x, we've included MicroProfile 6.0 along
> >> with
> >>>> all the necessary OpenTelemetry classes and libraries.
> >>>>>>> From what I've seen, many libraries—such as JDBC
> >> drivers—automatically
> >>>> enable OTEL features when the relevant libraries are present on the
> >>>> classpath, regardless of any MicroProfile configuration settings.
> >>>>>>> This puts us in a tricky position: we’re often forced to stick with
> >>>> older library versions because upgrading from MP 6.0 to 6.1 tends to
> >>>> introduce breaking changes. Moreover, MP 7 can only be supported once
> >> CXF
> >>>> provides a compatible client, which is currently being targeted for
> >> Jakarta
> >>>> EE 11.
> >>>>>>> Given this, I’d like to propose dropping the (de-activated)
> >>>> MicroProfile support from the Web, Plus, and Plume
> >> distributions—meaning we
> >>>> would no longer include the MP-related JARs by default. Instead, we
> >> could
> >>>> offer an optional script-based approach (e.g., via a zip/tar.gz
> package)
> >>>> that users can apply to add the MicroProfile flavor to Web/Plus/Plume
> as
> >>>> needed.
> >>>>>>> Since this would be a breaking change, we could aim to roll it out
> >>>> starting with version 10.1.x.
> >>>>>>> WDYT? Any thoughts?
> >>>>>>>
> >>>>>>> Gruß
> >>>>>>> Richard
> >>>>
> >>
>
Re: [DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume
Posted by Markus Jung <ju...@apache.org>.
Hey Jon,
for example, this is what happens when you use the MySQL JDBC connector
in TomEE Microprofile without any opentelemetry configuration:
22-Apr-2025 06:19:05.253 SEVERE [main]
io.opentelemetry.api.GlobalOpenTelemetry.maybeAutoConfigureAndSetGlobal
Error automatically configuring OpenTelemetry SDK. OpenTelemetry will
not be enabled.
io.opentelemetry.sdk.autoconfigure.spi.ConfigurationException: OTLP
gRPC Metrics Exporter enabled but opentelemetry-exporter-otlp not found
on classpath. Make sure to add it as a dependency to enable this feature.
at
io.opentelemetry.sdk.autoconfigure.ClasspathUtil.checkClassExists(ClasspathUtil.java:17)
at
io.opentelemetry.sdk.autoconfigure.MetricExporterConfiguration.configureOtlpMetrics(MetricExporterConfiguration.java:114)
at
io.opentelemetry.sdk.autoconfigure.MetricExporterConfiguration.configureExporter(MetricExporterConfiguration.java:47)
at
io.opentelemetry.sdk.autoconfigure.MeterProviderConfiguration.lambda$configureMetricReaders$0(MeterProviderConfiguration.java:70)
at
java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
at java.base/java.util.Collections$2.tryAdvance(Unknown Source)
at java.base/java.util.Collections$2.forEachRemaining(Unknown
Source)
at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown
Source)
at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
at
java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown
Source)
at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown
Source)
at java.base/java.util.stream.ReferencePipeline.collect(Unknown
Source)
at
io.opentelemetry.sdk.autoconfigure.MeterProviderConfiguration.configureMetricReaders(MeterProviderConfiguration.java:72)
at
io.opentelemetry.sdk.autoconfigure.MeterProviderConfiguration.configureMeterProvider(MeterProviderConfiguration.java:46)
at
io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdkBuilder.build(AutoConfiguredOpenTelemetrySdkBuilder.java:341)
at
io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdk.initialize(AutoConfiguredOpenTelemetrySdk.java:31)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown
Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at
io.opentelemetry.api.GlobalOpenTelemetry.maybeAutoConfigureAndSetGlobal(GlobalOpenTelemetry.java:224)
at
io.opentelemetry.api.GlobalOpenTelemetry.get(GlobalOpenTelemetry.java:72)
at
com.mysql.cj.otel.OpenTelemetryHandler.<init>(OpenTelemetryHandler.java:67)
at com.mysql.cj.NativeSession.<init>(NativeSession.java:124)
Thanks
Markus
On 22.04.25 15:50, Jonathan Gallimore wrote:
> I would not be in favor of removing MicroProfile from TomEE - it provided
> useful features and we've put effort into integrating them over the years.
>
> What are the JDBC drivers that actively scan for OTEL libraries?
>
> Jon
>
> On Tue, Apr 22, 2025 at 1:57 PM Richard Zowalla <rz...@apache.org> wrote:
>
>> Hi JL,
>>
>> Thanks for your reply :)
>>
>> The challenge we're facing is that some third-party libraries—such as
>> certain JDBC drivers—actively scan for OTEL libraries and automatically
>> enable related features based on their presence. This scanning process
>> happens independently of TomEE.
>>
>> Are you considering some kind of classloader-level workaround that would
>> make the visibility of OTEL classes or JARs configurable, perhaps via a
>> flag or similar mechanism?
>>
>> I agree, that we can shift the discussion towards distribution (perhaps
>> adding a new one without MicroProfile + transient libs) to replace the MP
>> flavour. The only diff between MP and Plus (atm) is the system property to
>> disable/enable MP integration.
>>
>> Gruß
>>
>> Richard
>>
>>> Am 22.04.2025 um 14:40 schrieb Jean-Louis Monteiro <
>> jlmonteiro@tomitribe.com>:
>>> Hi Richard,
>>>
>>> Sorry for the late reply.
>>>
>>> In terms of distribution only, I somehow agree that the MicroProfile
>> flavor
>>> isn't probably too useful. I'm not sure about the webprofile. The most
>> used
>>> being PLUME or PLUS. So, getting rid of the microprofile flavor seems
>>> probably better to discuss.
>>>
>>> Microprofile itself should still be part of TomEE Plus/Plume. If we want
>> to
>>> add an additional flag to disable the scanning for the few milliseconds
>>> saved, I'm ok, but I'd still keep a microprofile integration in TomEE by
>>> default.
>>>
>>> --
>>> Jean-Louis Monteiro
>>> http://twitter.com/jlouismonteiro
>>> http://www.tomitribe.com
>>>
>>>
>>> On Thu, Apr 17, 2025 at 12:59 PM Richard Zowalla <rz...@apache.org>
>> wrote:
>>>> Hi all,
>>>>
>>>> Thanks for the active and constructive discussion!
>>>>
>>>> To summarize, here are the key considerations raised so far:
>>>>
>>>> Balancing leaner distributions against offering full feature sets
>>>> out-of-the-box related to MicroProfile and EclipseLink / Mojarra vs
>> MyFaces
>>>> Technical concerns around startup time, image size, and library
>>>> compatibility (MyFaces vs Mojarra; OpenJPA vs EclipseLink / Hibernate)
>>>>
>>>> Possibility of rebranding or restructuring distributions for greater
>>>> clarity and flexibility
>>>>
>>>> EE11 is approaching, which may already introduce breaking changes — we
>>>> should be mindful of the impact of multiple disruptive changes across
>>>> versions like removing MP support in 10.x or 10.1.x
>>>>
>>>>
>>>>
>>>> A compromise would be to introduce a new, additional distribution
>> starting
>>>> with TomEE 10.1.x that excludes MicroProfile libraries by default.
>>>>
>>>> This would allow users who prefer a leaner runtime to benefit
>> immediately,
>>>> while keeping existing distributions unchanged for those relying on MP
>>>> support.
>>>>
>>>> It would also give us valuable community feedback ahead of any broader
>>>> decisions for TomEE 11 onwards (like streamlining the distributions as
>>>> Thomas suggested).
>>>>
>>>> WDYT?
>>>>
>>>> Gruß
>>>>
>>>> Richard
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Am 15.04.2025 um 10:17 schrieb Richard Zowalla <rz...@apache.org>:
>>>>>
>>>>> Short clarifications:
>>>>>
>>>>> - This is _not_ a vote. It is a discussion thread to get opinions /
>>>> different views :-)
>>>>> - I am not the chair of TomEE ;-)
>>>>>
>>>>> On a technical note:
>>>>>
>>>>> - We would still deliver TomEE MicroProfile with all its features.
>>>>>
>>>>>> Am 15.04.2025 um 10:10 schrieb Alex The Rocker <alex.m3tal@gmail.com
>>> :
>>>>>> Hello Richard,
>>>>>>
>>>>>> [-1] for removing Microprofile from OOB TomEE 10.*
>>>>>>
>>>>>> Indeed:
>>>>>> 1. From a semantic versionning standpoint, it is not possible to
>>>>>> introduce a breaking change, so the earliest possible release to do
>>>>>> such major change would be TomEE 11
>>>>>> 2. Competing applications servers (Payara, OpenLiberty, JBoss,...)
>>>>>> seem to have OOTB MicroProfile support
>>>>>> 3. MicroProfile is often quoted as "the incubator for potential new
>>>>>> specifications [of Jakarta EE...]" (quoted from
>>>>>>
>> https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee
>>>> ).
>>>>>> This last point is the key reason why I disagree with removing
>>>>>> MicroProfile from TomEE: enthousiatics developers willing to take
>>>>>> advantage of those ahead-of-time features brought by MicroProfile will
>>>>>> be less eager to use TomEE if MicroProfile isn't anymore part of it.
>>>>>> They most likely they'll fall into other application servers' hands.
>>>>>>
>>>>>> That said, I welcome your initiative to cast such vote : your are
>>>>>> playing your role as TomEE's PMC chairman, which is to inspire the
>>>>>> future of this great community, with the democratic way to exchange on
>>>>>> ideas. I will love seeying counter-arguments to my reply, and I'm sure
>>>>>> that the more answers this proposal will get (whatever the final
>>>>>> outcome will be), the healtiest TomEE community will be!
>>>>>>
>>>>>> Thanks,
>>>>>> Alex
>>>>>>
>>>>>> Le lun. 14 avr. 2025 à 10:07, Richard Zowalla <rz...@apache.org> a
>>>> écrit :
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Starting with TomEE 10.0.x, we've included MicroProfile 6.0 along
>> with
>>>> all the necessary OpenTelemetry classes and libraries.
>>>>>>> From what I've seen, many libraries—such as JDBC
>> drivers—automatically
>>>> enable OTEL features when the relevant libraries are present on the
>>>> classpath, regardless of any MicroProfile configuration settings.
>>>>>>> This puts us in a tricky position: we’re often forced to stick with
>>>> older library versions because upgrading from MP 6.0 to 6.1 tends to
>>>> introduce breaking changes. Moreover, MP 7 can only be supported once
>> CXF
>>>> provides a compatible client, which is currently being targeted for
>> Jakarta
>>>> EE 11.
>>>>>>> Given this, I’d like to propose dropping the (de-activated)
>>>> MicroProfile support from the Web, Plus, and Plume
>> distributions—meaning we
>>>> would no longer include the MP-related JARs by default. Instead, we
>> could
>>>> offer an optional script-based approach (e.g., via a zip/tar.gz package)
>>>> that users can apply to add the MicroProfile flavor to Web/Plus/Plume as
>>>> needed.
>>>>>>> Since this would be a breaking change, we could aim to roll it out
>>>> starting with version 10.1.x.
>>>>>>> WDYT? Any thoughts?
>>>>>>>
>>>>>>> Gruß
>>>>>>> Richard
>>>>
>>
Re: [DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume
Posted by Richard Zowalla <rz...@apache.org>.
MySQL for example: https://github.com/mysql/mysql-connector-j/blob/release/9.x/src/main/core-impl/java/com/mysql/cj/otel/OpenTelemetryHandler.java#L48
> Am 22.04.2025 um 15:50 schrieb Jonathan Gallimore <jo...@gmail.com>:
>
> What are the JDBC drivers that actively scan for OTEL libraries?
Re: [DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume
Posted by Jonathan Gallimore <jo...@gmail.com>.
I would not be in favor of removing MicroProfile from TomEE - it provided
useful features and we've put effort into integrating them over the years.
What are the JDBC drivers that actively scan for OTEL libraries?
Jon
On Tue, Apr 22, 2025 at 1:57 PM Richard Zowalla <rz...@apache.org> wrote:
> Hi JL,
>
> Thanks for your reply :)
>
> The challenge we're facing is that some third-party libraries—such as
> certain JDBC drivers—actively scan for OTEL libraries and automatically
> enable related features based on their presence. This scanning process
> happens independently of TomEE.
>
> Are you considering some kind of classloader-level workaround that would
> make the visibility of OTEL classes or JARs configurable, perhaps via a
> flag or similar mechanism?
>
> I agree, that we can shift the discussion towards distribution (perhaps
> adding a new one without MicroProfile + transient libs) to replace the MP
> flavour. The only diff between MP and Plus (atm) is the system property to
> disable/enable MP integration.
>
> Gruß
>
> Richard
>
> > Am 22.04.2025 um 14:40 schrieb Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com>:
> >
> > Hi Richard,
> >
> > Sorry for the late reply.
> >
> > In terms of distribution only, I somehow agree that the MicroProfile
> flavor
> > isn't probably too useful. I'm not sure about the webprofile. The most
> used
> > being PLUME or PLUS. So, getting rid of the microprofile flavor seems
> > probably better to discuss.
> >
> > Microprofile itself should still be part of TomEE Plus/Plume. If we want
> to
> > add an additional flag to disable the scanning for the few milliseconds
> > saved, I'm ok, but I'd still keep a microprofile integration in TomEE by
> > default.
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Thu, Apr 17, 2025 at 12:59 PM Richard Zowalla <rz...@apache.org>
> wrote:
> >
> >> Hi all,
> >>
> >> Thanks for the active and constructive discussion!
> >>
> >> To summarize, here are the key considerations raised so far:
> >>
> >> Balancing leaner distributions against offering full feature sets
> >> out-of-the-box related to MicroProfile and EclipseLink / Mojarra vs
> MyFaces
> >>
> >> Technical concerns around startup time, image size, and library
> >> compatibility (MyFaces vs Mojarra; OpenJPA vs EclipseLink / Hibernate)
> >>
> >> Possibility of rebranding or restructuring distributions for greater
> >> clarity and flexibility
> >>
> >> EE11 is approaching, which may already introduce breaking changes — we
> >> should be mindful of the impact of multiple disruptive changes across
> >> versions like removing MP support in 10.x or 10.1.x
> >>
> >>
> >>
> >> A compromise would be to introduce a new, additional distribution
> starting
> >> with TomEE 10.1.x that excludes MicroProfile libraries by default.
> >>
> >> This would allow users who prefer a leaner runtime to benefit
> immediately,
> >> while keeping existing distributions unchanged for those relying on MP
> >> support.
> >>
> >> It would also give us valuable community feedback ahead of any broader
> >> decisions for TomEE 11 onwards (like streamlining the distributions as
> >> Thomas suggested).
> >>
> >> WDYT?
> >>
> >> Gruß
> >>
> >> Richard
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>> Am 15.04.2025 um 10:17 schrieb Richard Zowalla <rz...@apache.org>:
> >>>
> >>> Short clarifications:
> >>>
> >>> - This is _not_ a vote. It is a discussion thread to get opinions /
> >> different views :-)
> >>> - I am not the chair of TomEE ;-)
> >>>
> >>> On a technical note:
> >>>
> >>> - We would still deliver TomEE MicroProfile with all its features.
> >>>
> >>>> Am 15.04.2025 um 10:10 schrieb Alex The Rocker <alex.m3tal@gmail.com
> >:
> >>>>
> >>>> Hello Richard,
> >>>>
> >>>> [-1] for removing Microprofile from OOB TomEE 10.*
> >>>>
> >>>> Indeed:
> >>>> 1. From a semantic versionning standpoint, it is not possible to
> >>>> introduce a breaking change, so the earliest possible release to do
> >>>> such major change would be TomEE 11
> >>>> 2. Competing applications servers (Payara, OpenLiberty, JBoss,...)
> >>>> seem to have OOTB MicroProfile support
> >>>> 3. MicroProfile is often quoted as "the incubator for potential new
> >>>> specifications [of Jakarta EE...]" (quoted from
> >>>>
> >>
> https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee
> >> ).
> >>>>
> >>>> This last point is the key reason why I disagree with removing
> >>>> MicroProfile from TomEE: enthousiatics developers willing to take
> >>>> advantage of those ahead-of-time features brought by MicroProfile will
> >>>> be less eager to use TomEE if MicroProfile isn't anymore part of it.
> >>>> They most likely they'll fall into other application servers' hands.
> >>>>
> >>>> That said, I welcome your initiative to cast such vote : your are
> >>>> playing your role as TomEE's PMC chairman, which is to inspire the
> >>>> future of this great community, with the democratic way to exchange on
> >>>> ideas. I will love seeying counter-arguments to my reply, and I'm sure
> >>>> that the more answers this proposal will get (whatever the final
> >>>> outcome will be), the healtiest TomEE community will be!
> >>>>
> >>>> Thanks,
> >>>> Alex
> >>>>
> >>>> Le lun. 14 avr. 2025 à 10:07, Richard Zowalla <rz...@apache.org> a
> >> écrit :
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> Starting with TomEE 10.0.x, we've included MicroProfile 6.0 along
> with
> >> all the necessary OpenTelemetry classes and libraries.
> >>>>>
> >>>>> From what I've seen, many libraries—such as JDBC
> drivers—automatically
> >> enable OTEL features when the relevant libraries are present on the
> >> classpath, regardless of any MicroProfile configuration settings.
> >>>>>
> >>>>> This puts us in a tricky position: we’re often forced to stick with
> >> older library versions because upgrading from MP 6.0 to 6.1 tends to
> >> introduce breaking changes. Moreover, MP 7 can only be supported once
> CXF
> >> provides a compatible client, which is currently being targeted for
> Jakarta
> >> EE 11.
> >>>>>
> >>>>> Given this, I’d like to propose dropping the (de-activated)
> >> MicroProfile support from the Web, Plus, and Plume
> distributions—meaning we
> >> would no longer include the MP-related JARs by default. Instead, we
> could
> >> offer an optional script-based approach (e.g., via a zip/tar.gz package)
> >> that users can apply to add the MicroProfile flavor to Web/Plus/Plume as
> >> needed.
> >>>>>
> >>>>> Since this would be a breaking change, we could aim to roll it out
> >> starting with version 10.1.x.
> >>>>>
> >>>>> WDYT? Any thoughts?
> >>>>>
> >>>>> Gruß
> >>>>> Richard
> >>>
> >>
> >>
>
>
Re: [DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume
Posted by Richard Zowalla <rz...@apache.org>.
Hi JL,
Thanks for your reply :)
The challenge we're facing is that some third-party libraries—such as certain JDBC drivers—actively scan for OTEL libraries and automatically enable related features based on their presence. This scanning process happens independently of TomEE.
Are you considering some kind of classloader-level workaround that would make the visibility of OTEL classes or JARs configurable, perhaps via a flag or similar mechanism?
I agree, that we can shift the discussion towards distribution (perhaps adding a new one without MicroProfile + transient libs) to replace the MP flavour. The only diff between MP and Plus (atm) is the system property to disable/enable MP integration.
Gruß
Richard
> Am 22.04.2025 um 14:40 schrieb Jean-Louis Monteiro <jl...@tomitribe.com>:
>
> Hi Richard,
>
> Sorry for the late reply.
>
> In terms of distribution only, I somehow agree that the MicroProfile flavor
> isn't probably too useful. I'm not sure about the webprofile. The most used
> being PLUME or PLUS. So, getting rid of the microprofile flavor seems
> probably better to discuss.
>
> Microprofile itself should still be part of TomEE Plus/Plume. If we want to
> add an additional flag to disable the scanning for the few milliseconds
> saved, I'm ok, but I'd still keep a microprofile integration in TomEE by
> default.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Thu, Apr 17, 2025 at 12:59 PM Richard Zowalla <rz...@apache.org> wrote:
>
>> Hi all,
>>
>> Thanks for the active and constructive discussion!
>>
>> To summarize, here are the key considerations raised so far:
>>
>> Balancing leaner distributions against offering full feature sets
>> out-of-the-box related to MicroProfile and EclipseLink / Mojarra vs MyFaces
>>
>> Technical concerns around startup time, image size, and library
>> compatibility (MyFaces vs Mojarra; OpenJPA vs EclipseLink / Hibernate)
>>
>> Possibility of rebranding or restructuring distributions for greater
>> clarity and flexibility
>>
>> EE11 is approaching, which may already introduce breaking changes — we
>> should be mindful of the impact of multiple disruptive changes across
>> versions like removing MP support in 10.x or 10.1.x
>>
>>
>>
>> A compromise would be to introduce a new, additional distribution starting
>> with TomEE 10.1.x that excludes MicroProfile libraries by default.
>>
>> This would allow users who prefer a leaner runtime to benefit immediately,
>> while keeping existing distributions unchanged for those relying on MP
>> support.
>>
>> It would also give us valuable community feedback ahead of any broader
>> decisions for TomEE 11 onwards (like streamlining the distributions as
>> Thomas suggested).
>>
>> WDYT?
>>
>> Gruß
>>
>> Richard
>>
>>
>>
>>
>>
>>
>>
>>
>>> Am 15.04.2025 um 10:17 schrieb Richard Zowalla <rz...@apache.org>:
>>>
>>> Short clarifications:
>>>
>>> - This is _not_ a vote. It is a discussion thread to get opinions /
>> different views :-)
>>> - I am not the chair of TomEE ;-)
>>>
>>> On a technical note:
>>>
>>> - We would still deliver TomEE MicroProfile with all its features.
>>>
>>>> Am 15.04.2025 um 10:10 schrieb Alex The Rocker <al...@gmail.com>:
>>>>
>>>> Hello Richard,
>>>>
>>>> [-1] for removing Microprofile from OOB TomEE 10.*
>>>>
>>>> Indeed:
>>>> 1. From a semantic versionning standpoint, it is not possible to
>>>> introduce a breaking change, so the earliest possible release to do
>>>> such major change would be TomEE 11
>>>> 2. Competing applications servers (Payara, OpenLiberty, JBoss,...)
>>>> seem to have OOTB MicroProfile support
>>>> 3. MicroProfile is often quoted as "the incubator for potential new
>>>> specifications [of Jakarta EE...]" (quoted from
>>>>
>> https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee
>> ).
>>>>
>>>> This last point is the key reason why I disagree with removing
>>>> MicroProfile from TomEE: enthousiatics developers willing to take
>>>> advantage of those ahead-of-time features brought by MicroProfile will
>>>> be less eager to use TomEE if MicroProfile isn't anymore part of it.
>>>> They most likely they'll fall into other application servers' hands.
>>>>
>>>> That said, I welcome your initiative to cast such vote : your are
>>>> playing your role as TomEE's PMC chairman, which is to inspire the
>>>> future of this great community, with the democratic way to exchange on
>>>> ideas. I will love seeying counter-arguments to my reply, and I'm sure
>>>> that the more answers this proposal will get (whatever the final
>>>> outcome will be), the healtiest TomEE community will be!
>>>>
>>>> Thanks,
>>>> Alex
>>>>
>>>> Le lun. 14 avr. 2025 à 10:07, Richard Zowalla <rz...@apache.org> a
>> écrit :
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Starting with TomEE 10.0.x, we've included MicroProfile 6.0 along with
>> all the necessary OpenTelemetry classes and libraries.
>>>>>
>>>>> From what I've seen, many libraries—such as JDBC drivers—automatically
>> enable OTEL features when the relevant libraries are present on the
>> classpath, regardless of any MicroProfile configuration settings.
>>>>>
>>>>> This puts us in a tricky position: we’re often forced to stick with
>> older library versions because upgrading from MP 6.0 to 6.1 tends to
>> introduce breaking changes. Moreover, MP 7 can only be supported once CXF
>> provides a compatible client, which is currently being targeted for Jakarta
>> EE 11.
>>>>>
>>>>> Given this, I’d like to propose dropping the (de-activated)
>> MicroProfile support from the Web, Plus, and Plume distributions—meaning we
>> would no longer include the MP-related JARs by default. Instead, we could
>> offer an optional script-based approach (e.g., via a zip/tar.gz package)
>> that users can apply to add the MicroProfile flavor to Web/Plus/Plume as
>> needed.
>>>>>
>>>>> Since this would be a breaking change, we could aim to roll it out
>> starting with version 10.1.x.
>>>>>
>>>>> WDYT? Any thoughts?
>>>>>
>>>>> Gruß
>>>>> Richard
>>>
>>
>>
Re: [DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Hi Richard,
Sorry for the late reply.
In terms of distribution only, I somehow agree that the MicroProfile flavor
isn't probably too useful. I'm not sure about the webprofile. The most used
being PLUME or PLUS. So, getting rid of the microprofile flavor seems
probably better to discuss.
Microprofile itself should still be part of TomEE Plus/Plume. If we want to
add an additional flag to disable the scanning for the few milliseconds
saved, I'm ok, but I'd still keep a microprofile integration in TomEE by
default.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Thu, Apr 17, 2025 at 12:59 PM Richard Zowalla <rz...@apache.org> wrote:
> Hi all,
>
> Thanks for the active and constructive discussion!
>
> To summarize, here are the key considerations raised so far:
>
> Balancing leaner distributions against offering full feature sets
> out-of-the-box related to MicroProfile and EclipseLink / Mojarra vs MyFaces
>
> Technical concerns around startup time, image size, and library
> compatibility (MyFaces vs Mojarra; OpenJPA vs EclipseLink / Hibernate)
>
> Possibility of rebranding or restructuring distributions for greater
> clarity and flexibility
>
> EE11 is approaching, which may already introduce breaking changes — we
> should be mindful of the impact of multiple disruptive changes across
> versions like removing MP support in 10.x or 10.1.x
>
>
>
> A compromise would be to introduce a new, additional distribution starting
> with TomEE 10.1.x that excludes MicroProfile libraries by default.
>
> This would allow users who prefer a leaner runtime to benefit immediately,
> while keeping existing distributions unchanged for those relying on MP
> support.
>
> It would also give us valuable community feedback ahead of any broader
> decisions for TomEE 11 onwards (like streamlining the distributions as
> Thomas suggested).
>
> WDYT?
>
> Gruß
>
> Richard
>
>
>
>
>
>
>
>
> > Am 15.04.2025 um 10:17 schrieb Richard Zowalla <rz...@apache.org>:
> >
> > Short clarifications:
> >
> > - This is _not_ a vote. It is a discussion thread to get opinions /
> different views :-)
> > - I am not the chair of TomEE ;-)
> >
> > On a technical note:
> >
> > - We would still deliver TomEE MicroProfile with all its features.
> >
> >> Am 15.04.2025 um 10:10 schrieb Alex The Rocker <al...@gmail.com>:
> >>
> >> Hello Richard,
> >>
> >> [-1] for removing Microprofile from OOB TomEE 10.*
> >>
> >> Indeed:
> >> 1. From a semantic versionning standpoint, it is not possible to
> >> introduce a breaking change, so the earliest possible release to do
> >> such major change would be TomEE 11
> >> 2. Competing applications servers (Payara, OpenLiberty, JBoss,...)
> >> seem to have OOTB MicroProfile support
> >> 3. MicroProfile is often quoted as "the incubator for potential new
> >> specifications [of Jakarta EE...]" (quoted from
> >>
> https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee
> ).
> >>
> >> This last point is the key reason why I disagree with removing
> >> MicroProfile from TomEE: enthousiatics developers willing to take
> >> advantage of those ahead-of-time features brought by MicroProfile will
> >> be less eager to use TomEE if MicroProfile isn't anymore part of it.
> >> They most likely they'll fall into other application servers' hands.
> >>
> >> That said, I welcome your initiative to cast such vote : your are
> >> playing your role as TomEE's PMC chairman, which is to inspire the
> >> future of this great community, with the democratic way to exchange on
> >> ideas. I will love seeying counter-arguments to my reply, and I'm sure
> >> that the more answers this proposal will get (whatever the final
> >> outcome will be), the healtiest TomEE community will be!
> >>
> >> Thanks,
> >> Alex
> >>
> >> Le lun. 14 avr. 2025 à 10:07, Richard Zowalla <rz...@apache.org> a
> écrit :
> >>>
> >>> Hi all,
> >>>
> >>> Starting with TomEE 10.0.x, we've included MicroProfile 6.0 along with
> all the necessary OpenTelemetry classes and libraries.
> >>>
> >>> From what I've seen, many libraries—such as JDBC drivers—automatically
> enable OTEL features when the relevant libraries are present on the
> classpath, regardless of any MicroProfile configuration settings.
> >>>
> >>> This puts us in a tricky position: we’re often forced to stick with
> older library versions because upgrading from MP 6.0 to 6.1 tends to
> introduce breaking changes. Moreover, MP 7 can only be supported once CXF
> provides a compatible client, which is currently being targeted for Jakarta
> EE 11.
> >>>
> >>> Given this, I’d like to propose dropping the (de-activated)
> MicroProfile support from the Web, Plus, and Plume distributions—meaning we
> would no longer include the MP-related JARs by default. Instead, we could
> offer an optional script-based approach (e.g., via a zip/tar.gz package)
> that users can apply to add the MicroProfile flavor to Web/Plus/Plume as
> needed.
> >>>
> >>> Since this would be a breaking change, we could aim to roll it out
> starting with version 10.1.x.
> >>>
> >>> WDYT? Any thoughts?
> >>>
> >>> Gruß
> >>> Richard
> >
>
>
Re: [DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume
Posted by Richard Zowalla <rz...@apache.org>.
Hi all,
Thanks for the active and constructive discussion!
To summarize, here are the key considerations raised so far:
Balancing leaner distributions against offering full feature sets out-of-the-box related to MicroProfile and EclipseLink / Mojarra vs MyFaces
Technical concerns around startup time, image size, and library compatibility (MyFaces vs Mojarra; OpenJPA vs EclipseLink / Hibernate)
Possibility of rebranding or restructuring distributions for greater clarity and flexibility
EE11 is approaching, which may already introduce breaking changes — we should be mindful of the impact of multiple disruptive changes across versions like removing MP support in 10.x or 10.1.x
A compromise would be to introduce a new, additional distribution starting with TomEE 10.1.x that excludes MicroProfile libraries by default.
This would allow users who prefer a leaner runtime to benefit immediately, while keeping existing distributions unchanged for those relying on MP support.
It would also give us valuable community feedback ahead of any broader decisions for TomEE 11 onwards (like streamlining the distributions as Thomas suggested).
WDYT?
Gruß
Richard
> Am 15.04.2025 um 10:17 schrieb Richard Zowalla <rz...@apache.org>:
>
> Short clarifications:
>
> - This is _not_ a vote. It is a discussion thread to get opinions / different views :-)
> - I am not the chair of TomEE ;-)
>
> On a technical note:
>
> - We would still deliver TomEE MicroProfile with all its features.
>
>> Am 15.04.2025 um 10:10 schrieb Alex The Rocker <al...@gmail.com>:
>>
>> Hello Richard,
>>
>> [-1] for removing Microprofile from OOB TomEE 10.*
>>
>> Indeed:
>> 1. From a semantic versionning standpoint, it is not possible to
>> introduce a breaking change, so the earliest possible release to do
>> such major change would be TomEE 11
>> 2. Competing applications servers (Payara, OpenLiberty, JBoss,...)
>> seem to have OOTB MicroProfile support
>> 3. MicroProfile is often quoted as "the incubator for potential new
>> specifications [of Jakarta EE...]" (quoted from
>> https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee).
>>
>> This last point is the key reason why I disagree with removing
>> MicroProfile from TomEE: enthousiatics developers willing to take
>> advantage of those ahead-of-time features brought by MicroProfile will
>> be less eager to use TomEE if MicroProfile isn't anymore part of it.
>> They most likely they'll fall into other application servers' hands.
>>
>> That said, I welcome your initiative to cast such vote : your are
>> playing your role as TomEE's PMC chairman, which is to inspire the
>> future of this great community, with the democratic way to exchange on
>> ideas. I will love seeying counter-arguments to my reply, and I'm sure
>> that the more answers this proposal will get (whatever the final
>> outcome will be), the healtiest TomEE community will be!
>>
>> Thanks,
>> Alex
>>
>> Le lun. 14 avr. 2025 à 10:07, Richard Zowalla <rz...@apache.org> a écrit :
>>>
>>> Hi all,
>>>
>>> Starting with TomEE 10.0.x, we've included MicroProfile 6.0 along with all the necessary OpenTelemetry classes and libraries.
>>>
>>> From what I've seen, many libraries—such as JDBC drivers—automatically enable OTEL features when the relevant libraries are present on the classpath, regardless of any MicroProfile configuration settings.
>>>
>>> This puts us in a tricky position: we’re often forced to stick with older library versions because upgrading from MP 6.0 to 6.1 tends to introduce breaking changes. Moreover, MP 7 can only be supported once CXF provides a compatible client, which is currently being targeted for Jakarta EE 11.
>>>
>>> Given this, I’d like to propose dropping the (de-activated) MicroProfile support from the Web, Plus, and Plume distributions—meaning we would no longer include the MP-related JARs by default. Instead, we could offer an optional script-based approach (e.g., via a zip/tar.gz package) that users can apply to add the MicroProfile flavor to Web/Plus/Plume as needed.
>>>
>>> Since this would be a breaking change, we could aim to roll it out starting with version 10.1.x.
>>>
>>> WDYT? Any thoughts?
>>>
>>> Gruß
>>> Richard
>
Re: [DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume
Posted by Thomas Andraschko <an...@gmail.com>.
IMO we should deliver it as many people using containers (docker,
kubernetes, ...) and then microprofile health is "almost required".
Maybe we should just rethink which distros we build per default.
IMO we might not even need Plume or Webprofile.
Webprofile just safes around 10mb. Im not sure if anyone cares about 10mb
today. If the startup time is much slower, thats what is interesting here.
We would need to check the difference.
The difference of Plume is that it delivers EclipseLink and Mojarra. Why do
we have this - because to allow users easily migrate to TomEE. Did this
ever happen?
- MyFaces is more stable as Mojarra - we are just not bug compatible, this
prevents users from using MyFaces as they dont want to fix their code.
- EclipseLink is more up2date and more widely used as OpenJPA. Maybe this
argument is not valid anymore if we would just deliver EclipseLink or
Hibernate per default, which is now possible with the license change. I
have never seen anyone using TomEE with JPA, but not replacing OpenJPA by
Hibernate or EclipseLink.
Maybe we can just have 2 profiles:
TomEE (Full + MicroProfile)
TomEE Lite (Full without Microprofile)
We can easily add some docs where users can e.g. replace Hibernate with
EclipseLink or just remove unused impls; but not deliver it as own distro.
Am Di., 15. Apr. 2025 um 10:17 Uhr schrieb Richard Zowalla <rzo1@apache.org
>:
> Short clarifications:
>
> - This is _not_ a vote. It is a discussion thread to get opinions /
> different views :-)
> - I am not the chair of TomEE ;-)
>
> On a technical note:
>
> - We would still deliver TomEE MicroProfile with all its features.
>
> > Am 15.04.2025 um 10:10 schrieb Alex The Rocker <al...@gmail.com>:
> >
> > Hello Richard,
> >
> > [-1] for removing Microprofile from OOB TomEE 10.*
> >
> > Indeed:
> > 1. From a semantic versionning standpoint, it is not possible to
> > introduce a breaking change, so the earliest possible release to do
> > such major change would be TomEE 11
> > 2. Competing applications servers (Payara, OpenLiberty, JBoss,...)
> > seem to have OOTB MicroProfile support
> > 3. MicroProfile is often quoted as "the incubator for potential new
> > specifications [of Jakarta EE...]" (quoted from
> >
> https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee
> ).
> >
> > This last point is the key reason why I disagree with removing
> > MicroProfile from TomEE: enthousiatics developers willing to take
> > advantage of those ahead-of-time features brought by MicroProfile will
> > be less eager to use TomEE if MicroProfile isn't anymore part of it.
> > They most likely they'll fall into other application servers' hands.
> >
> > That said, I welcome your initiative to cast such vote : your are
> > playing your role as TomEE's PMC chairman, which is to inspire the
> > future of this great community, with the democratic way to exchange on
> > ideas. I will love seeying counter-arguments to my reply, and I'm sure
> > that the more answers this proposal will get (whatever the final
> > outcome will be), the healtiest TomEE community will be!
> >
> > Thanks,
> > Alex
> >
> > Le lun. 14 avr. 2025 à 10:07, Richard Zowalla <rz...@apache.org> a écrit
> :
> >>
> >> Hi all,
> >>
> >> Starting with TomEE 10.0.x, we've included MicroProfile 6.0 along with
> all the necessary OpenTelemetry classes and libraries.
> >>
> >> From what I've seen, many libraries—such as JDBC drivers—automatically
> enable OTEL features when the relevant libraries are present on the
> classpath, regardless of any MicroProfile configuration settings.
> >>
> >> This puts us in a tricky position: we’re often forced to stick with
> older library versions because upgrading from MP 6.0 to 6.1 tends to
> introduce breaking changes. Moreover, MP 7 can only be supported once CXF
> provides a compatible client, which is currently being targeted for Jakarta
> EE 11.
> >>
> >> Given this, I’d like to propose dropping the (de-activated)
> MicroProfile support from the Web, Plus, and Plume distributions—meaning we
> would no longer include the MP-related JARs by default. Instead, we could
> offer an optional script-based approach (e.g., via a zip/tar.gz package)
> that users can apply to add the MicroProfile flavor to Web/Plus/Plume as
> needed.
> >>
> >> Since this would be a breaking change, we could aim to roll it out
> starting with version 10.1.x.
> >>
> >> WDYT? Any thoughts?
> >>
> >> Gruß
> >> Richard
>
>
Re: [DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume
Posted by Richard Zowalla <rz...@apache.org>.
Short clarifications:
- This is _not_ a vote. It is a discussion thread to get opinions / different views :-)
- I am not the chair of TomEE ;-)
On a technical note:
- We would still deliver TomEE MicroProfile with all its features.
> Am 15.04.2025 um 10:10 schrieb Alex The Rocker <al...@gmail.com>:
>
> Hello Richard,
>
> [-1] for removing Microprofile from OOB TomEE 10.*
>
> Indeed:
> 1. From a semantic versionning standpoint, it is not possible to
> introduce a breaking change, so the earliest possible release to do
> such major change would be TomEE 11
> 2. Competing applications servers (Payara, OpenLiberty, JBoss,...)
> seem to have OOTB MicroProfile support
> 3. MicroProfile is often quoted as "the incubator for potential new
> specifications [of Jakarta EE...]" (quoted from
> https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee).
>
> This last point is the key reason why I disagree with removing
> MicroProfile from TomEE: enthousiatics developers willing to take
> advantage of those ahead-of-time features brought by MicroProfile will
> be less eager to use TomEE if MicroProfile isn't anymore part of it.
> They most likely they'll fall into other application servers' hands.
>
> That said, I welcome your initiative to cast such vote : your are
> playing your role as TomEE's PMC chairman, which is to inspire the
> future of this great community, with the democratic way to exchange on
> ideas. I will love seeying counter-arguments to my reply, and I'm sure
> that the more answers this proposal will get (whatever the final
> outcome will be), the healtiest TomEE community will be!
>
> Thanks,
> Alex
>
> Le lun. 14 avr. 2025 à 10:07, Richard Zowalla <rz...@apache.org> a écrit :
>>
>> Hi all,
>>
>> Starting with TomEE 10.0.x, we've included MicroProfile 6.0 along with all the necessary OpenTelemetry classes and libraries.
>>
>> From what I've seen, many libraries—such as JDBC drivers—automatically enable OTEL features when the relevant libraries are present on the classpath, regardless of any MicroProfile configuration settings.
>>
>> This puts us in a tricky position: we’re often forced to stick with older library versions because upgrading from MP 6.0 to 6.1 tends to introduce breaking changes. Moreover, MP 7 can only be supported once CXF provides a compatible client, which is currently being targeted for Jakarta EE 11.
>>
>> Given this, I’d like to propose dropping the (de-activated) MicroProfile support from the Web, Plus, and Plume distributions—meaning we would no longer include the MP-related JARs by default. Instead, we could offer an optional script-based approach (e.g., via a zip/tar.gz package) that users can apply to add the MicroProfile flavor to Web/Plus/Plume as needed.
>>
>> Since this would be a breaking change, we could aim to roll it out starting with version 10.1.x.
>>
>> WDYT? Any thoughts?
>>
>> Gruß
>> Richard
Re: [DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Hi Alex!
> 3. MicroProfile is often quoted as "the incubator for potential new
> specifications [of Jakarta EE...]" (quoted from
> https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee).
I know, but it was proven wrong many moons ago. MicroProfile is just a different set of 'specs' with the credo of 'move fast and break things' - and boy we did break things :(
There are a few good parts in mp, but all of them can also be added portably imo. The only bit more tricky part might be the JWT integration, isn't?
Also please note that a PMC chair is only kind of a 'secretary' role. It doesn't cary more rights than any other PMC member. Usually we also don't even make a difference between PMC member, committer and contributor - what counts is the argument itself ;)
LieGrue,
strub
> Am 15.04.2025 um 10:10 schrieb Alex The Rocker <al...@gmail.com>:
>
> Hello Richard,
>
> [-1] for removing Microprofile from OOB TomEE 10.*
>
> Indeed:
> 1. From a semantic versionning standpoint, it is not possible to
> introduce a breaking change, so the earliest possible release to do
> such major change would be TomEE 11
> 2. Competing applications servers (Payara, OpenLiberty, JBoss,...)
> seem to have OOTB MicroProfile support
> 3. MicroProfile is often quoted as "the incubator for potential new
> specifications [of Jakarta EE...]" (quoted from
> https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee).
>
> This last point is the key reason why I disagree with removing
> MicroProfile from TomEE: enthousiatics developers willing to take
> advantage of those ahead-of-time features brought by MicroProfile will
> be less eager to use TomEE if MicroProfile isn't anymore part of it.
> They most likely they'll fall into other application servers' hands.
>
> That said, I welcome your initiative to cast such vote : your are
> playing your role as TomEE's PMC chairman, which is to inspire the
> future of this great community, with the democratic way to exchange on
> ideas. I will love seeying counter-arguments to my reply, and I'm sure
> that the more answers this proposal will get (whatever the final
> outcome will be), the healtiest TomEE community will be!
>
> Thanks,
> Alex
>
> Le lun. 14 avr. 2025 à 10:07, Richard Zowalla <rz...@apache.org> a écrit :
>>
>> Hi all,
>>
>> Starting with TomEE 10.0.x, we've included MicroProfile 6.0 along with all the necessary OpenTelemetry classes and libraries.
>>
>> From what I've seen, many libraries—such as JDBC drivers—automatically enable OTEL features when the relevant libraries are present on the classpath, regardless of any MicroProfile configuration settings.
>>
>> This puts us in a tricky position: we’re often forced to stick with older library versions because upgrading from MP 6.0 to 6.1 tends to introduce breaking changes. Moreover, MP 7 can only be supported once CXF provides a compatible client, which is currently being targeted for Jakarta EE 11.
>>
>> Given this, I’d like to propose dropping the (de-activated) MicroProfile support from the Web, Plus, and Plume distributions—meaning we would no longer include the MP-related JARs by default. Instead, we could offer an optional script-based approach (e.g., via a zip/tar.gz package) that users can apply to add the MicroProfile flavor to Web/Plus/Plume as needed.
>>
>> Since this would be a breaking change, we could aim to roll it out starting with version 10.1.x.
>>
>> WDYT? Any thoughts?
>>
>> Gruß
>> Richard
Re: [DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume
Posted by Alex The Rocker <al...@gmail.com>.
Hello Richard,
[-1] for removing Microprofile from OOB TomEE 10.*
Indeed:
1. From a semantic versionning standpoint, it is not possible to
introduce a breaking change, so the earliest possible release to do
such major change would be TomEE 11
2. Competing applications servers (Payara, OpenLiberty, JBoss,...)
seem to have OOTB MicroProfile support
3. MicroProfile is often quoted as "the incubator for potential new
specifications [of Jakarta EE...]" (quoted from
https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee).
This last point is the key reason why I disagree with removing
MicroProfile from TomEE: enthousiatics developers willing to take
advantage of those ahead-of-time features brought by MicroProfile will
be less eager to use TomEE if MicroProfile isn't anymore part of it.
They most likely they'll fall into other application servers' hands.
That said, I welcome your initiative to cast such vote : your are
playing your role as TomEE's PMC chairman, which is to inspire the
future of this great community, with the democratic way to exchange on
ideas. I will love seeying counter-arguments to my reply, and I'm sure
that the more answers this proposal will get (whatever the final
outcome will be), the healtiest TomEE community will be!
Thanks,
Alex
Le lun. 14 avr. 2025 à 10:07, Richard Zowalla <rz...@apache.org> a écrit :
>
> Hi all,
>
> Starting with TomEE 10.0.x, we've included MicroProfile 6.0 along with all the necessary OpenTelemetry classes and libraries.
>
> From what I've seen, many libraries—such as JDBC drivers—automatically enable OTEL features when the relevant libraries are present on the classpath, regardless of any MicroProfile configuration settings.
>
> This puts us in a tricky position: we’re often forced to stick with older library versions because upgrading from MP 6.0 to 6.1 tends to introduce breaking changes. Moreover, MP 7 can only be supported once CXF provides a compatible client, which is currently being targeted for Jakarta EE 11.
>
> Given this, I’d like to propose dropping the (de-activated) MicroProfile support from the Web, Plus, and Plume distributions—meaning we would no longer include the MP-related JARs by default. Instead, we could offer an optional script-based approach (e.g., via a zip/tar.gz package) that users can apply to add the MicroProfile flavor to Web/Plus/Plume as needed.
>
> Since this would be a breaking change, we could aim to roll it out starting with version 10.1.x.
>
> WDYT? Any thoughts?
>
> Gruß
> Richard
Re: [DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume
Posted by Daniel Dias Dos Santos <da...@gmail.com>.
Hello,
+1 :)
On Mon, Apr 14, 2025, 10:44 Jonathan S. Fisher <ex...@gmail.com> wrote:
> +1 we strip microprofile during our build phase for memory savings and boot
> time.
>
> On Mon, Apr 14, 2025 at 3:07 AM Richard Zowalla <rz...@apache.org> wrote:
>
> > Hi all,
> >
> > Starting with TomEE 10.0.x, we've included MicroProfile 6.0 along with
> all
> > the necessary OpenTelemetry classes and libraries.
> >
> > From what I've seen, many libraries—such as JDBC drivers—automatically
> > enable OTEL features when the relevant libraries are present on the
> > classpath, regardless of any MicroProfile configuration settings.
> >
> > This puts us in a tricky position: we’re often forced to stick with older
> > library versions because upgrading from MP 6.0 to 6.1 tends to introduce
> > breaking changes. Moreover, MP 7 can only be supported once CXF provides
> a
> > compatible client, which is currently being targeted for Jakarta EE 11.
> >
> > Given this, I’d like to propose dropping the (de-activated) MicroProfile
> > support from the Web, Plus, and Plume distributions—meaning we would no
> > longer include the MP-related JARs by default. Instead, we could offer an
> > optional script-based approach (e.g., via a zip/tar.gz package) that
> users
> > can apply to add the MicroProfile flavor to Web/Plus/Plume as needed.
> >
> > Since this would be a breaking change, we could aim to roll it out
> > starting with version 10.1.x.
> >
> > WDYT? Any thoughts?
> >
> > Gruß
> > Richard
> >
>
>
> --
> Jonathan | exabrial@gmail.com
> Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
> full.
> Engineers, of course, understand the glass is twice as big as it needs to
> be.
>
Re: [DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume
Posted by "Jonathan S. Fisher" <ex...@gmail.com>.
+1 we strip microprofile during our build phase for memory savings and boot
time.
On Mon, Apr 14, 2025 at 3:07 AM Richard Zowalla <rz...@apache.org> wrote:
> Hi all,
>
> Starting with TomEE 10.0.x, we've included MicroProfile 6.0 along with all
> the necessary OpenTelemetry classes and libraries.
>
> From what I've seen, many libraries—such as JDBC drivers—automatically
> enable OTEL features when the relevant libraries are present on the
> classpath, regardless of any MicroProfile configuration settings.
>
> This puts us in a tricky position: we’re often forced to stick with older
> library versions because upgrading from MP 6.0 to 6.1 tends to introduce
> breaking changes. Moreover, MP 7 can only be supported once CXF provides a
> compatible client, which is currently being targeted for Jakarta EE 11.
>
> Given this, I’d like to propose dropping the (de-activated) MicroProfile
> support from the Web, Plus, and Plume distributions—meaning we would no
> longer include the MP-related JARs by default. Instead, we could offer an
> optional script-based approach (e.g., via a zip/tar.gz package) that users
> can apply to add the MicroProfile flavor to Web/Plus/Plume as needed.
>
> Since this would be a breaking change, we could aim to roll it out
> starting with version 10.1.x.
>
> WDYT? Any thoughts?
>
> Gruß
> Richard
>
--
Jonathan | exabrial@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
full.
Engineers, of course, understand the glass is twice as big as it needs to
be.
[DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume
Posted by Richard Zowalla <rz...@apache.org>.
Hi all,
Starting with TomEE 10.0.x, we've included MicroProfile 6.0 along with all the necessary OpenTelemetry classes and libraries.
From what I've seen, many libraries—such as JDBC drivers—automatically enable OTEL features when the relevant libraries are present on the classpath, regardless of any MicroProfile configuration settings.
This puts us in a tricky position: we’re often forced to stick with older library versions because upgrading from MP 6.0 to 6.1 tends to introduce breaking changes. Moreover, MP 7 can only be supported once CXF provides a compatible client, which is currently being targeted for Jakarta EE 11.
Given this, I’d like to propose dropping the (de-activated) MicroProfile support from the Web, Plus, and Plume distributions—meaning we would no longer include the MP-related JARs by default. Instead, we could offer an optional script-based approach (e.g., via a zip/tar.gz package) that users can apply to add the MicroProfile flavor to Web/Plus/Plume as needed.
Since this would be a breaking change, we could aim to roll it out starting with version 10.1.x.
WDYT? Any thoughts?
Gruß
Richard