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;

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.

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).

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

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.

Ok, committed.

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.

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.

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

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

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.

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.