Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>First of all I would suggest doing such preprocessing before marshalling. It would be much easier. However if it is not possible for some reason then you can create you custom type adapter. Then you can put <code>@XmlJavaTypeAdapter(VersioningAdapter.class)</code> on every type that you want to have versioning enabled. <code>@XmlJavaTypeAdapter</code> can also be specified on package level, but you have to specify to which types it applies. You cannot use <code>XmlAdapter</code> without specifying somewhere <code>@XmlJavaTypeAdapter</code>.</p> <p>Drawbacks of such solution:</p> <ul> <li>if you have multiple versioned types then each of them has to be annotated with <code>@XmlJavaTypeAdapter</code></li> <li><code>@XmlJavaTypeAdapter</code> does not work for root element, only on child elements. You have to call adapter manually on root element before marshalling</li> </ul> <p>AFAIK there is no other option for customizing JAXB marshalling. That's why I think that annotation processing should be performed in separate step before marshalling. Unless you can accept mentioned limitations.</p> <p>Sample adapter (full code can be found <a href="https://github.com/destin/SO-answers/tree/master/SO-jaxb-marshalling-with-custom-annotations" rel="nofollow">here</a>):</p> <pre><code>public class VersioningAdapter extends XmlAdapter&lt;Object, Object&gt; { @Override public Object unmarshal(Object v) throws Exception { // TODO Auto-generated method stub return null; } @Override public Object marshal(Object v) throws Exception { if (v == null) { return v; } Field[] fields = v.getClass().getDeclaredFields(); for (Field field : fields) { Annotation[] annotations = field.getDeclaredAnnotations(); CustomVersion annotation = findCustomVersion(annotations); if (annotation != null) { if (!contains(annotation, Configuration.getVersion())) { field.setAccessible(true); field.set(v, null); } } } return v; } private CustomVersion findCustomVersion(Annotation[] annotations) { for (Annotation annotation : annotations) { if (annotation instanceof CustomVersion) { return (CustomVersion) annotation; } } return null; } private boolean contains(CustomVersion annotation, String version) { String[] values = annotation.value(); for (String value : values) { if (value.equals(version)) { return true; } } return false; } } </code></pre>
    singulars
    1. This table or related slice is empty.
    1. POJaxb marshalling with custom annotations
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USDawid Pytel
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POJaxb marshalling with custom annotations
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COhi. thanks for the answer, but can you clarify what do u mean when you say - "annotation processing should be performed in separate step before marshalling" ! i am open to suggestions and am still looking for the right approach.
      singulars
      1. PO
      1. USAshish Thukral
    2. CO@AshishThukral - if I were you I would write a utility class that uses reflection (like Adapter I wrote) to nullify properties that do not match version. This class should be called just before marshalling the objects to XML. If you marshal them using Marshaller then it is easy. If you use JAX-WS you can use logical handler to amend the output before it gets marshalled. The utility class doesn't have to know anything about JAXB.
      singulars
      1. PO
      1. USDawid Pytel
    3. COthat seems like a good suggestion. thanks.
      singulars
      1. PO
      1. USAshish Thukral
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload