Uploaded image for project: 'Weld'
  1. Weld
  2. WELD-1321

WELD/CDI get mixed up with CMT and persistency (context)


    • Type: Feature Request
    • Status: Resolved (View Workflow)
    • Priority: Critical
    • Resolution: Rejected
    • Affects Version/s: 1.1.10.Final
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Affects:
      Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial
    • Estimated Difficulty:


      Dear sirs,

      in order to test our calculation engine, that runs inside a EJB
      container (as an MDB for batch processing), we decided to use
      CDI to test this calculation engine .... outside of the JEE
      container, within a looping Junit test.

      The JUnit test invocation (and mocking) is working well with
      DeltaSPIKE and Weld-1.1.10. That's perfect.

      Unfortunately we are unable to run the calculation engine
      inside the EJB-container (respective as an mdb), cause the
      XA-datasource went mad and logged out weired messages of
      unsucceeded connect-request or weired transaction context.

      So i decided to extend my maven-driven test application,
      in order to emulate that faulty behaviour. This application
      works similar to our application.

      Small test app description:
      The major project contains three sub-projects:
      + CdiTestMackEAR for to build the ear
      + CdiTestMackEJB contains the EJB beans
      ok, there is actually ony one, that (self) initiates
      our test by means of a timer, that is attached to
      the timelyTest runner.
      + CdiTestMackService sub package that contains the calc engine,
      that is implementet in the CalculationEngineExmp01Impl
      class. Any data request is beeing declared by the
      DataSvcIf interface.
      Implementation are

      • MockMeMockMe for JUnit testing and
      • JpaDataSvc the failing JPA implementation.

      You can simply let the application write a bunch of
      exception, iff (see ServiceAccessPointBean.java line 55ff
      assign a string:
      inParamter.setBoxName(myBoxName) ;

      or blind out any exception:
      inParamter.setBoxName(null) ;

      Finally both assignments cause problems, but apparently the
      first one creates excptions.

      1) From my point of view the cause of the problem is
      the CDI-API, that lacks of some important functionality
      for transaction oriented processing.

      When the transactional method starts to run,
      the SLSB has been activated (postconstruct finished).
      All my ressouces have been reserved for my atomic
      operations. I will not require additional ressources
      from the injected implementation during runtime.
      Therefore all injected references should have been
      initialized (with their ressources) or better should
      be re-use the reserved/allocated ressources.

      In other words: Iff my atomic transaction starts,
      i do not want to allocate others during runtime.
      (we are not playing the Spring game in an EJB!!!)

      As a consequence of this, i would expect a
      passthrough interface, sharing my reserved
      ressources to the injected instances.

      Besides, it should be possible (better say the standard),
      to inherit the current transaction context to the
      injected implementations, maybe some of them
      needs them. (Nestated transaction shall not be
      the only one option).

      I was thinking of the transacion-cts, when i was
      folling the irritating stack traces. I guessed, that
      each CDI invocation created a separate transaction
      context outside of the EBJ container.

      Iff you have any question, let me know.
      For now, i'll have to remove the CDI from
      our project, until it is transaction safe.

      (SEE ALSO: http://stackoverflow.com/questions/8772175/how-to-implement-container-managed-transaction-cmt)

      Another thing is: Please write in your documentation
      what can be doen with Weld/CDI and which use cases
      (like mine) is not expected to work.

        Gliffy Diagrams




              • Assignee:
                jharting Jozef Hartinger
                TheGroove Christian Groove
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: