Pete Muir wrote on 12/17/12 00:19:
>>> However, I don't think this is a problem, the bread and butter of a Java
>>> EE container is checking if files exist, and parsing XML.
>>>
>>> To give you an idea of how the RI does it, Weld 1.1 allows a container
>>> to parse beans.xml itself, and parse in a object model representing it's
>>> content. Containers often want to parse deployment descriptors
>>> themselves, as it allows them to offer an interceptor-like facility
>>> around the parsing.
>>
>> I definitely wouldn't want both GlassFish code and Weld code parsing
>> beans.xml and making independent decisions about whether or not CDI is
>> enabled and in what mode.
>
> Only one or the other would do the parse. Agree that having both do it would
> be bad.
>
>>
>>> Weld also offers a parse utility (exposed via the Bootstrap class) which
>>> can be called at any point, it's not dependent on the CDI container
>>> having been initialized at all.
>>
>> This is more than just parsing, this is about answering the question of
>> which classes need to be scanned.
>
> Understood, this was to explain how Weld allows the container to do a parse
> of beans.xml before Weld is started, and I hope addresses your previous
> comment about the parsing being done differently. The point is that Weld
> allows the container to parse beans.xml at any time (no dependencies on Weld
> starting), examine the metadata (and in 1.1 we can easily have it expose an
> enum about what level of scanning is required by beans.xml). The container
> can then hold the result of this, and pass it to Weld when it starts, meaning
> that the parse isn't repeated.
>
> Obviously the container knows whether beans.xml is found or not (it has to
> pass it to Weld today), and combined with the parsed beans.xml, can make a
> decision about what to scan (this will be a ~10 line if statement).
Again, probably going into too much detail for this list, but...
I wouldn't want the container to know the name of beans.xml, nor the
schema of beans.xml. I hope the container asks Weld to "load the
configuration information for this module" and Weld does all the
detection of beans.xml, parsing, etc., and then after that is prepared
to answer the container's question of "what level of scanning do I need
to do for this module?"