Здравствуйте, Blazkowicz, Вы писали:
B>Сейчас существует множество проектов с помощью которых можно реализовать сериализацию объектов в XML.
B>JOX, Castor, JAXB, JiBX...
B>Какие-то сериализуют только бины, какие-то любые объекты через мапинг. B>Вопрос. Какие существуют ещё сериализаторы? B>И может ли кто рассказать про достоинства-недостатки?
B>Спасибо.
JAXB — начали использовать недавно, но для десериализации. Не очень нравится то, что объекты, которые хочется получить на выходе JAXB строить не может, только те, которые генерирует его компилятор xml-схем. Мы все равно им решили пользоваться, т.к. чистым jdom'ом или его аналогами разбирать большой и разнообразный xml-файл сложнее, просто по его бинам строим свои. Соответственно, при сериализации (если она бы нам понадобилась) возникла бы та же проблема — сначала пришлось бы из своих объектов строить бины для JAXB и только потом сериализовать.
В целом до сих пор с большими xml-файлами "на выходе" сталкиваться не приходилось, а для маленьких (типичный пример — подготовка данных для web-страницы, часть которой рендерится с помощью XSLT) до сих пор с успехом использую собственную низкоуровневую библиотечку, которая просто пишет в StringBuffer 5-6 различными способами, востребованными практикой. Почему-то думается, что по производительности этот способ лучший.
А руками приходится писать не так много, как могло бы показаться со стороны — по одному Java-классу тупой сериализации на каждую пару (исходные данные в конкретном формате; формат XML). При этом куски xml'я по определенным исходным данным я предпочитаю все время видеть в одном xml-формате, поэтому их сериализация кодируется только единожды, а потом вставляется в различные "объемлющие" алгоритмы сериализации. По трудозатратам это однозначно соперничает с тем же JAXB в силу того, что все равно приходится что-то писать (в одном случае — простой, хотя и объемный, код Java, который к тому же просто тестируется, в другом — схемы и код Java, который подстраивается под сгенерированные классы).
Сейчас существует множество проектов с помощью которых можно реализовать сериализацию объектов в XML.
JOX, Castor, JAXB, JiBX...
Какие-то сериализуют только бины, какие-то любые объекты через мапинг.
Вопрос. Какие существуют ещё сериализаторы?
И может ли кто рассказать про достоинства-недостатки?
Здравствуйте, Blazkowicz, Вы писали:
B>Сейчас существует множество проектов с помощью которых можно реализовать сериализацию объектов в XML.
B>JOX, Castor, JAXB, JiBX...
B>Какие-то сериализуют только бины, какие-то любые объекты через мапинг. B>Вопрос. Какие существуют ещё сериализаторы? B>И может ли кто рассказать про достоинства-недостатки?
Всегда писал сам, и всегда оставался доволен, поскольку всё работало и я понимал как
Здравствуйте, Mishka, Вы писали:
M>Здравствуйте, Blazkowicz, Вы писали:
B>>Сейчас существует множество проектов с помощью которых можно реализовать сериализацию объектов в XML.
B>>JOX, Castor, JAXB, JiBX...
B>>Какие-то сериализуют только бины, какие-то любые объекты через мапинг. B>>Вопрос. Какие существуют ещё сериализаторы? B>>И может ли кто рассказать про достоинства-недостатки?
M>Всегда писал сам, и всегда оставался доволен, поскольку всё работало и я понимал как
а может исходничками поделишся ?
Здравствуйте, Mishka, Вы писали:
M>Всегда писал сам, и всегда оставался доволен, поскольку всё работало и я понимал как
Сам писал сериализатор под конкретный набор классов? Или сам писал сериализацию каждого класса?
У нас заказчик обожает XML, там где надо и где не надо. Сначала некоторое время паринг-билдинг писал сам. Быстро надоело. Решил что пора это дело автоматизировать. Хотел написать сам, но потом решил поискать что есть (как это бычно бывает в Java ). Нашел JOX, расстроился что он только бины сериализует.
Сейчас не по своей воле пользуюсь JiBX. Есть свои плюсы, только сырой он ещё.
Говорят castor очень не плох. Сам не трогал — не знаю.
Ещё интересно насколько прикольнее использовать сериализацию бинов. Там по идее маппинг не надо писать. На какие грабли можно напороться.
Здравствуйте, Alekseymir, Вы писали:
M>>Всегда писал сам, и всегда оставался доволен, поскольку всё работало и я понимал как A>а может исходничками поделишся ?
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Mishka, Вы писали:
M>>Всегда писал сам, и всегда оставался доволен, поскольку всё работало и я понимал как
B>Сам писал сериализатор под конкретный набор классов? Или сам писал сериализацию каждого класса?
Писал для классов имеющих определённую структуру (что-то вроде O/R domain classes), использовал reflection. И если мне память не изменяет, то писал под .NET, хотя шибко большой разницы нет.
Давным давно в "Проектировании" этот вопрос обсуждали, но было это больше года назад, а то и больше, теперь фиг найдёшь.
http://xml.apache.org/xmlbeans/
B>Сейчас существует множество проектов с помощью которых можно реализовать сериализацию объектов в XML.
B>JOX, Castor, JAXB, JiBX...
B>Какие-то сериализуют только бины, какие-то любые объекты через мапинг. B>Вопрос. Какие существуют ещё сериализаторы? B>И может ли кто рассказать про достоинства-недостатки?
B>Спасибо.
А JAXB сильно различается с XMLEncoder\XMLDecoder в 1.4?
C0s><skipped>... просто по его бинам строим свои. Соответственно, при сериализации (если она бы нам понадобилась) возникла бы та же проблема — сначала пришлось бы из своих объектов строить бины для JAXB и только потом сериализовать.
Ууууу... я такие решения очень не люблю.
C0s><skipped>...до сих пор с успехом использую собственную низкоуровневую библиотечку, которая просто пишет в StringBuffer 5-6 различными способами, востребованными практикой. Почему-то думается, что по производительности этот способ лучший.
А если не секрет можешь рассказать что за функциональность о библиотеки?
C0s>А руками приходится писать не так много, как могло бы показаться со стороны — по одному Java-классу тупой сериализации на каждую пару (исходные данные в конкретном формате; формат XML). При этом куски xml'я по определенным исходным данным я предпочитаю все время видеть в одном xml-формате, поэтому их сериализация кодируется только единожды, а потом вставляется в различные "объемлющие" алгоритмы сериализации.
Тут согласен, но мне больше нравилось чтобы бины сами себя сериализовали. Только никак не удавалось нормальный интерфейс для этого придумать.
C0s>По трудозатратам это однозначно соперничает с тем же JAXB в силу того, что все равно приходится что-то писать (в одном случае — простой, хотя и объемный, код Java, который к тому же просто тестируется, в другом — схемы и код Java, который подстраивается под сгенерированные классы).
Склоняюсь к тому что JiBX все же рулит, с помошью маппинга там можно довольно сложные конструкции обрабатывать. А когда один раз научишься маппиг делать, то в дальнейшем его клепать не трудно. У него только 1 существенный недостаток. Это пост-компиляция. Которая на этапе разработки как палка в колесах. Хотя, наверное она очень сильно влияет на производительность (в позитивную сторону).
Осталось разузнать про Castor.
Я вот тут ещё подумал, на базе метаданных в 1.5 можно построить довольно не плохой сериализатор без всяких маппингов.
Здравствуйте, Blazkowicz, Вы писали:
B>Сейчас существует множество проектов с помощью которых можно реализовать сериализацию объектов в XML.
B>JOX, Castor, JAXB, JiBX...
B>Какие-то сериализуют только бины, какие-то любые объекты через мапинг. B>Вопрос. Какие существуют ещё сериализаторы? B>И может ли кто рассказать про достоинства-недостатки?
М.б. не совсем то, что надо, но похожее:
мне надо было из Явы создать XML файл заранее определенной структуры; данные для этого файла предоставляет куча разных классов.
Написал что-то типа XPath, но для записи. При этом процесс выглядит так:
1. Создаем org.w3c.dom.Document.
2. Создаем мой XPath-интерпретатор, отдаем ему документ из п.1
3. Отдаем этот интерпретатор по-очереди всем желающим в него чего-нибудь записать.
4. Эти желающие вызывают метод интерпретатора вида:
document.update("/Solar/Planet[@number=3]/Russia/Moscow@x-location=${x}",
new Object[] { "x", "123.4" });
(ну или как-то так, точно не помню)
При этом создаются все недостающие промежуточные узлы с нужными аттрибутами.
5. Сохраняем получившийся документ на диск.
Была мысль это расширить до декларативного подхода, но проект сдох.
Реализацией могу поделиться.
Здравствуйте, Blazkowicz, Вы писали:
B>А JAXB сильно различается с XMLEncoder\XMLDecoder в 1.4?
чего не знаю, того не скажу
C0s>><skipped>... просто по его бинам строим свои. Соответственно, при сериализации (если она бы нам понадобилась) возникла бы та же проблема — сначала пришлось бы из своих объектов строить бины для JAXB и только потом сериализовать. B>Ууууу... я такие решения очень не люблю.
вот и я бы не советовал
C0s>><skipped>...до сих пор с успехом использую собственную низкоуровневую библиотечку, которая просто пишет в StringBuffer 5-6 различными способами, востребованными практикой. Почему-то думается, что по производительности этот способ лучший. B>А если не секрет можешь рассказать что за функциональность о библиотеки?
на 200 строк вместе с реализациями несколько тупых методов:
public static StringBuffer appendXmlStart(StringBuffer sb, String encoding)
public static StringBuffer appendCDATA(StringBuffer sb, String cdata)
public static StringBuffer appendXmlAttr(StringBuffer sb, String attrName, Object _attrValue)
public static StringBuffer appendXmlAttrs(StringBuffer sb, String[] attrNames, Object[] attrValues)
public static StringBuffer appendElement(StringBuffer sb, String elementName, Object _body, boolean isCDATA)
public static StringBuffer appendElement(StringBuffer sb, String elementName, String[] attrNames, Object[] attrValues, Object _body, boolean isCDATA)
public static StringBuffer appendElement(StringBuffer sb, String elementName, XmlBodyGenerator bodyGenerator)
public static StringBuffer appendElement(StringBuffer sb, String elementName, String[] attrNames, Object[] attrValues, XmlBodyGenerator bodyGenerator)
// и еще несколько таких же низкоуровневых методов
// XmlBodyGenerator - интерфейс для callback-генерации body у элемента (годится, когда есть вложенные элементы)
никаких особых примочек типа изощренной работы с namespaces и проч... никаких валидаций и т.д.
для небольших динамических xml'ей этим способом уже почти 2 года пользуюсь и ничего другого не хочу
B>Тут согласен, но мне больше нравилось чтобы бины сами себя сериализовали. Только никак не удавалось нормальный интерфейс для этого придумать.
interface XMLizable с единственным методом toXMLString(нужные параметры, если нужны вообще) — кроме шуток, есть у нас функционал, где это катит, причем параметр даже есть и не очень тривиальный — объект контекста сериализации, что необходимо для передачи всяких значений и динамических параметров при спуске "вниз" по составным частям для генерации их кусочков xml (они также реализуют XMLizable)
при необходимости можно этот подход модифицировать: не строку генерировать, а в контекст сериализации класть writer какой-нибудь, чтобы метод в него пихал байты там или символы...
B>Склоняюсь к тому что JiBX все же рулит, с помошью маппинга там можно довольно сложные конструкции обрабатывать. А когда один раз научишься маппиг делать, то в дальнейшем его клепать не трудно. У него только 1 существенный недостаток. Это пост-компиляция. Которая на этапе разработки как палка в колесах. Хотя, наверное она очень сильно влияет на производительность (в позитивную сторону).
надо будет посмотреть, когда все имеющиеся решения меня перестанут устраивать... хотя к тому времени еще что-нибудь появится
B>Я вот тут ещё подумал, на базе метаданных в 1.5 можно построить довольно не плохой сериализатор без всяких маппингов.
Здравствуйте, C0s, Вы писали:
C0s>interface XMLizable с единственным методом toXMLString(нужные параметры, если нужны вообще) — кроме шуток, есть у нас функционал, где это катит, причем параметр даже есть и не очень тривиальный — объект контекста сериализации, что необходимо для передачи всяких значений и динамических параметров при спуске "вниз" по составным частям для генерации их кусочков xml (они также реализуют XMLizable)
C0s>при необходимости можно этот подход модифицировать: не строку генерировать, а в контекст сериализации класть writer какой-нибудь, чтобы метод в него пихал байты там или символы...
Не, ну с сериализацией-то все понятно. Не очень ясно как с десериализацией поступить.
Если делать просто метод a-la fromXML? То что он должен делать? Просто заполнять экземпляр другими данными? Не очень-то красиво.
Делать конструктор или статический метод? Так их в интерфейсе объявлять нельзя.
C0s>это еще когда 1.5 будет в production...
В будущее надо смотреть, в будущеет. 1.5 однозначно рулит. Скорей бы релиз.
Здравствуйте, Blazkowicz, Вы писали:
B>Не, ну с сериализацией-то все понятно. Не очень ясно как с десериализацией поступить. B>Если делать просто метод a-la fromXML? То что он должен делать? Просто заполнять экземпляр другими данными? Не очень-то красиво. B>Делать конструктор или статический метод? Так их в интерфейсе объявлять нельзя.
Поделюсь "своим" методом.
Сериализация — ручками в StringBuffer с помощью похожей либы.
Десериализация — тоже ручками, но с привлечением SAX. Писать свой парсер XML вообще никакого смысла нет.
