geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: New feature: XmlReferenceBuilder, with an example: LoginConfigBuilder
Date Thu, 05 May 2005 14:38:13 GMT

On May 5, 2005, at 6:08 AM, Gianny Damour wrote:

> Hi,
>
> Sorry for this late comment.

So far it's the only comment :-) many thanks!
>
> I must admit that I love and hate at the same time the concept. I love  
> this concept for the same reasons that you have identified; so, I will  
> not re-iterate them. I hate the concept for the following reasons:
>
> As far as I know, this concept is useful only when the reference is  
> used by a single GBean. In the case of two GBeans sharing the same  
> reference, then we will have the choice between: using an  
> xml-reference for the first one and a simple reference of the second  
> one; or using the current approach with one GBean and two references.  
> In the former case, I think that users will copy and past the  
> xml-reference and discover the hard way that this not what they should  
> have done. To some extent, I believe that  this type of mechanism  
> works pretty well for attributes as they are not objects to be shared  
> and that it may not work so well for references;

I agree that there is a significant risk of encouraging people to make  
lots of copies of the same gbean, and actually I didn't implement this  
feature for a long time due to that danger :-)  In this specific case,  
the primary use (IMO) is to generate the LoginModuleUse gbeans which  
are really intended for use only as helpers to a single other gbean  
(GenericSecurityRealm).  Future improvements in reference collections  
might make this unnecessary, but also might not :-)  It's hard to tell  
at this point if a generic collection/list structure can accommodate  
the same level of functionality as a linked list of possibly  
polymorphic gbeans.  In the example, if you only use references to  
login module gbeans rather than embedded definitions of the login  
module gbeans you wont be tempted to copy anything you shouldn't.

>
> Also, this is a door open for the proliferation of "non core" elements  
> as we can put whatever we want inside an xml-reference node.
>
> The declaration of GBean is simple and mechanic:
> <gbean name="MyName" class="some_stuff_there">
>    <attribute name="name_attribute1">the_value_there</attribute>
>    <reference name="name_reference1">and_a_reference_there</reference>
> </gbean>
>
> Another kind of declaration could have been to use gbean, attribute  
> and reference names as element names such as:
> <MyName class="some_stuff_there">
>    <name_attribute1>the_value_there</name_attribute1>
>    <name_reference1>and_a_reference_there</name_reference1>
> </MyName>
> This declaration is cumbersome.

I disagree... I think that such a custom xml format is less cumbersome  
for a specific gbean.  The problem is that you then need a schema and  
namespace for each gbean info, which is cumbersome.  However, if you  
are willing to supply the schema, then you get schema-enforced type  
safety.

I think that for most gbeans the generic format we have works fine, but  
that there are some gbeans where it is just too complicated to expect  
users to configure the gbeans directly.  Indeed all the j2ee components  
are like this: we have custom xml formats for them, namely the j2ee  
deployment descriptors + geronimo plans.  I think the security gbeans  
are another area where there is too much complexity to configure gbeans  
individually and we need a custom xml schema that will automatically  
enforce the necessary constraints through schema validation.  I'm  
hoping that the addition of xml-references can be extended to allow  
"namespace switching" in gbean plans to actually allow what you are  
complaining about :-)
>
> I think that XmlReferenceBuilder is another door open for the  
> proliferation of "non core" elements, which will lead to notations as  
> annoying as the one above.
>
> I think that we can replace:
>            <lc:login-config   
> xmlns:lc="http://geronimo.apache.org/xml/ns/loginconfig">
>                <lc:login-module control-flag="REQUIRED"   
> server-side="true">
>                      
> <lc:login-domain-name>black-login</lc:login-domain-name>
>                     <lc:login-module-  
> class>org.apache.geronimo.security.realm.providers.PropertiesFileLoginM 
> o dule</lc:login-module-class>
>                    <lc:option   
> name="usersURI">var/security/black_users.properties</lc:option>
>                    <lc:option   
> name="groupsURI">var/security/black_groups.properties</lc:option>
>                </lc:login-module>
>            </lc:login-config>
>
> by:
>            <reference-builder   
> xmlns:lc="http://geronimo.apache.org/xml/ns/loginconfig">
>                <attribute name="control-flag">REQUIRED</attribute name>
>                <attribute name="server-side">true</attribute name>
>                <attribute name="domain-name">black-login</attribute  
> name>
>                <attribute  
> name="module- 
> class">org.apache.geronimo.security.realm.providers.PropertiesFileLogin 
> Module</attribute name>
>                <attribute  
> name="usersURI">var/security/black_users.properties</attribute name>
>                <attribute  
> name="groupsURI">var/security/black_groups.properties</attribute name>
>            </reference-builder>

I'm not sure why you like the second better.  It looks to me as if you  
have combined the worst of both worlds: you need a custom builder for  
the gbean to reassemble the options back into a map, and you lose the  
type-safety of a schema adapted to the specific gbean you are  
configuring, thus helping users make configuration errors undetectable  
until deployment.

