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.