Hi Jonathan, cool, thanks for the detailed answer!
If I read it right, your setup (no HTTP, no remote EJB, external ActiveMQ) doesn't need httpejbd at all. So we could drop the embedded HTTP server and still keep openejb-standalone as a lean, Tomcat-free runtime for exactly that kind of use case. @all: Is anyone else still using httpejbd or the HTTP capability of openejb-standalone outside of tests (e.g. EJB calls over HTTP, REST endpoints without Tomcat)? Any objections to dropping it? Thanks Richard On 2026/09/14 18:14:18 "Jonathan S. Fisher" wrote: > * no http. We set up jolokia as a jvm agent for monitoring via telegraf. > In-band health checks are pretty worthless when the rubber hits the road! > * no remote EJB access. The EJB remoting model is outdated unfortunately. > OpenEJB made it stupid easy back in the day, especially compared to WAS! > But with CDI being the new king, it's not really a thing for us (at least). > - A modern CDI portal extension/ replacement would be awesome! I was > thinking something with mdns discovery... I'll get around to this... some > day > * always external ActiveMq! It how we scale to a datacenter and distribute > work. > > > > > > > On Mon, Sep 14, 2026 at 12:26 PM Richard Zowalla <[email protected]> wrote: > > > 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. > > > > > > -- > 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. >