Many thanks
david jencks
>
> My 2 cents.
>
> Thanks,
> Gianny
>
> On 1/05/2005 5:32 PM, David Jencks wrote:
>
>> While getting annoyed at the zillions of gbeans you need to configure  
>>  to create a complicated login configuration using the new "linked  
>> list"  approach (see GERONIMO-639)  I realized that we could do  
>> something  similar to the XmlAttributeBuilder but for references.
>>
>> So, here's the idea:
>>
>> An XmlReferenceBuilder is registered for an xml namespace.  When the   
>> gbean builder finds an xml-reference element, it looks at the  
>> enclosed  xml "any" element, gets its namespace, and looks for a   
>> XmlReferenceBuilder registered for that namespace.  It then gives the  
>>  XmlObject and the DeploymentContext (and the J2eeContext for   
>> constructing appropriate jsr-77 names) to the XmlReferenceBuilder.   
>> The  builder can look at the xml, configure as many gbeans as it  
>> likes, and  add them to the DeploymentContext.  When it's done, it  
>> returns a Set of  reference patterns to the gbean builder, which  
>> installs the set (if  non-null and non-empty) as the  
>> referencePatterns value.
>>
>> Lets look at the example, LoginConfigBuilder.
>>
>> Configuration of a simple GenericSecurityRealm in only gbeans might   
>> look like this:
>>
>>    <gbean name="black-login"
>>         class="org.apache.geronimo.security.jaas.LoginModuleGBean">
>>         <attribute   
>> name="loginModuleClass">org.apache.geronimo.security.realm.providers.P 
>> ro pertiesFileLoginModule</attribute>
>>         <attribute name="serverSide">true</attribute>
>>         <attribute name="options">
>>             usersURI=var/security/black_users.properties
>>             groupsURI=var/security/black_groups.properties
>>         </attribute>
>>         <attribute   
>> name="loginDomainName">black-properties-realm</attribute>
>>     </gbean>
>>
>>     <gbean name="black-properties-realm"
>>              
>> class="org.apache.geronimo.security.realm.GenericSecurityRealm">
>>         <attribute name="realmName">black-properties-realm</attribute>
>>         <reference name="LoginModuleConfiguration">
>>             <name>black-properties-login</name>
>>         </reference>
>>         <reference   
>> name="ServerInfo"><module>org/apache/geronimo/System</  
>> module><name>ServerInfo</name></reference>
>>     </gbean>
>>
>>     <gbean name="black-properties-login"   
>> class="org.apache.geronimo.security.jaas.JaasLoginModuleUse">
>>         <attribute name="controlFlag">REQUIRED</attribute>
>>         <reference name="LoginModule">
>>             <name>black-properties-login</name>
>>         </reference>
>>     </gbean>
>>
>>
>> Using an xml-reference, one format is:
>>
>>    <gbean name="black-login"
>>         class="org.apache.geronimo.security.jaas.LoginModuleGBean">
>>         <attribute   
>> name="loginModuleClass">org.apache.geronimo.security.realm.providers.P 
>> ro pertiesFileLoginModule</attribute>
>>         <attribute name="serverSide">true</attribute>
>>         <attribute name="options">
>>             usersURI=var/security/black_users.properties
>>             groupsURI=var/security/black_groups.properties
>>         </attribute>
>>         <attribute   
>> name="loginDomainName">black-properties-realm</attribute>
>>     </gbean>
>>
>>     <gbean name="black-properties-realm"
>>              
>> class="org.apache.geronimo.security.realm.GenericSecurityRealm">
>>         <attribute name="realmName">black-properties-realm</attribute>
>>         <reference   
>> name="ServerInfo"><module>org/apache/geronimo/System</  
>> module><name>ServerInfo</name></reference>
>>         <xml-reference name="LoginModuleConfiguration">
>>             <lc:login-config   
>> xmlns:lc="http://geronimo.apache.org/xml/ns/loginconfig">
>>                 <lc:login-module-ref control-flag="REQUIRED">
>>                     <lc:name>black-login</lc:name>
>>                 </lc:login-module-ref>
>>             </lc:login-config>
>>         </xml-reference>
>>     </gbean>
>>
>> However, in this case the xml is a little more flexible and we can   
>> eliminate another separate gbean definition:
>>
>>     <gbean name="black-properties-realm"
>>              
>> class="org.apache.geronimo.security.realm.GenericSecurityRealm">
>>         <attribute name="realmName">black-properties-realm</attribute>
>>         <reference   
>> name="ServerInfo"><module>org/apache/geronimo/System</  
>> module><name>ServerInfo</name></reference>
>>         <xml-reference name="LoginModuleConfiguration">
>>             <lc:login-config   
>> xmlns:lc="http://geronimo.apache.org/xml/ns/loginconfig">
>>                 <lc:login-module control-flag="REQUIRED"   
>> server-side="true">
>>                       
>> <lc:login-domain-name>black-login</lc:login-domain-name>
>>                      <lc:login-module-  
>> class>org.apache.geronimo.security.realm.providers.PropertiesFileLogin 
>> Mo dule</lc:login-module-class>
>>                     <lc:option   
>> name="usersURI">var/security/black_users.properties</lc:option>
>>                     <lc:option   
>> name="groupsURI">var/security/black_groups.properties</lc:option>
>>                 </lc:login-module>
>>             </lc:login-config>
>>         </xml-reference>
>>     </gbean>
>>
>> This still creates the same 3 gbeans as the first example.
>>
>> I've modified the openejb secure-plan.xml used in the itests to use   
>> this new format.
>>
>> I'd appreciate some review of this, both the XmlReferenceBuilder   
>> concept and the LoginConfigBuilder example, before I try to document  
>> it  in the wiki.
>>
>> I think we will be able to write the gbean builder as an   
>> XmlReferenceBuilder that happens to return null.  This might get us  
>> to  the goal of namespace-driven deployment that has been discussed  
>> on and  off for a long time.
>>
>>  many thanks,
>> david jencks
>>
>>
>


Mime
View raw message