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.

Reply via email to