Re: JAX-RS and generics
On Sat, Sep 5, 2009 at 1:57 PM, Benson Margulies wrote:
> JAX-RS defines two fundamental interfaces: MessageBodyReader and
> MessageBodyWriter, and providers implement.
>
> I claim that GENERIC providers that work for any object (like those
> corresponding to data bindings) should, themselves, be GENERIC, and
> implement MessageBodyX, not MessageBodyX.
>
Allow me to modulate this claim. I thought about it some more.
If you want to define a class as 'implements MessageBodyX', fine.
However, the right thing to pass to the Class argument will ALWAYS be
Object.class. If you want to cue in the code to the sort of object in
flight, use the Type argument further down the parameter list.
>
> I claim this because the whole API structure of MessageBodyX assumed this.
> It uses Class in a way that requires constant
> @SupressWarnings("unchecked") if the base is MessageBodyX.
>
> To put my money where my mouth is, as it were, I implemented this for the
> Aegis providers. When I did this, I discovered that the JAX-RS runtime code
> couldn't handle generic type providers. When the provider type is, say,
>
> AegisElementProvider
>
> then implemented interface comes up as MessageBodyReader, not
> MessageBodyReader. So it is a TypeVariable, not a class or a
> ParameterizedType.
>
> I fixed the provider selection code to cope, but I didn't write the
> additionally complex code to look at bounds and insist that if there is a
> bound the type at hand be within it.
>
Possible alternative source of JSON
http://wiki.fasterxml.com/JacksonInFiveMinutes It looks to me as if a Jackson 'provider' would be a pretty straightforward construction. To be clear, there's be no CXF DataBinding in the process at all. Jackson maps pojos to JSON and vica versa. The plus side of this is that it would yield, if successful, 'natural' json, unencrusted with namespace glop, in both directions. The minus side of this would be that it doesn't help those people who want a JSON JAX-RS endpoint as a sort of instant side-effect of their preexisting stack of JAXB @nnotations or Aegis XML files or whatever. Personally, I think that I'd be coding something a whole lot more useful by adding this than by putting more lipstick on the pig of producing and consuming extremely ugly JSON via Aegis. Admittedly, 'unqualified' Aegis would be helpful, but if Jackson already does the job, why do all that work? Not to mention the fact that Tatu is likely to prove responsive in case of need.
JAX-RS and generics
JAX-RS defines two fundamental interfaces: MessageBodyReader and
MessageBodyWriter, and providers implement.
I claim that GENERIC providers that work for any object (like those
corresponding to data bindings) should, themselves, be GENERIC, and
implement MessageBodyX, not MessageBodyX.
I claim this because the whole API structure of MessageBodyX assumed this.
It uses Class in a way that requires constant
@SupressWarnings("unchecked") if the base is MessageBodyX.
To put my money where my mouth is, as it were, I implemented this for the
Aegis providers. When I did this, I discovered that the JAX-RS runtime code
couldn't handle generic type providers. When the provider type is, say,
AegisElementProvider
then implemented interface comes up as MessageBodyReader, not
MessageBodyReader. So it is a TypeVariable, not a class or a
ParameterizedType.
I fixed the provider selection code to cope, but I didn't write the
additionally complex code to look at bounds and insist that if there is a
bound the type at hand be within it.
JSON + Aegis + JAX-RS: Not?
Well, so, I've been working on the soggy saga of JAX-RS + Aegis + Jettison. I won't repeat other recent messages too much. Aegis likes to write namespaces. There is no option to use it unqualified. Jettison is really weak on namespaces. It someone to know all the namespaces and prefixes in advance of creating a StaX stream. That's not very realistic for Aegis. Jettison doesn't write out the definition of namespaces for you. You tell it that namespace X maps to prefix P, and it writes strings of the form P., and never writes a definition of P. I have danced around all of this by making the JAX-RS Aegis provider write to DOM first, and then collect all the namespace prefixes, and then push it to jettison. I have no idea how to make the read side work consistently in any non-brittle way. Given that any sort of object, in any package, could turn up as a subclass, there's just no way to know what all the namespaces will be in advance. More to the point, when reading, seeing 'ns3.bloop', there's no way to tell what namespace should go with ns3. Very simple cases work where there's only one namespace. This might be addressed by prefixing an actual namespace map, and reading it. Alternatively, we could use a completely different scheme for handling namespaces than Jettison. Instead of adding prefixes to the element names, put them all in attributes (say, well, 'xmlns' attributes, by URI). Then we wouldn't lose any information. It could be argued that this combination is just a really bad idea. If you want JSON, you want a binding that can do unqualified elements. And if the DOSGi gang wants to avoid JAX-B that badly, perhaps someone from in there would like to add unqualified support to Aegis?
StaxUtils.copy
This doesn't write END_DOCUMENT events to the output?
Re: Have we got a new maven dependency ?
On Sat September 5 2009 9:49:57 am Benson Margulies wrote:
> The quickest path to failure is:
>
> mvn clean
> mvn -Pfastinstall,setup.eclipse
You probably needed:
mvn install -Pfastinstall,setup.eclipse
setup.eclipse resets the default target to process-test-sources so the plugin
probably wasn't installed.
Dan
>
> On Sat, Sep 5, 2009 at 9:37 AM, Christian Schneider
>
> > wrote:
> >
> > So mvn install worked and mvn -Pfastinstall did not work?
> >
> >
> > Greetings
> >
> > Christian
> >
> > Benson Margulies schrieb:
> >> Something is wrong with the 'fastinstall' profile. Maybe it doesn't
> >> rebuild
> >> the codegen?
> >>
> >> On Sat, Sep 5, 2009 at 9:02 AM, Christian Schneider <
> >> ch...@die-schneider.net
> >>
> >>> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Hi Benson,
> >>>
> >>> I have added this dependency. It is used to pull wsdl files from the
> >>> maven
> >>> repo.
> >>> (see https://issues.apache.org/jira/browse/CXF-2275)
> >>>
> >>> I have added the following dependencies to the codegen plugin:
> >>>
> >>>
> >>> org.apache.maven
> >>> maven-core
> >>> provided
> >>>
> >>>
> >>> org.apache.maven
> >>> maven-artifact
> >>> provided
> >>>
> >>>
> >>>
> >>>
> >>> Did I forget to include something to make the build work? A complete
> >>> build
> >>> seems to run without problems.
> >>>
> >>> Greetings
> >>>
> >>> Christian
> >>>
> >>>
> >>> Benson Margulies schrieb:
> >>>
> >>> INFO] [antrun:run {execution: validate}]
> >>>
> [INFO] Executing tasks
> [INFO] Executed tasks
> [INFO] Registering compile source root
> /Users/benson/asf/cxf/testutils/target/generated/src/main/java
> [INFO] [cxf-xml2fastinfoset:xml2fastinfoset {execution:
> xml2fastinfoset}]
> [INFO]
> --
> -- [ERROR] FATAL ERROR
> [INFO]
> --
> -- [INFO] Unresolved compilation problems:
> The import org.apache.maven.execution cannot be resolved
> MavenSession cannot be resolved to a type
> MavenSession cannot be resolved to a type
>
> [INFO]
> --
> -- [INFO] Trace
> java.lang.Error: Unresolved compilation problems:
> The import org.apache.maven.execution cannot be resolved
> MavenSession cannot be resolved to a type
> MavenSession cannot be resolved to a type
>
> at
> org.apache.cxf.maven_plugin.WSDL2JavaMojo.(WSDL2JavaMojo.java:40
> )
>
--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog
Re: Have we got a new maven dependency ?
The quickest path to failure is:
mvn clean
mvn -Pfastinstall,setup.eclipse
On Sat, Sep 5, 2009 at 9:37 AM, Christian Schneider wrote:
> So mvn install worked and mvn -Pfastinstall did not work?
>
>
> Greetings
>
> Christian
>
> Benson Margulies schrieb:
>
>> Something is wrong with the 'fastinstall' profile. Maybe it doesn't
>> rebuild
>> the codegen?
>>
>> On Sat, Sep 5, 2009 at 9:02 AM, Christian Schneider <
>> ch...@die-schneider.net
>>
>>
>>> wrote:
>>>
>>>
>>
>>
>>
>>> Hi Benson,
>>>
>>> I have added this dependency. It is used to pull wsdl files from the
>>> maven
>>> repo.
>>> (see https://issues.apache.org/jira/browse/CXF-2275)
>>>
>>> I have added the following dependencies to the codegen plugin:
>>>
>>>
>>> org.apache.maven
>>> maven-core
>>> provided
>>>
>>>
>>> org.apache.maven
>>> maven-artifact
>>> provided
>>>
>>>
>>>
>>>
>>> Did I forget to include something to make the build work? A complete
>>> build
>>> seems to run without problems.
>>>
>>> Greetings
>>>
>>> Christian
>>>
>>>
>>> Benson Margulies schrieb:
>>>
>>> INFO] [antrun:run {execution: validate}]
>>>
>>>
[INFO] Executing tasks
[INFO] Executed tasks
[INFO] Registering compile source root
/Users/benson/asf/cxf/testutils/target/generated/src/main/java
[INFO] [cxf-xml2fastinfoset:xml2fastinfoset {execution:
xml2fastinfoset}]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Unresolved compilation problems:
The import org.apache.maven.execution cannot be resolved
MavenSession cannot be resolved to a type
MavenSession cannot be resolved to a type
[INFO]
[INFO] Trace
java.lang.Error: Unresolved compilation problems:
The import org.apache.maven.execution cannot be resolved
MavenSession cannot be resolved to a type
MavenSession cannot be resolved to a type
at
org.apache.cxf.maven_plugin.WSDL2JavaMojo.(WSDL2JavaMojo.java:40)
>>>
>>>
>>
>>
>>
>
>
Aegis + JSON = Chaos in namespaces
I've convinced myself that the implementation of aegis+json for JAX-RS, with respect to namespaces, has absolutely got to change. Let me lay out the situation as I see it. When we are writing XML, Aegis assigns prefixes on the fly, though it will respect a map of preferred prefixes. These prefixes are fed to StaX, incrementally, and all is well. The Jettison implementation of the StaX API is badly crippled with respect to namespaces. It ignores setPrefix, and will throw an unchecked exception in the presence of any namespace that is not defined, in advanced, in the 'Convention' object. In my tree at the moment, I've gotten around this by subclassing the Jettison MappedXMLStreamWriter and handling the exception and respecting the available prefix. However, this only moves the problem down the pipe. It would be cleaner to write, say, a DOM tree, then collect all the prefixes, and then put them in Jettison's stupid map, and then copy from the DOM tree to Jettison. Slower but cleaner. The result of all of this is json that has undefined namespace prefixes. The json keys just look like 'ns1.HereIsMyObject'. Nothing is written to in the JSON that defines what namespace 'ns1' is. Instead, the code sort of takes it on faith that 'ns1' will be the prefix for the top-level element, and defines no other prefixes. The code to derive that namespace is wrong, and I can fix it, but that won't make the unbounded collection of other prefixes for other schema appear by magic. Part of the problem here is that the flags to write XSI types are turned off, at least in the test case I'm working with. Still, I don't see how it can be interoperable to write out these prefixes without definitions if we expect to get them back.
Re: Have we got a new maven dependency ?
So mvn install worked and mvn -Pfastinstall did not work?
Greetings
Christian
Benson Margulies schrieb:
Something is wrong with the 'fastinstall' profile. Maybe it doesn't rebuild
the codegen?
On Sat, Sep 5, 2009 at 9:02 AM, Christian Schneider
wrote:
Hi Benson,
I have added this dependency. It is used to pull wsdl files from the maven
repo.
(see https://issues.apache.org/jira/browse/CXF-2275)
I have added the following dependencies to the codegen plugin:
org.apache.maven
maven-core
provided
org.apache.maven
maven-artifact
provided
Did I forget to include something to make the build work? A complete build
seems to run without problems.
Greetings
Christian
Benson Margulies schrieb:
INFO] [antrun:run {execution: validate}]
[INFO] Executing tasks
[INFO] Executed tasks
[INFO] Registering compile source root
/Users/benson/asf/cxf/testutils/target/generated/src/main/java
[INFO] [cxf-xml2fastinfoset:xml2fastinfoset {execution: xml2fastinfoset}]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Unresolved compilation problems:
The import org.apache.maven.execution cannot be resolved
MavenSession cannot be resolved to a type
MavenSession cannot be resolved to a type
[INFO]
[INFO] Trace
java.lang.Error: Unresolved compilation problems:
The import org.apache.maven.execution cannot be resolved
MavenSession cannot be resolved to a type
MavenSession cannot be resolved to a type
at
org.apache.cxf.maven_plugin.WSDL2JavaMojo.(WSDL2JavaMojo.java:40)
Re: Have we got a new maven dependency ?
Something is wrong with the 'fastinstall' profile. Maybe it doesn't rebuild
the codegen?
On Sat, Sep 5, 2009 at 9:02 AM, Christian Schneider wrote:
> Hi Benson,
>
> I have added this dependency. It is used to pull wsdl files from the maven
> repo.
> (see https://issues.apache.org/jira/browse/CXF-2275)
>
> I have added the following dependencies to the codegen plugin:
>
>
> org.apache.maven
> maven-core
> provided
>
>
> org.apache.maven
> maven-artifact
> provided
>
>
>
>
> Did I forget to include something to make the build work? A complete build
> seems to run without problems.
>
> Greetings
>
> Christian
>
>
> Benson Margulies schrieb:
>
> INFO] [antrun:run {execution: validate}]
>> [INFO] Executing tasks
>> [INFO] Executed tasks
>> [INFO] Registering compile source root
>> /Users/benson/asf/cxf/testutils/target/generated/src/main/java
>> [INFO] [cxf-xml2fastinfoset:xml2fastinfoset {execution: xml2fastinfoset}]
>> [INFO]
>>
>> [ERROR] FATAL ERROR
>> [INFO]
>>
>> [INFO] Unresolved compilation problems:
>>The import org.apache.maven.execution cannot be resolved
>>MavenSession cannot be resolved to a type
>>MavenSession cannot be resolved to a type
>>
>> [INFO]
>>
>> [INFO] Trace
>> java.lang.Error: Unresolved compilation problems:
>>The import org.apache.maven.execution cannot be resolved
>>MavenSession cannot be resolved to a type
>>MavenSession cannot be resolved to a type
>>
>>at
>> org.apache.cxf.maven_plugin.WSDL2JavaMojo.(WSDL2JavaMojo.java:40)
>>
>>
>>
>
>
Re: Have we got a new maven dependency ?
Hi Benson,
I have added this dependency. It is used to pull wsdl files from the
maven repo.
(see https://issues.apache.org/jira/browse/CXF-2275)
I have added the following dependencies to the codegen plugin:
org.apache.maven
maven-core
provided
org.apache.maven
maven-artifact
provided
Did I forget to include something to make the build work? A complete
build seems to run without problems.
Greetings
Christian
Benson Margulies schrieb:
INFO] [antrun:run {execution: validate}]
[INFO] Executing tasks
[INFO] Executed tasks
[INFO] Registering compile source root
/Users/benson/asf/cxf/testutils/target/generated/src/main/java
[INFO] [cxf-xml2fastinfoset:xml2fastinfoset {execution: xml2fastinfoset}]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Unresolved compilation problems:
The import org.apache.maven.execution cannot be resolved
MavenSession cannot be resolved to a type
MavenSession cannot be resolved to a type
[INFO]
[INFO] Trace
java.lang.Error: Unresolved compilation problems:
The import org.apache.maven.execution cannot be resolved
MavenSession cannot be resolved to a type
MavenSession cannot be resolved to a type
at
org.apache.cxf.maven_plugin.WSDL2JavaMojo.(WSDL2JavaMojo.java:40)
Generics and JAX-RS API
public abstract class AbstractAegisProvider implements MessageBodyReader, MessageBodyWriter It seems to me that this is supposed to be . This is resulting in warnings that need to be suppressed for any type that isn't precisely Object.
Re: Handling collections with Aegis in JAX-RS
Sergey, I've made it as far as the namespace issues with JSON, since the changes I've made to deal with generic types have made them worse. There's something here that I just don't follow. When the output is XML, all the namespaces just take care of themselves. Aegis assigns prefixes and StaX writes them. Admittedly, if Aegis ever forgot to assign a prefix StaX would just go add an xmlns=, but I don't (yet) think that this is something that happens. Do you have any idea why the JSON environment ends up being so much more fussy? --benson On Mon, Aug 24, 2009 at 8:58 AM, Sergey Beryozkin wrote: > > Hi Benson > > Thanks for spending your time on these tests, and fixing CXF 2401. I was > also able to add few more tests, including the one which writes/reads a > complex Map to/from JSON. > > AegisJSONProvider tries its best for users to avoid setting up a namespace > map manually, but in cases when it does not guess properly the users would > be able to overwrite namespaces and their prefixes as needed. This isssue > would likely arise on the read side only, when CXF reads it. JSON is > namespace-unaware so when reading, one needs to setup a namespace map for > Jettison to report values like @ns1.bar to the JAXB reader... (but only if > AegisJSONProvider has not guessed how to map prefixes to namespaces) > > There's a couple of issues I'd like to discuss. First one is that > AegisJsonProviderTest.testReadWriteComplexMap does have to setup a > namespace > for a map root element, but it does not have to do it for > testWrite/ReadCollection tests. I'm wondering, can it be avoided in cases > when Maps are being written/read ? That is, can we modify > createReader/Writer methods such that QNames for containers like > Map/Collections and its member types are available ? > > Another one is that DataBindingJSONProvider test (aegis tests) still can > not > handle collections. I think the problem there is that when > DataBindingProvider (the one DataBindingJSONProvider extends) is being > initialized, it uses a workaround which we discussed in the other thread. > Namely, it attempts to convert a JAXRS model info into WSDL-like one and > set > calls DataBinding.initialize(Service). It's quite limiting for a number of > reasons, and one of them is that the generic types are not visible to data > bindings > So we introduced PropertiesAwareDataBinding interface and I've just updated > the JAXRS code to call it like this : > > Map, Type> allClasses = getAllJAXRSResponseInputTypes(); > Map props = new HashMap(); > props.put(PropertiesAwareDataBinding.TYPES_PROPERTY, allClasses); > ((PropertiesAwareDataBinding)db).initialize(props); > > At the moment no CXF DataBindings implement this newly introduced > interface. > I think the only way for DataBindingJSONProvider aegis tests which handle > collections to start passing is for Aegis DataBinding to implement > PropertiesAwareDataBinding and initialize itself using the provided > Map, Type>, as opposed to Service. Would you be open to updating > the Aegis databinding ? > > thanks, Sergey > > > > > > > > > > > > bimargulies wrote: > > > > I have a rather clear memory of working on these, there wasn't enough > > passing of Generic classes around. I'll go have a look. > > > > > > On Fri, Aug 21, 2009 at 6:38 AM, Sergey > > Beryozkin wrote: > >> > >> Hi Benson > >> > >> if you could look at any of these tests or at least point me in the > right > >> direction then it would be great. > >> I know you're busy - so just look at it whenever you get a chance, not > >> urgent... > >> > >> cheers, Sergey > >> > >> > >> Sergey Beryozkin-2 wrote: > >>> > >>> > >>> > >>> Hi Benson > >>> > >>> I can't make the Aegis tests writing/reading collections working in CXF > >>> JAX-RS. > >>> I've found that AegisProviderTest#testReadWriteComplexMap is still > >>> @Ignored, it might've passed for you because it was @Ignored :-) > >>> > >>> I've also added testWriteCollections() (which writes > >>> List) > >>> to AegisJSONProviderTest. I also updated DataBindingJSONProviderTest, > >>> one > >>> of its internal classes to return List. AegisJSONProvider extends > >>> AegisElementProvider, DataBindingJSONProvider extends > >>> DataBindingProvider > >>> which actually (in this case) delegates to Aegis DataBinding. > >>> > >>> AegisJSONProviderTest fails at the write time, it can't find the > mapping > >>> for List. DataBindingJSONProviderTest fails early at the Aegis > >>> DataBinding > >>> initialization time for the same reason. I thought Lists were supported > >>> by > >>> default ? I haven't found any exam[le showing how a type mapping for > >>> Lists > >>> can be created. > >>> Can you please, whenever you have a chance, have a look at these tests > ? > >>> > >>> thanks, Sergey > >>> > >>> > >> > >> -- > >> View this message in context: > >> > http://www.nabble.com/Handling-collections-with-Aegis-in-JAX-RS-tp24933144p25076146.html > >> Sent from the cxf-dev mailing list archive at Nabble.com.
codegen problems
I found that I had to manually go build the codegen-plugin before I could get fastinstall,setup.eclipse to work on trunk.
Have we got a new maven dependency ?
INFO] [antrun:run {execution: validate}]
[INFO] Executing tasks
[INFO] Executed tasks
[INFO] Registering compile source root
/Users/benson/asf/cxf/testutils/target/generated/src/main/java
[INFO] [cxf-xml2fastinfoset:xml2fastinfoset {execution: xml2fastinfoset}]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Unresolved compilation problems:
The import org.apache.maven.execution cannot be resolved
MavenSession cannot be resolved to a type
MavenSession cannot be resolved to a type
[INFO]
[INFO] Trace
java.lang.Error: Unresolved compilation problems:
The import org.apache.maven.execution cannot be resolved
MavenSession cannot be resolved to a type
MavenSession cannot be resolved to a type
at
org.apache.cxf.maven_plugin.WSDL2JavaMojo.(WSDL2JavaMojo.java:40)
