On Feb 23, 2005, at 1:53 PM, David Jencks wrote:
On Feb 23, 2005, at 11:53 AM, Dain Sundstrom wrote:
<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.
Are you sure? In the example above I put a security element using security namespace. I would assume that the xml parser would verify that the security element is internally consistent. Now that would not assure me that the component wasn't looking for say an ActiveMQ queue configuration element.
I suppose that if we went down this path, we would want something like the java beans property editors that took an xml dom (or XmlObject) and created java object, and that may be too much work for the effort....
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.
Good point. I'm not sure. As an administrator, I hate the idea of an Easter egg hunt, and would personally like a single document with many internal types. On the other hand, I really don't like the idea of having a (in this case) a security descriptor as an attribute.
Building on David Blevins idea from earlier and using the example above, it would nice to be able to have a plain old security descriptor in the plan without any wrapper. In that case you would have your gbeans and then several xs:any types. At deployment time, we would look up a handler for the unknown element based on the namespace. The handler would get the element and the deployment context. Having deployment plugin support for all of our standard descriptors would be very powerful.
-dain
