[cdi-dev] Bean Discovery Mode in SE

[John D. Ament]

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