Hi Jonathan,
thanks for the feedback! To understand whether openejb-standalone would still
work for you without the embedded HTTP server (httpejbd), could you share a bit
more about what those backend apps need?
• Any HTTP at all? (REST endpoints, EJB calls over HTTP, health checks /
metrics for probes)
• Remote EJB access, or purely local (MDBs, singletons, timers)?
• For the MDBs: which broker - embedded ActiveMQ or an external one?
httpejbd and openejb-standalone are separable, so dropping one doesn't
necessarily mean dropping the other but it'd be good to know which pieces you'd
actually rely on.
However, this thing - httpejbd - is a hand-written HTTP server that nobody
maintains. It gets none of the hardening, request-parsing fixes or CVE response
that Tomcat's connectors get.
Perhaps time to let it go? I bet that one will find tons of issues if you throw
a cheap LLM at it ...
Gruß
Richard
> Am 13.09.2026 um 23:19 schrieb Jonathan S. Fisher <[email protected]>:
>
> A long time ago we did (TomEE 7 days).
>
> We currently run a lot of "backend" apps, but we have typically deployed on
> them on the Tomcat based container. We're actually looking to move some of
> these to openejb-standalone for less exposure surface (no Tomcat CVEs for
> things that dont actually need Tomcat). We don't have a use for EJBs
> anymore except for MDBs, singletons, and timers, all which execute locally;
> none of those require remote invocation or coordination.
>
> As a side note, sure be cool if TomEE had a "invoke this interface" and
> have TomEE locate it locally or remotely. Be a cool portable extension to
> write!
>
> On Sun, Sep 13, 2026 at 1:41 PM Markus Jung <[email protected]> wrote:
>
>> Hey all,
>>
>> I’ve been discussing with Richard lately in private about dropping
>> openejb-http and think we should be bringint it to the list. Looking at
>> openejb-http we noticed it's really two things in one module: the embedded
>> HTTP server ("httpejbd") and the HttpListener / request / response /
>> servlet adapter types that CXF, tomee-jaxrs and tomee-webservices plug into.
>>
>> On TomEE the server never runs. TomEEServiceManager skips httpejbd (along
>> with ejbd, ejbds and admin) and Tomcat's connectors handle all HTTP [1].
>> The only things that still start it are:
>>
>> - the openejb-standalone assembly, where it's the HTTP transport for
>> remote EJB calls
>> - ApplicationComposer tests with @EnableServices("jaxrs"/"jaxws"), ~80
>> test classes, most of them in openejb-cxf-rs (57) and openejb-cxf (10)
>> - openejb.embedded.remotable and the arquillian-openejb-embedded adapter
>> - ~19 examples (simple-rest, rest-cdi, the jsonb ones,
>> applicationcomposer-jaxws-cdi, the webservice-* ones)
>>
>> So the only real runtime user is openejb-standalone, the rest is test
>> tooling. IMO we should drop both httpejbd and the openejb-standalone
>> assembly and move the affected tests/examples over to a Tomcat based setup
>> (tomee-embedded / arquillian-tomee-embedded). The adapter types would stay
>> since TomEE needs them, so this is more a split of the module than a
>> removal.
>>
>> Independent of that: the Jetty backend in openejb-http checks for
>> org.mortbay.jetty.Connector (Jetty 6) while the pom pulls Jetty 12, so it
>> always falls back to the OpenEJB server and can never run [2]. I'd remove
>> that in any case.
>>
>> Does anyone still use openejb-standalone or rely on httpejbd outside of
>> tests? WDYT?
>>
>>
>> Thanks
>>
>> Markus
>>
>> [1]
>> https://github.com/apache/tomee/blob/main/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/TomEEServiceManager.java
>> [2]
>> https://github.com/apache/tomee/blob/main/server/openejb-http/src/main/java/org/apache/openejb/server/httpd/HttpServerFactory.java
>
>
>
> --
> Jonathan | [email protected]
> 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.