Mark
seems there are multiple topics and can maybe be better to split them
accross threads to avoid to cross topics and finally be lost easily.
Here the ones I see:
-> BDA BM (what it means, usability in real apps = outside of TCKs) -
this is also the question of the modularity of CDI. there are few
pointers in the spec but seems it is only implemented this way in few
containers. The question of deployment/runtime consistency if
important as well. 1 BM by jar is quickly broken because you can write
any lib (too restricted visibility) + "jar" sometimes doesnt mean
anything (but deployment does).
-> EAR and bean managers (1 by jar? 1 by sub app? 1 for lib + 1 by
webapp? 1 for the whole app?)
-> (if previous answer is not 1 for the whole app) EAR and bean
propagation/inheritance
-> same as previous with events (splitting in container events and
runtime events I think)
-> EAR and different use cases (1) just a packaging for my app, 2)
aggregating existing app => both needs different meaning for the same
scopes relatively quickly :s)
Hope I was more or less clear on this fuzzy topic
Romain Manni-Bucau
@rmannibucau
I fear the clash in bean names across different WARs is a bug which
is the direct consequence of Weld only has 1 ‚User BeanManager‘. It seems there are
multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ‚BDA
BeanManager‘. But there must be another one. What happens to all the
AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld?
What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ?
If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my
WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same
Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly)
isolated unit.
Arjans experience is only the tip of the iceberg.
@Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I
expect this is also broken as you added lots of workarounds to get it running on Weld. But
still would love to know how far (or not) portability goes.
I do fully agree with „1 Extension instance per Application“ paragraph. But the important
question is what Appliation means. This is by far not clear. The EE spec for example talks
about „multiple Applications in an EAR“ in some paragraphs (meaning Web-Apps it seems). So
both interpretations are ok by the strict spec wording.
Of course, the other approaches have their downsides as well…
LieGrue,
strub
> Am 18.02.2015 um 12:02 schrieb arjan tijms <arjan.tijms(a)gmail.com>:
>
> Hi,
>
> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg <struberg(a)yahoo.de> wrote:
>>
https://struberg.wordpress.com/2015/02/18/cdi-in-ears/
>
> Interesting write up!
>
> Over at OmniFaces we had some major issues with this as well, and
> blogged about that experience a little over a year ago. See
>
http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html
>
> We also compiled an overview of what works and doesn't work with CDI
> and ears from our perspective here:
>
https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI)
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>>
>> There was a lively discussion on twitter but 140 chars is way too restrictive to
have a good flow ;)
>>
>> So please lets continue the arguments over here.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For
all other ideas provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.