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 > <jonathan.gallim...@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 <r...@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 < >>>> jlmonte...@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 <r...@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 <r...@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.m3...@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 <r...@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 >>>>>> >>>> >>
