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
