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>
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.
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...
Cheers,
Reza
On 7/14/2011 4:53 PM, Bill Shannon wrote:
> Thanks for the pointer, Reza. I've spent a little time trying to read it
> but I'm finding it very difficult to read. I feel like I've come in
> in the
> middle of the story.
>
> From my view about 10,000 feet up, it looks like this is the same as
> Seam Config, which is the same as what was originally proposed for CDI.
> As I understand it, the general idea is to associate XML namespaces
> with Java package or class names, then use elements in that namespace
> to reference (e.g.) methods or properties or fields of the class. The
> XML elements are then used to modify the configuration of those Java
> elements, e.g., by adding or removing the effective annotations applied
> to those elements, and by specifying the values to be injected into those
> elements, possibly by reference to other elements.
>
> Is that close?
>
> I kind of like that approach, and it seems to make a lot of sense for the
> cases that involve configuring particular Java classes.
>
> 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. How would I use this to replace application.xml? How would
> I configure the location of the library directory? How would I list the
> modules included in the application? (I can imagine answers to these
> questions, but what I want to know is how *you* think this would work.)
>
> In any event, the basic "bean configuration" capability you describe
> seems
> like it would fit well with CDI, where it was first proposed. We know
> that
> we need a way to specify or override CDI configuration using XML, but
> unfortunately I don't see that in the CDI 1.1 JSR. Perhaps this is being
> deferred until CDI 2.0 and/or Java EE 8?
>
>
> Reza Rahman wrote on 07/12/2011 12:03 PM:
>> Bill,
>>
>> In that case, I think the existing documentation for CanDI configuration
>> suffices: http://caucho.com/resin-4.0/admin/config-candi.xtp.
>>
>> Basically the key concepts we would like to see (strictly in order of
>> priority)
>> are:
>> * Compact, "Java-like" schema-based syntax, similar to the Seam Config
>> module/CanDI XML.
>> * Being able to configure CDI and EJB using this syntax.
>> * Being able to load property file values/environment property values
>> through EL
>> (this might be a good enhancement to EL regardless of this). We
>> allude to this
>> in the docs, but it is not completely hashed out.
>> * Being able to configure all Java EE managed beans including
>> Servlets using
>> this syntax. Like Resin configuration we would actually prefer that
>> most Java EE
>> configuration looks like managed bean configuration using XML.
>> * Have separate schemas for current XML DD values that do not match
>> the managed
>> beans/annotation paradigm well. Taking the web.xml as an example,
>> things like
>> module names, session configuration, etc can go in such schemas. I
>> think the
>> number of tags that genuinely fall in this category is quite small.
>> * Being able to configure multiple things in any Java EE XML DD using
>> schemas.
>> For example, you would be able to configure CDI beans in web.xml if
>> you want.
>> * Let all Java EE XML DDs have capabilities similar to web.xml
>> fragments.
>>
>> Let me know if any of this requires further details. Since we started
>> down this
>> path, I'd prefer to follow this to the end. I do think there is
>> tangible befits
>> for developers in such an enhancement and at least some of it is
>> doable in Java
>> EE 7 if there is a desire to do it. We in the Resin team can see if
>> we have the
>> resources to contribute to this significantly if resources are an
>> issue (I do
>> feel a little funny soliciting Oracle with an offer of additional
>> resources from
>> a tiny company like Caucho :-)).
>>
>> Cheers,
>> Reza
>>
>>
>> On 7/11/2011 2:44 PM, Bill Shannon wrote:
>>> I think at this point we just need to understand more to assess whether
>>> this would be feasible in the limited time we have. Maybe a brief
>>> informal description with examples would be better than a detailed
>>> proposal
>>> at this stage?
>>>
>>> Reza Rahman wrote on 07/11/11 08:26 AM:
>>>> Linda/Bill,
>>>>
>>>> What is the practical possibility we can include this in Java EE 7? If
>>>> you are still seriously considering it, I have some time now to put
>>>> together a detailed proposal (the time window will not last long). One
>>>> important part of an XML configuration revamp would be to load
>>>> properly
>>>> files and system/environment variables from EL (that might be
>>>> important
>>>> to add to EL regardless of this).
>>>>
>>>> Thanks,
>>>> Reza
>>>>
>>>>
>>>> On 6/6/2011 6:01 PM, Linda DeMichiel wrote:
>>>>> Antonio,
>>>>>
>>>>> Sounds interesting, tell us more....
>>>>>
>>>>> thanks,
>>>>>
>>>>> -Linda
>>>>>
>>>>>
>>>>> On 6/2/2011 10:47 AM, Antonio Goncalves wrote:
>>>>>> I would like to share some thoughts with you.
>>>>>>
>>>>>> I've used in the past Spring Config and latelly I've attended a
>>>>>> conference that talked about Seam Config. Clearly I can
>>>>>> see the benefit of having easy configuration on the entire platform.
>>>>>> At the moment we have ejb-jar.xml and environment
>>>>>> entries to configure our EJBs. We can also use the web.xml to pass
>>>>>> some parameters to our servlets and bits and pieces
>>>>>> in the application.xml file.
>>>>>>
>>>>>> Why not having a seperate spec that takes inspiration from Seam
>>>>>> Config, Spring Config and so on to be able to configure
>>>>>> the entire platform (a CDI bean as well as an EJB...). Configuration
>>>>>> will also be used for Paas purposes of course.
>>>>>>
>>>>>> Configuration is an important topic and developers never know where
>>>>>> to put it : property files, XML, database, JNDI. Why
>>>>>> not having a spec that specifies how configuration should work (I
>>>>>> really like the Seam Config approach) and each spec
>>>>>> could then use it to specify how to configure a specific component,
>>>>>> as well as batch processing or Paas/Saas
>>>>>> configuration...
>>>>>>
>>>>>> Again, my 2 cents
>>>>>>
>>>>>> --
>>>>>> Antonio Goncalves
>>>>>> Software architect and Java Champion
>>>>>>
>>>>>> Web site<http://www.antoniogoncalves.org> | Twitter
>>>>>> <http://twitter.com/agoncal> | Blog
>>>>>> <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn
>>>>>> <http://www.linkedin.com/in/agoncal> | Paris JUG
>>>>>> <http://www.parisjug.org>
>>>>>
>>>>>
>>>>> -----
>>>>> No virus found in this message.
>>>>> Checked by AVG - www.avg.com
>>>>> Version: 10.0.1382 / Virus Database: 1511/3682 - Release Date:
>>>>> 06/05/11
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 10.0.1388 / Virus Database: 1516/3758 - Release Date: 07/11/11
>>>
>>>
>>
>>
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1390 / Virus Database: 1516/3763 - Release Date: 07/13/11
>
>