From: <sco...@jb...> - 2005-05-11 14:59:31
|
I don't see a problem with needing to create holder objects. The main advantage is that they give you a type explicit representation of the stack as opposed to having to know the types and order of the stack. An example I have that has a clean ObjectModelFactory view is the org.jboss.security.auth.login.LoginConfigObjectModelFactory. Here the javax.security.auth.login.AppConfigurationEntry that is represented in the xml config cannot be constructed incrementally as a java bean because it has no setters. All data must be passed in via the ctor. There is an example of such a document with the associated xsds in jboss-head/testsuite/src/resources/xml/mbeanserver: | [starksm@banshee9100 jboss-4.0]$ ls -l jboss-head/testsuite/src/resources/xml/mbeanserver/ | total 10 | drwxrwxrwx+ 2 starksm None 0 May 3 18:12 CVS/ | -rwxrwxrwx 1 starksm None 1879 May 3 18:14 login-config2.xsd* | -rwxrwxrwx 1 starksm None 1599 May 3 18:14 mbean-service_1_0.xsd* | -rwxrwxrwx 1 starksm None 3370 May 3 18:14 testObjFactory.xml* | -rwxrwxrwx 1 starksm None 1040 May 3 18:14 user-roles.xsd* | I think the general extension to jaxb that we need is the notion of a holder object that is a java bean which can be constructed via standard jaxb rules or customizations + a mapping of that holder into the actual object. The mapping could be specified via simple transform/factory interface. The authentication type in the login-config2.xsd could be customized using something like: | <xs:complexType name="authentication"> | <xs:annotation> | <xs:appinfo> | <jbossxb:factory | name="org.jboss.security.auth.login.LoginConfigFactory" | holderClass="org.jboss.security.auth.login.AppConfigurationEntryHolder" | /> | </xs:appinfo> | </xs:annotation> | ... | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877347#3877347 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877347 |