Recent tests

[adrian.brock]

Although I discussed it privately with Alex, this covers the recent tests
I submitted for JBossXB point out some problems.

AnyComplexTypeUnitTestCase:
This shows the problem with duplicate wildcard processing
and needs to be fixed so I can use SchemaBindings to handle things
like the invoker proxy binding config that has specific xml but also
allows a generic dom element.

SimpleContentUnitTestCase
This shows the problem with subclassing simple types
for which the workaround is to set the type not to construct the object at startElement

CollectionOverridePropertyUnitTestCase
This shows the problem where even if you override the behaviour with an
interceptor, the RtElementHandler still gets confused and wants to do some
of the work itself. The only generic workaround is to name the class fields
the same as the xml elements

DuplicateInterceptorUnitTestCase
This shows the problem for which Scott did a recent fix, but it doesn't work
in the generic case.
In this case that fails, I have two parents sharing the same child type
and both interceptors are invoked when only one should be!

[aloubyansky]

I've been looking into the AnyComplexTypeUnitTestCase. One issue related to the test was fixed in JBossXB. The other one is the way the binding is configured in the test itself.
Specifically, it's the use of type.setStartElementCreatesObject(false). It's always true for the complex types or types that are supposed to have child values.
Following that, in the testcase it should be true (i.e. not set to false). I'll add a javadoc description to clarify that.
This is the diff with an example of a correct binding to make the test pass:

$ svn diff test/
Index: test/java/org/jboss/test/xml/AnyComplexTypeUnitTestCase.java
===================================================================
--- test/java/org/jboss/test/xml/AnyComplexTypeUnitTestCase.java (revision 2184)
+++ test/java/org/jboss/test/xml/AnyComplexTypeUnitTestCase.java (working copy)
@@ -34,6 +34,7 @@
 import org.jboss.xb.binding.metadata.ValueMetaData;
 import org.jboss.xb.binding.sunday.unmarshalling.CharactersHandler;
 import org.jboss.xb.binding.sunday.unmarshalling.DefaultElementInterceptor;
+import org.jboss.xb.binding.sunday.unmarshalling.DefaultHandlers;
 import org.jboss.xb.binding.sunday.unmarshalling.ElementBinding;
 import org.jboss.xb.binding.sunday.unmarshalling.ParticleBinding;
 import org.jboss.xb.binding.sunday.unmarshalling.ParticleHandler;
@@ -155,15 +156,24 @@

 DOMUnresolvedHandler unresolved = new DOMUnresolvedHandler();
 TypeBinding type = schema.getType(new QName(NS, "any-complexType"));
- type.setStartElementCreatesObject(false);
+ //type.setStartElementCreatesObject(false);
+ type.setHandler(new DOMUnresolvedHandler()
+ {
+ public void setParent(Object parent, Object o, QName qName, ParticleBinding particle,
+ ParticleBinding parentParticle)
+ {
+ DefaultHandlers.ELEMENT_HANDLER.setParent(parent, o, qName, particle, parentParticle);
+ }
+ }
+ );
 WildcardBinding wild = type.getWildcard();
 assertNotNull(wild);
 wild.setUnresolvedElementHandler(unresolved);
 wild.setUnresolvedCharactersHandler(unresolved);

- DOMInterceptor interceptor = new DOMInterceptor();
- element = schema.getElement(new QName(NS, "element"));
- element.pushInterceptor(interceptor);
+ //DOMInterceptor interceptor = new DOMInterceptor();
+ //element = schema.getElement(new QName(NS, "element"));
+ //element.pushInterceptor(interceptor);

 Top top = (Top) unmarshal("AnyComplexTypeFromMultipleWildCardAndElement.xml", schema, Top.class);
 Element dom = top.element;

The snapshot in the repository hasn't been updated yet.

[aloubyansky]

SimpleContentUnitTestCase

It fails because by default each complex type is supposed to be bound to a non-primitive Java class. If the class cannot be resolved then a warning or an error is reported depending of the value of ignoreUnresolvedFieldOrClass.
But, specifically for the xsd:ID, I am going to make an exception in the form of a config option. If you have other suggestions, please, share.

[adrian.brock]

I'd say for the simple types that if the complex type is just an extension
of the simple types to add attributes and it can't find a binding then it should
unmarshall as the simple type.

Something like:
1) Real Complex type - error
2) Complex type extends simple - try to unmarshall as simple type if it can't find the model class
3) Plain simple type - as now

Maybe you could add an option to the schema to enable the (2) processing
for backwards compatibility?
e.g.
SchemaBinding.setUnmarshalSimpleComplexTypeAsSimpleTypeWhenNoMapping(true);

Although, if the intention was really to map to a real type its going to be raised
as an IllegalArgumentException on the setter anyway.

[aloubyansky]

For the 2), if all the attributes are optional then yes. And also if the complex type with simple content doesn't have a ClassMetaData associated with it (we have a testcase for this already).

[aloubyansky]

Just wanted to add, attributes of type xsd:ID are optional.

[aloubyansky]

I've implemented handling of complex type with simple content that have only attributes of type xsd:ID as simple types. And created a config option for this simpleContentWithIdAsSimpleType which is true by default. But if there is a ClassMetaData associated with the type, the value of the option is ignored.

I don't like the fall back approach, i.e. if the type is complex and the class resolution failed then try handling it as a simple type. Is there a real use-case where it's useful?

Haven't committed yet. Still thinking.

[aloubyansky]

Ok, committed.

[aloubyansky]

CollectionOverridePropertyUnitTestCase

I don't think the behavior is wrong. Interceptors are executed before the handler, not instead of. AFAICS, you want to change the behavior of the handler's setParent. For that, you have to set the handler, not add interceptors. Or add property metadata instead.

[adrian.brock]

It isn't possible because the child needs to be injected into two different parents.
See the other duplicate interceptors test.

Well, it is possible, but you have to do a horrible case statement (knowing all
possible parents) like:
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/kernel/src/main/org/jboss/kernel/plugins/deployment/xml/ValueElementInterceptor.java

This might be ok when you are dealing with a single model, but when
you are trying to generate the model from annotations on a class it becomes
very messy, if possible at all?

[aloubyansky]

I don't see how it would help even if it worked with the interceptor for the CollectionOverridePropertyUnitTestCase.


For the DuplicateInterceptorUnitTestCase, I agree, it's useful to be able to define interceptors/metadata per use of a binding, not only its global definition.
And I don't agree with Scott's "fix" to ignore addition of a duplicate interceptor. The client code should be fixed in this case.

[aloubyansky]

For the CollectionOverride test you would have probably like to leave setParent empty in the handler then and rely on interceptors.

[aloubyansky]

There should be a way to set default handlers per schema rather than using static DefaultHandlers as it is now.

[aloubyansky]

Extending RtElementHandler and leaving setParent empty won't help right now. An exception will be thrown from the startParticle during field resolution for the child.
The parent is recognized as an array wrapper type and handled specially.

[aloubyansky]

CollectioOverridePropertyUnitTestCase is fixed now (JBXB-93).
Adrian, you were right in that interceptor.add() overrides handler.setParent(). I apologize.
I guess the reason I got confused is that it works not the way I would like to :) It would be better to have use-local metadata/interceptor/handlers that could override their global defaults.