On Feb 23, 2005, at 11:53 AM, Dain Sundstrom wrote:
On Feb 23, 2005, at 11:40 AM, David Blevins wrote:
On Wed, Feb 23, 2005 at 12:13:50PM -0500, Alan D. Cabrera wrote:I don't parse the data at startup. The data gets parsed by a tssConfigEditor and a cssConfigEditor at deployment time.
Cool. Is this a case where you could put the xml in another file in the archive and have the attribute be the name of the file?
I personally dislike having lots of little config files in the archive. I think it would be more natural for our xml document to be extensible, and support importing of schemas into our catalog.
I agree that lots of files is unpleasant.
And to appease david's no-mixed context rule we could have two attribute elements, one for xml and one for text;
<attribute name="port">8888</attribute>
<xattribute name="securityConfig">
<security xmlns="http://geronimo.apache.org/xml/ns/security">
<default-principal realm-name="public-properties-realm">
<principal class="o.a.g.s.r.p.GeronimoUserPrincipal" name="j2ee"/>
</default-principal>
<role-mappings>
<role role-name="Administrator">
<realm realm-name="public-properties-realm">
<principal class="o.a.g.s.r.p.GeronimoUserPrincipal" name="j2ee"/>
</realm>
</role>
<role role-name="Employee">
<realm realm-name="public-properties-realm">
<principal class="o.a.g.s.r.p.GeronimoUserPrincipal" name="j2ee"/>
</realm>
</role>
</role-mappings>
</security>
</xattibute>
This satisfies my insistence on no-mixed content, and IMO would be possible to implement. It still has the problem that the xml-attribute element will have to contain an "any" thus making it impossible to check if you put the right kind of document in there without loading it into the gbean you are configuring.
However, I wonder if this is really a good way to approach this. Why wouldn't we prefer a builder that reads, in this case, a security config document and generates gbeanDatas from it? Rather than trying to break up the concepts into independent single-gbean sized pieces, wouldn't it provide a better administrator experience to have a single schema for the entire area you are trying to configure? Such a schema can make sure that you are setting up corresponding gbeans, set relationships, etc etc and generally work better.
thanks david jencks
-dain
