Hi Jon, This isn't part of the specification as far as I am aware of. And my understanding from the discussion I had with Romain, this isn't part of CDI either and not really required anymore. But was added for compatibility reasons.
The side effect might be related to a bad merge between CDI beans and EJB beans in the context of an EAR file. There is already a flag to turn it off at the bottom of the commit you pointed to. openejb.cdi.support.@Startup=false Hope it helps -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Wed, Nov 24, 2021 at 11:08 AM Jonathan Gallimore < [email protected]> wrote: > Hi All, > > I have a slightly odd scenario, where I have an EAR file, with a library in > the EAR's lib folder, which has a Singleton EJB, which is annotated > with @Startup. > > The code in question is a common library shared between a number of > applications. Where I want the bean to be used, I define it by including an > entry in a ejb-jar.xml file in an EJB module in an EAR file. > > When deploying this EAR file, it appears that CDI picks up this class via a > scan, and attempts to start it, which fails because it isn't > ApplicationScoped - here is the error: > > Caused by: java.lang.IllegalStateException: Only normal scoped beans can > use @Startup - likely @ApplicationScoped > > It looks like this behaviour is intentional, and was introduced here: > > https://github.com/apache/tomee/commit/351aa3fd63bed63d5e4289693c7155ac5c413845 > > A couple of quick questions: > > * Is this behaviour defined/required by one of the specifications? > * Can we make a change to turn it off? > > Assuming it isn't required by a spec, ideally it would have been something > that one would specifically turn on, but requiring that now would be a > backwards incompatible change, so I'd propose adding a parameter to allow > it to be turned off. Would anyone object to that? > > Thanks > > Jon >
