[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdi-dev] CDI future - problems and proposal
|
That is a general problem that manifests in circular dependencies between spec TCKs and releases. We should adopt a notion that CDI requirements on other specs and their containers be added as CDI addendum specs to those containing specs, and make the associated TCK tests separable libraries that can be consumed by the downstream spec TCK.
Hi,
or in retrospect shouldn't be in CDI
in the first place. Things like:
- decorators
- specialization
- session scope
- conversation scope
- passivation
- non-contextual injection
I always felt that just JSR 330/AtInject was way too small, while JSR 299/CDI might have been a tad too big. My personal pet peeve is the fact that CDI includes build-in beans for several Servlet types, such as HttpServletRequest. We tried hard before to get that out of CDI and into Servlet. Likewise, the build-in bean for Principal should likely belong in Jakarta Security, etc.
Though the conversation scope is technically not bound to Faces, maybe we should consider moving it to Faces anyway?
Thoughts?
Kind regards,
Arjan Tijms
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
