[cdi-dev] Bean Discovery Mode in SE

[John D. Ament]

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/d41d331c/attachment-0001.html