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 > >>>> > >> >
