Рицинус и розетки - PullRequest
       45

Рицинус и розетки

1 голос
/ 19 ноября 2009

Я новичок в Castor и привязке данных в целом. Я работаю над приложением, которое, в частности, должно извлекать данные из сокета и демаршировать данные для создания POJO. Теперь у меня есть сокеты, и я даже сгенерировал и скомпилировал Java-файлы благодаря Ant и Castor.

Вот проблема: поток данных, который я получу, может быть одним из примерно 9 различных объектов. То есть я получаю поток текста (XML), представляющий объект с вещами, над которыми я буду работать; опять же, в зависимости от типа объекта. Если бы это был только один объект, это было бы легко: вызовите на нем команды unmarshall и продолжайте мой веселый путь. Но, поскольку это может быть один из многих видов объектов, кого я знаю, что разобрать? Я прочитал об отображении, но либо не получил его, либо похоже на статическое отображение, а не на динамическое отображение.

Любая помощь там?

Ответы [ 3 ]

2 голосов
/ 24 ноября 2009

Вы правы, Кастор ожидает статическое отображение. Но вы можете работать с этим. Вы можете написать некоторый код, который изменит входящий xml, чтобы на вашей стороне Castor мог использовать одну схему, а на стороне ваших клиентов им не приходилось менять свои схемы.

Измените схему, которую Кастор ожидает получить с чем-то с общим корневым элементом, с учетом этого ваши девять различных альтернатив для ваших различных объектов (я думаю, вы можете ограничить ее, чтобы схема допускала только одну из девяти, если это не сработает, вы можете просто сделать все подэлементы необязательными).

Затем вы можете написать код, который модифицирует входящий xml, чтобы обернуть ваш входящий xml этим общим корневым элементом, а затем подать обернутый xml в поток, который читается демаршаллером Castor.

Существует как минимум 3 различных способа реализации XML-оболочки: библиотеки SAX, XSLT и XML (например, JDOM, DOM4J и XOM - я предпочитаю XOM, но любой из них будет работать).

Путь SAX, вероятно, лучше всего подходит, если вы уже знакомы с SAX или если один из других способов работает, но не хватает производительности. Если бы мне пришлось реализовать это, то я бы создал XMLFilter, который принимает xml и записывает xml, укладывая его поверх другого куска, который записывает xml в OutputStream, и записывая метод-обертку вокруг демаршаллинга, чтобы передать входящий поток в xmlreader, скопируйте OutputStream в другой InputStream (простой способ - использовать commons-io) и передайте новый InputStream в демаршаллер Castor.

С XSLT нет никакого дурака с SAX, хотя иногда XSLT имеет репутацию болевого синдрома, мне кажется, что это может быть относительно простым преобразованием, но я также не сделал на это укол. Прошло много времени с тех пор, как я использовал XSLT для чего-либо. Я также не уверен в производительности, хотя я бы не стал списывать ее со счетов.

Использование XOM, JDOM или DOM4J для переноса XML также возможно, и кривая обучения намного ниже, чем для SAX или XSLT. Недостатком является то, что весь XML-документ имеет тенденцию сразу всасываться в память, поэтому, если вы имеете дело с достаточно большими документами, вам может не хватить памяти.

1 голос
/ 25 ноября 2009

У меня есть похожая вещь в Jibx, где все объекты входящих сообщений реализуют базовый интерфейс, в котором есть поле, обозначающее тип сообщения.

Текст / xml сериализуется в базовый интерфейс, и затем я использовал шаблон команды для вызова соответствующей бизнес-логики в зависимости от типа сообщения, определенного в базовом интерфейсе.

Не уверен, что это возможно при использовании Castor, но взгляните на Jibx, так как производительность просто фантастическая.

http://jibx.sourceforge.net/

0 голосов
/ 10 декабря 2009

Я ценю ваши идеи. Вы оба дали мне хорошую информацию и новые знания, которых у меня не было. В конце концов, я получил процесс, чтобы работать через взломать. Я беру текстовый поток, анализирую корневой тег сообщения и затем включаю его, чтобы определить нужный объект для создания. Я демонтирую все свои объекты независимо, и все счастливы с нашей стороны.

...