Ideally, we would encapsulate all the hacks and provide two
implementations. One for 1.0 with the hacks and one for 1.1 without the
hacks.

Cheers,
Arne


Am 01.10.14 01:14 schrieb "John D. Ament" unter <[email protected]>:

>HI all,
>
>I'd like to bring up the topic of how to best handle CDI 1.1/1.2
>integration within DeltaSpike.  If you look at our code, we have a few
>cases of "hacks" to make CDI 1.0 work cross container in our extensions.
>Much of this is fixed for CDI 1.1/1.2/EE7 so I was wondering how it would
>make sense for us to support those runtimes even better.  Here are some of
>my thoughts.
>
>- Create a DS 1.1.0-SNAPSHOT branch for CDI 1.1/1.2 compatibility.
> 1.0.x-SNAPSHOT would remain for maintenance on this release line.  We
>would have to determine branch naming strategy (e.g. does 1.1.0 go on
>master or a separate release branch?)
>- What features do we leverage? There's a bunch of things I see as
>problematic today
>    - Keep BeanManagerProvider/BeanProvider but have them wrap
>CDI.current() instead of their current behaviour.
>    - Replace usage of @Typed with @Vetoed
>- What do we enhance?
>    - Our current @Transactional mirrors the EE7 transactional, except we
>support RESOURCE_LOCAL for JPA.
>    - Certain modules become irrelevant (Servlet/BeanVal come to mind).
>Do
>we document how to migrate forward?
>    - Certain modules can be significantly reduced (JPA/JSF).  Do we do
>something similar?
>
>
>John

Reply via email to