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?