Where does the legacy system property reference/property edi

[starksm64]

I mentioned this once, but want to finalize where support for constructs like the following belong:

 <thing ...>
 <property name="address">${system.property.name}</property>
 </thing>

Where address is a javabean property of the bean class the thing element maps to, and address is of type java.net.InetAddress.

We can certainly have flags on the jbossxb layer that enable sysytem property replacement on text content and a property editor conversion annotation that would be used in the absence of any more specific setting.

Does this make sense?

[aloubyansky]

I don't mind adding property editors.
Are you also asking for system property replacement? I think, it was you who added system property replacement to jbossxb (SchemaBinding.[is/set]ReplacePropertyRefs(...)).

[adrian.brock]

Currently, I leave system property replacement to JBossXB,
but I do the property editor stuff in the Microcontainer.

You cannot do the property editor stuff in JBossXB since it will break classloader
dependencies.

i.e. You don't even know what you want to do until you parsed the xml
let alone what the correct classloader should be or whether the class is available.

[adrian.brock]

There are also some property editors like the java.util.Properties one
that are currently broken.

They also do system property replacement. Which leads to duplicate replacement.
I currently have a horrible workaround for this in JCA.

[starksm64]

Yes, I remembered I added property replacement stuff while working with jbossxb yesterday.

I agree with the control over the property editor namespace/type system has to be outside of the jbossxb layer.

What I'm driving at is really a schema binding configuration that supports the legacy javabean/property editor semantics to simplify jbossxb default behavior. Maybe this is completely subsumed by the default binding rules of jaxb, but I can't tell you how much I hate having write an xsd schema in order to map a conforming xml fragment to an object model.

Let me give the current usecase. I want to upgrade the xmbean descriptor parsing to allow for arbitrarily complex interceptor definitions. My default usage will generally only involve

<mbean>
 <description>The standard JBoss JNDI naming server with a custom
 ProxyFactoryInterceptor interceptor that does replacement of NamingContext
 objects with the detached invoker proxy.
 </description>

 <descriptors>
 <interceptors>
 <custom1:interceptor code="org.jboss.test.jmx.interceptors.JNDISecurity"
 attr1="some-text1" attr2="some-text2" />
 <custom2:interceptor code="org.jboss.naming.interceptors.ProxyFactoryInterceptor"
 proxyName="some-name">
 <custom2:ctor>...</custom2:ctor>
 </custom2:interceptor>

 <interceptor
code="org.jboss.mx.interceptor.PersistenceInterceptor2" />
 <interceptor code="org.jboss.mx.interceptor.ModelMBeanInterceptor" />
 <interceptor code="org.jboss.mx.interceptor.ObjectReferenceInterceptor" />
 </interceptors>
 </descriptors>
...

The base interceptor element mapping is just a basic no-arg ctor conforming to an interface. The custom1:interceptor is a no-arg ctor with mapping of the attributes to javabean accessors using property editor string to object conversion. The custom2:interceptor is a custom ctor with mapping of the attributes to javabean accessors using property editor string to object conversion.

I don't want to have to write a schema for the custom1 namespace. Is there a way to do this today?

Maybe I'm willing to write one for custom2 if the ctor is too complicated.

[aloubyansky]

What we have today that might help or be a step in that direction is an ability to provide custom element/characters handlers for unresolved elements that constitute a content of any. By unresolved I mean those a schema couldn't be resolved for.

E.g. in webservices, such unresolved elements that are a content of any should be unmarshalled into a DOM structure.
In our implementation, this is done by setting unresolvedElementHandler and unresolvedCharactersHandler on the WildcardBinding that do the job.

[starksm64]

Ok, so it seems like if we can combine the following:

- Ability to plugin in SchemaBinding for namespaces via the SchemaBindingInitializer
- An extension of SchemaBindingInitializer, DynamicSchemaBindingInitializer that allows for parse time resolution of the binding. Maybe this is already supported. I need to look more at the org.jboss.kernel.plugins.config.xml.JavaBeanSchemaInitializer as an example.

then I could write the schemaless document as:

 <descriptors>
 <interceptors>
 <custom1:interceptor xlms:custom1="urn:jboss:javabean:1.0"
 code="org.jboss.test.jmx.interceptors.JNDISecurity"
 attr1="some-text1" attr2="some-text2" />
 <custom2:interceptor xlms:custom2="urn:jboss:javabean:2.0"
 code="org.jboss.naming.interceptors.ProxyFactoryInterceptor"
 proxyName="some-name">
 <custom2:ctor>...</custom2:ctor>
 </custom2:interceptor>
...

What we are doing is programming in xml where each custom namespace represents a fragment conforming to binding pattern rather than a fragment conforming to a schema.

With this model the unresolved elements would be a special case of an application usage where they decided not to specify a namspace binding pattern, most likely because they have to use the DOM model due to legacy issues.

[aloubyansky]

I was actually going to add at some point schema-less binding with current/JAXB default binding rules. It existed in earlier prototypes but not in the one that survived.