Develop Reference

Use Spring-Data-Rest to return response as XML instead of JSON

Spring-data-rest is currently RC1 (heading for GA July 16), but the documentation is still a little sketchy. So far all the example code I find shows responses defaulting to JSON, but I need XML, and ideally either XML or JSON based on ACCEPT header. I found one source in some comments in a DZone link that indicate XML is going to be supported. But that was posted during the M2 release, before RC1. I don't see anything in the Issues under the project either.
So does anybody know how to make either RC1 (or SNAPSHOT) produce XML instead of or in addition to JSON.

I wish there was an easy answer to producing XML in Spring Data REST, but I haven't found one yet. We defaulted to using JSON because we figured that's a super easy and lightweight "protocol" for transmitting objects and will work good enough for most cases.
There are a couple of problems with XML that we haven't found reasonable answers for:
How do I represent an object in XML? Do I use the property name as the element name or do I use a standard element name and put the property name in an attribute?
Where do I identify the type of the property (whether it's complex or simple, a Long, a BigInteger or what have you)?
Do I dispense with all the custom mapping information and just use JAXB or Spring OXM?
What do I do about links? Do I use the Atom namespace link element?
If I'm using Atom already, then why not use an Atom representation for everything?
Since answering these questions will necessarily involve more community input than we've had yet since the project is so new, I was thinking we'd wait until a post-1.0 release to add XML support. Priorities could obviously change if there's enough momentum in that direction, but I just don't see it happening in the next week.
There is some machinery you can override (this is just a Spring MVC application, after all) to produce any kind of a response you want. If you use the latest snapshot and override the RepositoryRestMvcConfiguration.contentNegotiatingViewResolver() method, you can provide an entirely different representation of the DTO coming out of the exporter. This is referred to in the wiki. You'll have to check the source code of JsonView to get the necessary details on what the DTO looks like internally, but it would be relatively easy to replace JsonView with MyOwnXmlView.
NOTE: This will only work for the current version of the REST exporter. The GA version will have different machinery to render output. I'll be providing hooks for doing whatever types of output rendering one wants to do, though, so you should be able to override output rendering by setting a property on the configuration. If you create a View subclass for this version, it will likely only be a matter of changing it to an HttpMessageConverter for the GA version.

Well with latest Spring IO Platform we can achieve this and with IO Platform we
dont need to worry about version also.
Have posted how to achieve in another stack overflow link as below :
Spring Boot REST with XML Support

Injecting Java Bytecode in XML for harmful purposes

So I have been thinking whether there is a way to send an XML such that the XML contains code in (bytecode) that will be unintentionally executed by the JVM. I am using java so I think uncompiled code will not work. I think I need to inject bytecode in the XML to trick the JVM? I want to try to make sure that the web service that I am building is secure. I am using JAXB for xml marshalling unmarshalling and Jersey as the web service handler.

Unintentionally? I don't think so.
The JAXB marshaller is going to deserialize XML values into the state of a given object, but the class and its behavior will be decided by you. I don't see sending raw bytecode in the XML and doing anything harmful with it.
You could send a JSON object that your Java object could execute using Rhino, but that's hardly unintentional.
Your service might have other security issues, but Java byte code injection attack isn't one of them.
You should be validating all data sent to you before binding, anyway.

About the only xml related vulnerability (i'm aware of) is "external entities", you can read up on that here. pretty sure the jdk has external entity handling disabled by default these days.

XML is data, and it's very unlikely that any recipient is going to try to execute it.
But of course, some XML vocabularies use the data to contain what you can think of as instructions to perform an action, and the recipient might then be fooled into performing inappropriate actions, which you could consider to be a security problem. This vulnerability is not at the level of XML, it is at the level of the application protocol (the vocabulary). The attack would have to use instructions that make sense in the context of this protocol, which is much more likely to be something like <employee action="delete"/> than something at the level of bytecode.

expose JAXB generated Class as WSDL web service

I have a bunch of very simple functions.
Each function has one input and one output.
OutputType function func(InputType);
The types of input/output are defined in xsd schema and generated into java classes with JAXB/XJC. Now I want to expose those functions as WSDL Web service running on Geronimo.
I just took a look at Axis/WSDL2Java/Java2WSDL; I thought that is pretty in a similar way as my functions are created.
I guess, I can use Java2WSDL to generate WSDL from my function and input/output types.
and then use some tools to generate server/client side binding,
Can anyone give more further suggestions? especially I have defined my input/output of functions in a xsd schema.
thanks very much.
A Summary:
These are what I have now....
Many implemented functions with one input and one outout.
public OutputType functionXXX(InputType in) { ....; return output; }
InputType and OutputType are already defined in a xsd schema (and turned into java classes with Jaxb/xjc).
What I want is....
Build Web services to execute those functions.
Not to touch the code of implemented functions.
And with WSDL,

I found a tutorial using CXF to do what you are looking to here.
That document claims to be using a contract first approach, but it isn't exactly. When discussing SOAP-based services, contract first means creating the descriptors (WSDL, XSD) first. You then generate any code artifacts from those descriptors. You can see the comments in the original blog post for the debate about the original author's choice of words.
That being said, a contract first approach has many benefits depending on what you are trying to accomplish. See the Spring Web Services tutorial for some information about it.

If you have an existing schema, with existing JAXB2 bindings for it, then in my experience Spring WebServices is by far the easiest way of exposing that as a SOAP web service. Its philosophy is "contract first", which is is exactly what you have. You don't need to generate any additional bindings, just wire up the endpoints a la Spring MVC, plug in the marshaller, and of it goes. It will introspect your schema looking for things that look like operations and expose them as WSDL operations automatically (you can tell it how to do that, if the default auto-discovery doesn't quite work).

What is the best way to expose a WCF service so that it can be easily consumed from Java/CXF?

We've written a WCF service to be used by a Java shop, who is using CXF to generate the adapters. We're not that familiar with Java, but have exposed the service using basicHttpBinding, SSL, and basic authentication. Integration tests show that a .NET client can consume the service just fine. However, the Java shop is having trouble consuming the service. Specifically, they getthe following JAXB error: Two declarations cause a collision in the ObjectFactory class. This is usually caused if 2 operations have the same name and namespace when CXF attempts to create adapter classes.
We can't find any type or operation names that should cause any sort of collision. We have made sure that all custom types specify a namespace, and tempuri.org is not specified anywhere in the WSDL. The Java shop suspects the error is because the generated WSDL contains <xsd:import elements.
So, my questions:
Is there any better way than CXF for the Java shop consume the WCF service? Project Tango looks interesting, but I don't know enough to tell them to consider using it. Is CXF a defacto standard in Java?
BasicHttpBinding/SSL/Basic Auth are MS recommended for interop scenarios, but the client still seems to have interop problems. Should we consider other bindings or settings to make this easier to consume?
Is there a way to configure WCF to always output a single WDSL with no schema imports?

The "Two declarations cause a collision in the ObjectFactory class" error message usually has nothing to do with imports. That's a JAXB error message that is usually caused by having multiple elements or similar that cause the generated field names to be the same. For example, if you have elements like:
<element name="Foo" .../>
and
<element name="foo" .../>
That can cause that error. Another is using thing like hyphens and underscores and such that are usually eliminated+capped:
<element name="doFoo" .../>
and
<element name="do_foo" .../>
With 2.1.4, you can TRY running the wsdl2java with the -autoNameResolution flag. That SOMETIMES helps with this, but not always. Unfortunately, the information that JAXB gives in these cases is nearly worthless and lots of times it's just trial and error to find the conflicting types. :-(

I am deep into Java & WCF interoperability. As someone else said you need to flatten your WSDL if you are working with file based WSDL. However I use Netbeans 6.5 and if you point to a real url like http://myservice/?wsdl , Netbeans can cope easily with the default wsdl generated by WCF.
In real life other things you need to consider is service versioning, optional datamembers (doesn't go well in java, so I suggest to make all datamembers IsRequired=true), order etc.
The real tough thing to get going was security. I had to make mutual certificate authentication working and it still has some issues.

The only way for your java client to talk to a WCF component will be one of the HTTP methods - basicHttpBinding, ws*, etc just as MS recommends. Java can't talk to WCF over TCP or namedPipes or MSMQ, etc.
I'd start with a super simple WCF component - something with a single method that spits out a string. Get that working with Java and then work your way up. Make sure that everything you're exposing is working with base types or well defined [DataContract] objects.

I've developped WCF with Axis2 clients. The authentication methods I've sucessfully uses is BasicHttpBinding/SSL/Basic (Transport) and WS-Security with Username (and MTOM).
The Metro implementation is used by SUN and Microsoft to test the interop :
http://weblogs.java.net/blog/haroldcarr/archive/2007/11/metro_web_servi.html
Sorry no clue about the import generated by WCF for the schema definition.

The problem with xsd:import is very common. Some toolkits or runtimes cannot cope with that. To address this, you can flatten the WSDL that is generated by WCF.
Check this post.
Regarding whether CXF is the right Java stack - I have never heard of it? I have used AXIS successfully, as well as JAX-WS. Both have been pretty straightforward.

This is a Jaxb issue. I ran into the same issue but used the xmlbeans option instead in wsdl2java client generation. To be honest I seem to prefer the xmlbeans objects more over jaxb as far a consumer to this webservice.

Saving Java Object Graphs as XML file

What's the simplest-to-use techonlogy available to save an arbitrary Java object graph as an XML file (and to be able to rehydrate the objects later)?

The easiest way here is to serialize the object graph.
Java 1.4 has built in support for serialization as XML.
A solution I have used successfully is XStream (http://x-stream.github.io/)- it's a small library that will easily allow you to serialize and deserialize to and from XML.
The downside is you can only very limited define the resulting XML; which might not be neccessary in your case.

Apache digester is fairly easy: http://commons.apache.org/digester/
JAXB is newer and comes with annotation goodness: https://jaxb.dev.java.net

XStream by the folks at Thoughtworks has a simple API and even deals with things like duplicate and circular references. It seems to be actively developed and is well documented.
http://x-stream.github.io/

Use java.beans.XMLEncoder. Its API is very simple (actually a little too simple; it'd be nice to wire it to a SAX ContentHandler), but it works on many graphs out of the box, and it's easy to create your own persistence delegate for any odd-ball classes you might encounter.
The syntax used by XMLDecoder allows
you to invoke any method, instance
or static, including constructors,
so it's extremely flexible.
Other encoders name
elements and attributes after class
and field names, so there's no fixed schema for the result. The XMLEncoder's
XML follows a simple DTD and can
easily be validated or transformed,
even when you've never seen the
types it uses.
You can assign objects an
identifier, and reference them
throughout the graph.
You can refer to constants defined
in classes or interfaces.
And, it's built into Java SE, so you don't need to ship an extra library.

Simple
Although XStream and JAXB can serialize an some object graphs succssfully they can not handle very complex graphs. The most powerful solution for large complex graphs is Simple XML Serialization. It can handle any graph. Also, it’s fast and simple to use without any dependencies.
To quote the Simple project page:
Simple is a high performance XML serialization and configuration framework for Java. Its goal is to provide an XML framework that enables rapid development of XML configuration and communication systems. This framework aids the development of XML systems with minimal effort and reduced errors. It offers full object serialization and deserialization, maintaining each reference encountered. In essence it is similar to C# XML serialization for the Java platform, but offers additional features for interception and manipulation.

The Simple API is, well, simple! It's really good. http://simple.sourceforge.net/
You can also use XStream: http://www.ibm.com/developerworks/library/x-xstream/index.html

JAX-B is part of the standard APIs and really easy to use.

If you need control over the XML that gets generated, I recommend taking a look at Betwixt (http://commons.apache.org/betwixt/) - it adds a lot of functionality to Apache's digester (Digester is good for building object graphs from XML, but is not so good for generating them).
If you really don't care about the XML that gets generated (just that it can be deserialized in the future), then the XMLEncoder/Decoder classes built into Java or good - as long as the objects you are serializing follow the JavaBean specification. The biggest area I've run into problems with the XMLEncoder/Decoder solution is if you have a bean that returns an immutable list for one of it's properties - the encoder doesn't handle that situation very well.

If you need to control the structure of the XML, the XStream is a good choice. You can use annotations to define precisely the structure/mapping of the XML and your objects.

I'd second (or third) XStream. It reads and writes XML without needing any special binding configuration or placing lots of extraneous syntax in the XML.

I put together a list with a lot of xml serialization libraries and its license

XStream is very simple http://x-stream.github.io/
XStream is a simple library to serialize objects to XML and back again.

java.beans.XMLEncoder perhaps?

Jackson
The Jackson Project is a processing and binding library for XML, JSON, and some other formats.
… Jackson is a suite of data-processing tools for Java (and the JVM platform), including the flagship streaming JSON parser / generator library, matching data-binding library (POJOs to and from JSON) and additional data format modules to process data encoded in Avro, BSON, CBOR, CSV, Smile, (Java) Properties, Protobuf, XML or YAML; and even the large set of data format modules to support data types of widely used data types such as Guava, Joda, PCollections and many, many more…

If you are really only interested in serializing your objects to a file and then deserializing them later, then you might check out YAML instead of XML. YAML is much easier to work with than XML and the output files are very human-readable (which may or may not be a requirement). Check out yaml.org for more information. I've used JYAML successfully on a recent project.