[cdi-dev] Bean Discovery Mode in SE

[Romain Manni-Bucau]

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/2f32bc6b/attachment.html