[cdi-dev] Bean Discovery Mode in SE

Sun Mar 1 12:40:04 EST 2015

@John: I agree so we have to use web.xml or application.xml which doesn't
fit CDI since we can't use any CDI descriptor ATM. A solution would be
however maybe easy: master beans.xml (ie WEB-INF/beans.xml or
META-INF/beans.xml for war/ear and a beans.xml given to container in
standalone)

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-03-01 18:34 GMT+01:00 John D. Ament <john.d.ament at gmail.com>:

> I would avoid adding yet another xml file.  It'll be a bit hard to decide
> which XML files take precendence.
>
> For those looking to comment, the CDI SE page of the spec can be seen
> here, for comments:
>
>
> https://github.com/johnament/cdi/blob/CDI-26-docs/spec/src/main/doc/cdi-se.asciidoc
>
> John
>
> On Sun, Mar 1, 2015 at 11:53 AM Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>
>> well having a map as parameter is IMO mandatory at least for vendor
>> features.
>>
>> about scanning we cant use it for EE but we could use a standard
>> parameter. Issue we'll get here (EE) is we dont know when the container
>> scans so not sure we can standardize it so easily, would maybe need some
>> integration with other specs like a META-INF/scan.xml or something like
>> that. I guess we can ignore EE short term to avoid another "by spec"
>> solution - keeping vendor features for it in the mid term.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com>
>>
>> 2015-03-01 17:49 GMT+01:00 John D. Ament <john.d.ament at gmail.com>:
>>
>>> So that's one of the benefits from my point of view of having that extra
>>> initialize w/ map options.  We can start to define some standard parameters
>>> to control SE mode for some SE specific issues that may pop up.
>>>
>>> I'm just not sure how that'll apply yet, as ideally the issues should be
>>> in both SE and EE.  I think your case is mostly an SE problem, but the
>>> other issues I'm thinking of are EE as well.
>>>
>>> - Additional scanning configuration on a global scale (package level and
>>> classpath entry name [like you mentioned]).  Package level since the
>>> beans.xml files all end up at the same level.
>>> - How to specify additional Bean Defining Annotations (for
>>> bean-discovery-mode=annotated)
>>> - Disable extension loading/Explicitly list extensions to load.
>>>
>>> There will probably be more options that come up as well.  Maybe to fix
>>> the SE/EE discrepancies, we allow the definition of a bean that returns a
>>> Map<String,Object> that can be loaded in either SE or EE, and instead of
>>> the default being an empty map we read this via a service loader or
>>> something.
>>>
>>> John
>>>
>>>
>>> On Sun, Mar 1, 2015 at 11:28 AM Romain Manni-Bucau <
>>> rmannibucau at gmail.com> wrote:
>>>
>>>> It is consistent so ok.
>>>>
>>>> Wonder if we can get some rule we could pass to the container to say
>>>> "dont scan jackson*jar" - issue begin we have to suppose we run with a
>>>> classpath we dont control. Or the opposite "scan myapp*jar".
>>>>
>>>> wdyt?
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>> <http://rmannibucau.wordpress.com> | Github
>>>> <https://github.com/rmannibucau> | LinkedIn
>>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>>> <http://www.tomitribe.com>
>>>>
>>>> 2015-03-01 16:18 GMT+01:00 John D. Ament <john.d.ament at gmail.com>:
>>>>
>>>>> Yeah actually you're right.  For some reason I had in my head that
>>>>> "all" was the default.  It's very clearly not.  Too early for some of this
>>>>> :-)
>>>>>
>>>>> So let me rephrase.  "annotated" will be the default bean discovery
>>>>> mode if a classpath entry contains no META-INF/beans.xml, based on the
>>>>> exact same rules used in EE.
>>>>>
>>>>> Any concerns with that?
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>> On Sun, Mar 1, 2015 at 10:10 AM Romain Manni-Bucau <
>>>>> rmannibucau at gmail.com> wrote:
>>>>>
>>>>>> For me it is 100% the same as ee where you have the same issues so
>>>>>> keeping them aligned is better IMO. That said configuring globally the
>>>>>> scanning would be nice.
>>>>>> Le 1 mars 2015 15:54, "John D. Ament" <john.d.ament at gmail.com> a
>>>>>> écrit :
>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> I'd like to propose in my doc changes for CDI-26 that if a classpath
>>>>>>> entry does not contain a META-INF/beans.xml that it is treated as if it
>>>>>>> were bean-discovery-mode=none, e.g. no beans will be scanned in that entry.
>>>>>>> (BTW, I'm using classpath entry rather than archive in the document to
>>>>>>> account for cases where someone does -cp
>>>>>>> "./classes:./extra-classes:./lib/*" to define their classpath)
>>>>>>>
>>>>>>> It's a bit different than how EE works, but I could imagine it
>>>>>>> causing fewer headaches when running on SE classpaths.
>>>>>>>
>>>>>>> Any thoughts/comments?
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev at 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.
>>>>>>>
>>>>>>
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150301/3d299aab/attachment.html 