cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Continued trimming of Aegis
Date Wed, 02 Sep 2009 00:51:28 GMT
Apologies if this proves less that coherent.

As it was first built, Aegis centered around a map that connected Java types
(specified as Class objects) and Aegis 'Type' objects. A type object does
reading and writing.

Obviously, such a system will treat all List<x> objects as the same thing.

Pre-Java-5, Aegis supported List and Map via XML specs that stated, for a
particular method parameter or bean property, what to use as the list
component or map key and value. In this situation, instead of using a
generic Aegis Type object, a new one gets instantiated and hung onto by
either the service model (for a parameter) or the 'BeanType' object.

For Java5, this was enhanced with code that would look at the
java.lang.reflect.Type information to obtain the same information.

The type mapping is also used to get from xsi:type attributes to types. In
the generic case, this leads to a somewhat incoherent situation. The type
mapping is bidirectional: it can map a type QName to an Aegis type, or a
Class to an Aegis type. For these filled-in generics, they fight with each
other in the type mapping to map the Class, but they they can be unique in
the QName direction. This more or less works, since the xsi type reading
case only looks up by qname, and, when writing, the specific Aegis Type is
available and need not be obtained from the map.

Due to the duel over the Class slot in the map, there has been internal
disagreement in the code over whether these specific types get registered or

My nose has been rubbed in all of this by the JAX-RS situation. JAX-RS wants
to be able to read a message, specifying what to read via both a Class and a
full java.lang.reflect.Type -- in other words, a full generic.

Now, if the map mapped 'Type' instead of 'Class', it would seem possible to
make all this cohere. List<a>, List<b>, and List<c> could all be distinctly

However, working with java.lang.reflect.Type and it's subclasses is not so
easy. The API has some gaps. In particular, I see no way to get from
"java.util.List' and "java.lang.Integer" to a ParmeterizedType object for
List<Integer>. I feel as if I must be missing something, since javac must do
something like this somehow.

So, say that I wanted to move Aegis to book-keeping in Type. There are
plenty of things that happen that require Class. Things get newInstanced,
for example. So in some places it would be critical to have both a Type and
a Class, or at least to have a very convenient utility for the rigamarole to
get from one to the other.

If I can't manufacture a ParameterizedType on demand, I have to either get
rid of the old Java 1.4 support for properties of naked collection types
with XML to fill in, or I need some object that is the 'union' of a Type and
a manual description to use in mapping.

Before I do either of this things, I thought I'd see if anyone else knows a
better way.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message