posted 11 years ago
Now I understand your problem better.
Probably Responce.entity does not use any information about generic types. It use actual values to create an output. I think it makes no difference to write a List<Object> or a List<Server> if they contains same values. You may safely create a list of Objects and pass it to a writer.
Or, as I said, you may create a some kind of a "type-safe" handler passing a bean class to a handler constructor. Thus a handler will be parametrized with a bean class and some metadata (such as a table name, etc...). It may even resolve bean fields at an instantiation time to reduce reflection overhead. And in a bean configuration you just use a Class<?>.
Something like
But you may be unlucky. While I wrote an example I found an anonymous inner class (child of GenericEntity). It is a bad sign. It may mean that Response actually uses generic type info. And it is a common trick to create an anonymous class to catch actual generic arguments type.
Let's clarify a difference. When you have an instance of GenericEntity<T> (but not of a child class) then you can not exctract any concrete value of type T. This kind of types is erased at runtime. But then you can create a non-generic child class. This is a brand new class (and also a new type). In this class you may extract information about "generic" parent type. Yes, this class inherits its implementation from it parent (and actually an "erased" class is it's parent). But this new class have information about how it's generic types relates with a parent generic types. For example, using Class.getGenericSuperclass you may know, which arguments was passed to a parent class. If child is a generic class itself this information may contain references to this child type arguments. But since child is a concrete (although anonymous) class, it has no type arguments and genericSuperclass will have all fields as "concrete values".
Just repeat following thought in other words. There is no difference between different instantiations of a same type. They are all same ".class" at a run-time. And because there is no difference, you cannot create a new "instance" of a generic type at a runtime. But you can extract information parent's type arguments form a child type. And, of course, different children (anonymous inner classes still are childern) are different classes (each children have it's own class file). So, creating child classes may be a solution.
Wrapping things up. You cannot create an instance of a "generic" type. But even you are unlucky, you still may handle a situation! Now you know, that some information is saved in child classes. So you need to generate two classes. One class for a bean. And other for a child class which can store generic information. Try to find a class named like ServersResource$GenericEntity$1.class or ServersResource$1.class in your compiled output (sorry, I forgot a proper naming scheme for an anonymous inner classes. But they are clearly distinguishable by suffixed like $<number>). You second generated class should be similar to that anonymous child (of course, using a properly constructed general type argument).
And you handler will be like this:
All required information can be extracted now from new wrapper class (which is a child to a GenericEntity). Yes, you now need to create two class files (one for bean and one for wrapper). And generation of proper wrapper is not easy (generic type info is ignored at a runtime in most JVM parts and generic signatures are not easy by itself). But if you have no other choices, this is doable. And you may generate a non-anonymous (named) descendant from a GenericEntitiy if it is simplier, JVM does not distinguish anonymous and named classes (all classes have it's name in JVM).
P.S. Among other choices there is a possibility to not to use a CXF and create own writer. In this case you map store table data as a list of simple hashmaps and serialize it using via a custom writer. But it may be not possible. And some libraries provides a way to construct "generic type" representation itself in some form (so you pass a "type" object and a value object).
P.P.S. Primary tool for analyzing existing bytecode files (including anonymous classes) is javap, which is included in JDK. You may use it to look up signatures in that anonymous inner classes and use it as a guide in a generating you new wrapper types.