Re: [DISCUSS] Stop shipping MicroProfile Integration with Web/Plus/Plume

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 <[email protected]> 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 <
>> [email protected]>:
>>> 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 <[email protected]>
>> 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 <[email protected]>:
>>>>>
>>>>> 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 <[email protected]
>>> :
>>>>>> 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 <[email protected]> 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
>>>>
>>