Can I use same Pojo class for hibernateMapping and jaxb binding ?
For example, I have a username in my Pojo class and hibernate mapping bind username with a database field.
I would like to bind this username with xml properties and send that with soap.
Is it possible ?
Thanks for your help.
Yes. In fact hyperjaxb3 is an open source library that facilitates this process (there are likely others available).
If you want to do it by hand, all you need to do is put both JAXB and JPA (or whatever) annotations on your POJO.
Related
I am using the IBM Social Business Toolkit. I have defined a connection for my Notes app via endpoints in the faces-config xml file. I wonder how I can access this file pro grammatically since I could not find a service that returns me the base url of IBM Connections.
It's useful to remember that an endpoint definition is really just creating a managed bean. The managed bean has a variable name you refer to it - the managed-bean-name property. You can access this directly from SSJS or via ExtLibUtil.resolveVariable() in Java. The definition also tells you the Java class that's being used, e.g. com.ibm.sbt.services.endpoints.ConnectionsBasicEndpoint. That really gives you all the information you need to get or set the properties.
So from SSJS you can just cast it to the class name, e.g.
var myService:com.ibm.sbt.services.endpoints.ConnectionsBasicEndpoint = connections
So the bit after the colon will be the managed-bean-class value and the bit after the equals sign will be the managed-bean-name. In Java, you can use
ConnectionsBasicEndpoint myService = (ConnectionsBasicEndpoint) ExtLibUtil.resolveVariable(ExtLibUtil.getXspContext().getFacesContext(), "connections");
You'll then have access to all the methods of the class, so you should be able to retrieve what you need.
The properties are part of the Java class, who are referred to in the Faces-Config.xml. So get the class by his fully qualified name or by bean name and set or get the properties
I think the best route will most likely be what Paul is suggesting: resolve the variable by its name and use the getters to get the effective properties that way.
Sven's suggestion is a good one to keep in mind for other situations. By accessing the faces-config.xml file as a resource, you could load it into an XML parser and find the values using XPath. I'm doing much that sort of technique in the next version of the OpenNTF Domino API, which will have a set of methods for manipulating the Faces config. However, one key aspect there is that reading the XML file directly will just get you the string values, which may be EL expressions, whereas going the resolveVariable route will get you the real current properties.
I wanted to know why do we need to specify the Annotation #XmlAccessorType when working with JAXB .
When i googled for this i found out this description from a website stating this
#XmlAccessorType sets default field and property serializability. By default, JAXB serializes public fields and properties. By setting #XmlAccessorType, the bean can choose to only allow annotated fields to be serialized.
Here the author mentions that with this annotation it gives control on serialization .
My question is , so #XmlAccessorType has nothing to do with the JAXB Binding and Unbinding from XML to java and java to XML , and it is all about Serialization only .
JAXB's #XmlAccessorType annotation is only used by JAXB (JSR-222) implementations for determining how to marshal a file to/from XML:
Normally the main decision to be made is between FIELD & PROPERTY/PUBLIC. FIELD is particularly useful when you have logic in your get/set methods that you do not want triggered during marshalling/unmarshalling. To see one way this choice affects the mapping metadata see:
http://blog.bdoughan.com/2012/02/jaxbs-xmltype-and-proporder.html
NONE is a useful choice when you have many unmapped properties and you want to tell your JAXB implementation to only map the fields/properties you have annotated. This can be alot easier than adding a lot of #XmlTransient annotations into your model.
Fore More Information
http://blog.bdoughan.com/2011/06/using-jaxbs-xmlaccessortype-to.html
I want to know which solution is better for a Jersey Rest Web service. In some cases JAXB is not able to handle some types. Is it better to use XStream?
Note: I'm the EclipseLink JAXB (MOXy) lead and a member of the JAXB (JSR-222) expert group.
I want to know which solution is better for a Jersey Rest Web service.
JAXB (JSR-222) is the default binding layer for JAX-RS. This means that if you have the following method, JAXB will automatically be used to convert the return type (Customer) to XML (and JSON when using Jersey).
#GET
#Produces(MediaType.APPLICATION_XML)
#Path("{id}")
public Customer read(#PathParam("id") long id) {
return entityManager.find(Customer.class, id);
}
If you need more control over your JAXBContext you can use a JAX-RS mechanism called ContextResolver:
http://blog.bdoughan.com/2011/04/moxys-xml-metadata-in-jax-rs-service.html
In some cases JAXB is not able to handle some types
JAXB is able to handle all types, either by default or through the use of an XmlAdapter. Below are some examples where an XmlAdapter is used with the Joda-Time types and some immutable domain objects:
http://blog.bdoughan.com/2011/05/jaxb-and-joda-time-dates-and-times.html
http://blog.bdoughan.com/2010/12/jaxb-and-immutable-objects.html
Is it better to use XStream?
Below is a link to a blog entry I wrote where I mapped the same object model to the same XML document using both JAXB and XStream you may be interested in:
http://blog.bdoughan.com/2010/10/how-does-jaxb-compare-to-xstream.html
JAXB implementations such as MOXy also contain many extensions you will find useful such as XPath based mapping (#XmlPath) and an external mapping document:
http://blog.bdoughan.com/2011/09/mapping-objects-to-multiple-xml-schemas.html
For an example of using MOXy as the JAXB provider in Jersey see:
http://blog.bdoughan.com/2010/08/creating-restful-web-service-part-35.html
Depends on your use case - if you think JAXB will be significant limitation, you can use XStream. Btw Jersey recently added support for MOXy, which could help you overcome some corner cases in JAXB Reference impl in JDK.
Pro JAXB
out of the box functionality with Jersey
ability to specify own JAXBContext
stable; lots of tests / support from Jersey/JAXB team
Con JAXB
it doesn't work as expected for some corner cases (java/xml binding has limitations due to different nature of these languages)
Pro XStream:
you probably have some experience with that
Con XStream:
you'll need implement support for it (MessageBodyReaders/Writers) in Jersey
I'm trying to enable JAXB annotation support within my RESTEasy based web application and this article was suggested to me (http://wiki.fasterxml.com/JacksonJAXBAnnotations). I'm able to get the jackson-xc.jar but I don't see how to register the annotation introspector. Currently, RESTEasy automatically serializes my JSON responses, where would the below fit? Currently, RESTeasy serializes the JSON object automatically.
Include jackson-xc jar, which contains org.codehaus.jackson.xc.JaxbAnnotationIntrospector
Register this annotation introspector
ObjectMapper mapper = new ObjectMapper();
AnnotationIntrospector introspector = new JaxbAnnotationIntrospector();
// make deserializer use JAXB annotations (only)
mapper.getDeserializationConfig().setAnnotationIntrospector(introspector);
// make serializer use JAXB annotations (only)
mapper.getSerializationConfig().setAnnotationIntrospector(introspector);
What you need to figure out is how to make RESTeasy use ObjectMapper you have configured. JAX-RS offers generic way to do this via providers, but there may be simpler way(s) to do this with RESTeasy.
Some JAX-RS implementations also register JAXB annotation introspector by default.
Last thing: are you sure you need to use JAXB annotations? While Jackson can use them, preferable method is to either just use basic naming convention for discovery and jackson's own annotations in case where overrides are needed. Problem with JAXB is that it is xml-specific so there is little bit of impedance when used with JSON.
Thanks for the reply, I'll take a look at your suggestions...
The reason why we want to stick with the jaxb annotations is that the #XmlRootElement(name="userResponse") annotation allows an extra wrapping element that we want in our JSON responses. See example below:
We want to have {"response":{"userResponse":[{"user":{"businessRegion":"US","firstName":"joe","language":"en","lastName":"smith"}}}]} instead of what Jackson currently outputs, {"response":[{"user":{"businessRegion":"US","firstName":"joe","language":"en","lastName":"smith"}}]}. Is there anyway to mimic the #XmlRootElement in Jackson without adding an additional wrapper class?
User class:
#XmlAccessorType(XmlAccessType.FIELD)
#XmlRootElement(name="userResponse")
public class UserResponse extends AbstractResponse{
private Users user;
When marshaling some objects into XML, I need to insert an additional field in each of the resulting XML objects - sort of flag. The purpose is not modifying the source objects but inserting that information in the output XML.
Any ideas if this is possible?
There are a few possible approaches:
1. Use an XmlAdapter
You could leverage JAXB's XmlAdapter. Here you would create a version of the classes with the extra field (the adapted classes could extend the original). Then convert between them in the adapter. Since the alternate version of the class would contain the extra field it would marshal out.
http://bdoughan.blogspot.com/2010/07/xmladapter-jaxbs-secret-weapon.html
2. Use Binder
If you marshal target is DOM, then you could leverage JAXB's Binder. It is intended for infoset preservation, but after a marshal it does maintain a link between the objects and the DOM nodes. Once the marshal is complete you could use the binder to find an object's associated node and update it.
http://bdoughan.blogspot.com/2010/09/jaxb-xml-infoset-preservation.html
3. Wrap the Output Target
If your output target is something like a ContentHandler or XMLStreamWriter then when the appropriate state is reached you could trigger additional events to be called on the nested marshal target.
The easiest way I can think of would be to use JAXB to marshal to a DOM, and then programmatically insert your extra information into that DOM, then re-marshal the DOM to XML.
Ugly and inefficient, but that's the best I can think of.