Bill,
I guess it's a little disheartening that no one else on the alias is
chiming in on this - not sure if this is just that boring or that they
are judiciously biding their time :-).
Anyways, would it help much that this approach might open the doorway to
100% XML free, Java based configuration down the line or that it greases
the wheels for other possibilities like JSON or property file based DDs?
It also helps make configuring CDI style DI easier for any managed bean...
To be honest though, I think just getting some kind of CDI XML in Java
EE 7 would be a good accomplishment in the scheme of things. I've never
been a proponent of making big changes in the standard without some
implementation precedent. If we defer the general overhaul of Java EE DD
to Java EE 8, this does give us (and hopefully others) a little more
room to do some "bleeding edge" implementation work on our own terms. As
far as you can see, there is nothing in the standard that stops us from
doing that, right?
Cheers,
Reza
On 7/18/2011 5:42 PM, Bill Shannon wrote:
> Reza Rahman wrote on 07/18/11 08:21 AM:
>> Bill,
>>
>> Sorry for the delayed response. Unfortunately I had to be off-line for a
>> couple of days. Responses below:
>>
>> * I've spent a little time trying to read it but I'm finding it very
>> difficult to read.
>> - I figured as much :-). I apologize for the staccato style of that
>> document. As you can imagine, it matches the persona of the individual
>> that wrote that section of our documentation :-). If any of it requires
>> further explanation, I can do that here.
>>
>> * It looks like this is the same as Seam Config, which is the same as
>> what was originally proposed for CDI.
>> - Correct. It is basically that with a few pieces that we saw missing
>> like the property file/environment value loading via EL.
>>
>> * What I don't understand is how that approach would be used to replace
>> the full range of things you can configure with our existing deployment
>> descriptors.
>> - We haven't decided on that ourselves yet. For Resin, we didn't want to
>> change the underlying semantics of the existing Java EE XML tags, so we
>> were going to leave them as is and overlay them with the new syntax. So
>> there would be two ways of configuring a Servlet:
>>
>> "Old" way:
>> <javaee:servlet>
>> <javaee:servlet-name>myServlet</javaee:servlet-name>
>> <javaee:servlet-class>com.acme.MyServlet</javaee:servlet-class>
>> </javaee:servlet>
>> <javaee:servlet-mapping>
>> <javaee:servlet-name>myServlet</javaee:servlet-name>
>> <javaee:url-pattern>*.html</javaee:url-pattern>
>> </javaee:servlet-mapping>
>>
>> "New" way:
>> <acme:MyServlet>
>> <ee:WebServlet urlPatterns ="*.html"/>
>> </acme:MyServlet>
>
> Yes, that I understood.
>
>> 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.
>
>> This approach basically requires a mind-set change of thinking of XML as
>> a way to wire objects rather than purely used to describe configuration
>> via mark-up and thinking of all configuration as objects themselves. The
>> great benefit is that it makes all Java EE configuration more generic
>> and possibly even decoupled from XML altogether (down the line as more
>> advanced meta-data vehicles become available).
>>
>> * In any event, the basic "bean configuration" capability you describe
>> seems like it would fit well with CDI, where it was first proposed.
>> - I agree that this is a sound approach given what we know about the
>> scope/time-line of Java EE 7. The only thing I am concerned about going
>> down this path right now is being able to use the EJB services in CDI
>> XML in Java EE 7. That being said, CDI is an ideal place for a
>> "proof-of-concept" for this just as EJB 3.0 was for annotations. This
>> also gives us a chance to implement some of this at a broader level in
>> the "Java EE 7" releases of Resin before standardizing it :-).
>>
>> Do let me know if we should discuss anything in greater detail. I do
>> think we should think about some of the ramifications of doing this
>> beforehand. Admittedly, we haven't yet had a chance to do this
>> yourselves, hence my initial hesitation of bringing this up right now.
>> But then again, I guess that's why we have this EG, right? We also could
>> get broader community feedback on this...
>
> Have you gotten community feedback on the current support you have in
> Resin?
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1390 / Virus Database: 1516/3773 - Release Date: 07/18/11
>
>