Pete Muir wrote on 07/21/2011 04:05 AM:
>
> On 18 Jul 2011, at 22:42, Bill Shannon wrote:
>>
>>> Similarly, application.xml content in the more OO style XML could be
>>> like this:
>>> <javaee:Application>
>>> <javaee:modules>
>>> <javaee:value><javaee:JarModule uri="test-client.jar"/></javaee:value>
>>> <javaee:value><javaee:EjbModule uri="test-ejb.jar"/></javaee:value>
>>> <javaee:value><javaee:WebModule uri="test.war"
>>> context-root="test"/></javaee:value>
>>> </javaee:modules>
>>> <javaee:libraryDirectory>lib</javaee:libraryDirectory>
>>> </javaee:Application>
>>>
>>> Now, it becomes a very interesting question if the Application object
>>> itself would become injectable via CDI. In case of Resin, the answer
>>> would be yes, since we are basically CDI-based from the ground up and
>>> almost everything in the server is a CDI object. In case of Java EE, the
>>> right answer might be that the actual Application object is not
>>> available via injection.
>>
>> But you would envision *defining* an Application object that would contain
>> the properties needed to allow the above configuration style to work?
>> That's kind of what I was expecting, although it's a bit weird to define
>> a Java API that you can't actually use anywhere except to reference it in
>> such an XML configuration file. I suspect people would want access to it
>> so that they could change their application's configuration at runtime,
>> and I'm not sure that's a good thing.
>
> We at JBoss do not like this style of using bean configuration for
> configuring things that aren't actually beans. We've found our users find
> this confusing. We prefer to use a configuration scheme that is designed as
> XML from the ground up, sometimes even if there is a programmatic approach to
> configuration as well. We find this provides a better approach as you don't
> shoe-horn two inherently different things together.
>
> OTOH configuration for a user application is somewhat different, primarily
> due to the fact they likely don't want to spend a lot of time designing a
> configuration scheme.
To help us understand your position, how would you use this new configuration
approach to configure the other elements that are currently configured in a
deployment descriptor? What would be your equivalent of the above XML?