On 18 Dec 2012, at 23:44, Bill Shannon wrote:
> 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?"
Kinda, except that it's the container responsibility to load the beans.xml file. There is no portable scanning api in Java/Java EE to allow us to detect such files.