阿兩的筆記本 Ryoutsu's Notebook

Introduction 在開發Rest API時，透過Jackson提供的API，將物件轉為json或xml格式。它曾經算是效能最好的函式庫之一，現在就不一定了。 Jackson - Hello World From 2.4.5 to 2.7.1 Convert the key fields with special char @JsonSerialize(keyUsing=KeySerializer.class) Convert the Date format to ISO8601 @JsonSerialize(using=Serializer.class) @JsonDeserialize(using=Deserializer.class) Optionally ignore some fields @JsonIgnore @JsonIgnoreProperties The visibility of the fields @JsonAutoDetect Convert the value fields with special char @JsonSerialize @JsonDeserialize DeepClone with Jackson Resource How to rename element names? @JsonProperty(“contractor”) Serializing Map<Date, String> with Jackson Jackson Modules for Map Serialization Jackson Annotations

Problem 最近因為有人code沒寫好的原因，造成了Optional之亂；而始作俑者聲稱這問題很難解，促成我寫這篇文章的原因。原始問題發生在透過Gson對有Guava Optional做為member的物件做deepClone時，會拋出例外: public class ParentObject { private Optional < ChildObject > guavaOptionalChild = Optional. absent ( ) ; // .. } 這個問題發生在Gson無法將Json內容轉回Guava Optional的物件。首先網上已有許多針對Optional使用的討論，這裡不涉及使用的議題；而以Gson來說，可以透過TypeAdapter去解決物件轉換的問題，請參考此link。 Jackson會有相同問題，本篇文章主要分享Jackson的解法。詳細程式碼可以參考link。 How to? 解決Jackson Json轉換問題的方法之一，是在欄位掛載@JsonSerialize與@JsonDeserialize，可以參考link。今天分享給大家的，是直接使用別人的做好的模組，來減少維護的負擔。 Target Object 我想要做DeepClone的物件，會使用Guava與JDK8的Optional，而Optional中的ChildObject結構與ParentObject相同: public class ParentObject { private Optional < ChildObject > guavaOptionalChild = Optional. absent ( ) ; private java. util . Optional < ChildObject > jdkOptionalChild = java. util . Optional . empty ( ) ; private String value ;   public java. util . Optional < String > getValue ( ) { return java. uti...

Problem 這陣子在擴充Rest API的功能時，聽同事說某功能輸出在xml格式下，會因內容使用unicode，導致無法在瀏覽器上正常顯示。xml並非不支援unicode，而是因為瀏覽器只支援xml 1.0；我們資料剛好不在1.0所規範的範圍內，因此瀏覽器才把它認為不合法。本篇文章分享解決此問題的方法。 Research 首先我思考的是，為什麼Json沒這問題呢? 因為對Json來說，unicode內容有兩種選擇: 以代碼顯示: \u0001\u0002\u0003。 以原始樣式顯示: 即欄位定義為unicode type。 而xml在瀏覽器接收到代碼後，會做轉換；無法轉換時，就會報錯。在花些時間研究後，得知Amazon的Simple DB針對client傳遞或是要回應給client的資料；在有這種情況時，會將內容做base64的encoding。雖然對user來說需要額外轉換，但也不失為一個解法。因此我的解法核心在於encoding，差別只在於用什麼方式。 How to? 假設我們的Event Bean物件是這樣子: public class Event { private Date date ;   private String message ;   public Date getDate ( ) { return date ; }   public void setDate ( Date date ) { this . date = date ; }   public String getMessage ( ) { return message ; }   public void setMessage ( String message ) { this . message = message ; } } 當message中包含對xml不合法的字元，就會發生我所敘述的問題。 第一個方法 - 直接操作message 最簡單的方法，當然就是直接將message做base64的encoding。但如果直接把值塞到物件內，可能會讓使用到的client必須自行去decoding。因...