2

I have a use case where I want to create dynamically (=programmatically) a Stateless Session Bean (EJB3) instead of declaratively creating a Stateless bean through annotation (@Stateless).

Is there a way of telling the EJB container / CDI that my programme wants to:

  • create a java instance;

  • dynamically register the instance as a Stateless EJB (including any meta information such as transactional context (which method should run in which transaction context and under which TxType (Required, Supports, ...)) and

  • registering it also in the naming context (JNDI / EJB name)?

So, in a nutshell:

I have custom code acting as a "Stateless SB" producer/provider and it should be able to let the container know that it wants to register a new instance (class) as a Stateless SB with all expected EJB's behaviours (Tx interceptors etc etc).

So what I am really saying:

My code knows how to implement a specific logic(by code) which needs to be dynamically encapsulated in an instance which belongs to SOME class that is NOT declaratively annotated with the @Stateless annotation and will be dynamically (runtime) decorated in such a way to behave like a Stateless session bean.

Another way to approach this, IMO:

To define all EJB specific meta information in the interface which would be implemented by a bean, but EJB3 spec does NOT allow you to declare @Stateless on interface level. @Stateless should be declared on implementation level (bean).

Mind you: it is precisely this STATELESS ANNOTATED bean implementation which does NOT exist in my case. So there is no way for the container to scan the code, to find and to register a class as a stateless bean.

Any ideas?

user2120188
  • 427
  • 1
  • 4
  • 16
  • No, EJBs must be declared on start up via deployment descriptor or annotations. CAn you explain your use case though? – John Ament Oct 29 '16 at 12:44
  • Maybe you are not looking for creating EJB's dynamically, but you are looking for a pojo to have transactional capabilities and also could be injected into other components. Whole idea about EJB is being "container managed". You should revise your use case. – infiniteRefactor Oct 29 '16 at 12:47
  • Hi John. I want to do some prototyping by implementing a REST API which is using stateless session beans to access business logic. I am able to annotate at injection point the real session bean or a data stubbed session bean (mock) depending on a switch in my custom annotation (thru CDI). The real session bean is implemented in the traditional way (@Stateless), but in the other case (mock) I do some dynamic stuff because I am stubbing with a mock framework. I basically ask my @Produces annotated method to "give me" a mock based on some service interface. I want mock instance to behave as SLB. – user2120188 Oct 29 '16 at 12:54
  • Hi infiniteRefactor. I understand your suggestions. My consideration is that I want to keep the logic -which is calling my service method- agnostic for my strategy (whether it is the real thing or a prototyped version of my service (mock)). Actually, the known "build against interface pattern" or the way Spring is using this pattern to do its DI. But now, I want to pass in my version of implementation at runtime. – user2120188 Oct 29 '16 at 13:00
  • Hmm, as I am writing you guys... I realize also that all these things (which I would like to happen) should take place when SLB is being created for the first time (and before it is put in a pool).... kinda impossible if I see my code/design...suddenly.. ... I wonder if what I want is possible suddenly ... (thinking loudly now ;-)) – user2120188 Oct 29 '16 at 13:03
  • How are you determining the logic encapsulated? Is someone typing it in? – John Ament Oct 30 '16 at 12:23
  • After having thought about the realization as described above I decided to change the design. I explicitly declare a class as Stateless bean (@Stateless) which inherits from a Base class where I supply some prototyping logic and define an operation to be implemented by its subtypes. In that operation stubbing will be defined. Thanks. – user2120188 Oct 30 '16 at 14:53
  • Hi John, I am simply using mockito to define certain scenario's (when.then) I would like to simulate when a stateless bean method is called. – user2120188 Oct 30 '16 at 23:20
  • Did you already think about using @Alternative in your mocking environment? Probably cdi-unit or ejb-cdi-unit could help. – aschoerk Jul 25 '17 at 07:17

0 Answers0