mrkovalchuk: Скачал проект (было бы гораздо проще сделать это без папок out и target). Поменял int на Integer в Note, нажал Save на страничке Test.xhtml - ошибки нет, в таблицах note и telephone появилось по одной записи с ID = 1. Не знаю, что у Вас пошло не так, единственное предположение - не перезапускали сервер после обновления приложения...
mrkovalchuk: Чтобы проверить автоинкремент, напишите и выполните SQL-скрипт INSERT INTO note..., не указывая ID в списке полей. Если выполнится без ошибок и в поле ID появится непустое значение, значит автоинкремент у первичного ключа есть. Пересоберите проект с полем id в сущностях везде указанным как Integer, а не как int, и проверьте ещё раз работоспособность. Попробуйте включить трассировку SQL-запросов (hibernate.show_sql=true) в persistence.xml и посмотреть что происходит при вставке записи.
mrkovalchuk: Если сущности описаны в .hbm.xml, то аннотации не нужны. Вообще, использование аннотаций считается более современным подходом в сравнении с файлами .hbm.xml, но по функциональности оба подхода идентичны. У вас в Note.hbm.xml уже прописана стратегия генерации identity, осталось поменять тип поля таблицы в БД, как я описал в ответе. Если сделаете тип BIGINT, то в сущности следует указать Long для id. Если хотите оставить Integer, то в БД делайте INT.
Приведите код класса Note, как в нём определено поле id? Какая СУБД используется? Как определено поле id в базе данных (SQL create table)? Test.xhtml можно убрать, чтобы не занимать лишнего места. PS - не соблюдаете стандартные договорённости о именовании языка Java: имена пакетов желательно делать полностью в нижнем регистре, имена классов в CamelCase с заглавной буквой в начале.
Хранить данные по колонкам - одна из основных особенностей реляционных СУБД, если вам эта особенность не нужна, вероятно следует задуматься о смене СУБД.
"снизит нагрузку на бд" - есть доказательства, нагрузочные тесты делали? Можно без нагрузочных тестов прикинуть: в JSON вы храните имя поля и его значение в КАЖДОЙ строке таблицы, СУБД хранит в строке ТОЛЬКО значение, а описание поля хранится в одном экземпляре в отдельной структуре данных. Размер, занимаемый данными в случае хранения в JSON будет значительно больше - где здесь снижение нагрузки?
"40+ позиций". Такое количество полей в таблице мелочь для любой адекватной СУБД. Лично у меня были примеры по 300+ в одной таблице, не считая связанных с ней таблиц - никаких вопросов в связи с этим не возникало. Более того, имея такую структуру, в разных местах вашей бизнес-логики можно осуществлять выборку разного состава полей, т.е. не все 300, а только 10, которые нужны "здесь и сейчас". JSON вам придется каждый раз вытаскивать целиком, даже если нужно значение только одного поля.
Настоятельно рекомендую использовать все возможности, предоставляемые СУБД именно в том виде, в котором они подразумеваются по-умолчанию. А такие велосипеды не делать никогда.
Михаил Акушский: Можно еще попробовать другие версии библиотек jaxb*. Они ведь не сами по себе работают, а под управлением других библиотек, так что есть вероятность несовместимости версий. Проверьте библиотеки в соответствии с, например, вот этим руководством: examples.javacodegeeks.com/enterprise-java/jws/jax...
Там предлагают скачать пакет библиотек отсюда: https://jax-ws.java.net/2.2.10/ и перенести некоторые из них (или все) в TOMCAT_HOME/lib. Проверьте внимательно, чтобы таких же библиотек не было больше нигде на сервере, особенно в вашем приложении.
Михаил Акушский: Думаю, что библиотек jaxb-* в вашем приложении всё же не должно быть, раз у Glassfish уже развёрнута своя имплементация (Metro 2.3.1?). Попробуйте не пересобирая приложение, прямо на сервере удалить эти библиотеки из своего приложения (а лучше все библиотеки). Вы говорите что делали это но что-то не сходится - как могло возникнуть исключение "внутри jaxb-impl-2.2.10", если вы всё удалили...
Михаил Акушский: Ещё вариант: добавьте к команде запуска сервера опцию -verbose:class - в лог будет выводиться информация о том, из каких библиотек загружаются классы. После повторения ошибки сделайте поиск по логу классов com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl и com.sun.xml.bind.v2.model.core.EnumLeafInfo. Скорее всего, они загружаются из разных .jar-файлов (jaxb-core-xxx и jaxb-impl-xxx), возможно у них разная версия
Ну раз уж пошли по пути ручного перекладывания данных, то, видимо, надо идти этим путем до конца: писать копирование не только родительского объекта, но и его дочерних тоже. Т.е., создавать коллекцию, а добавлять в неё новые экземпляры (new ChildEntity()) дочерних объектов, и копировать во вновь созданные экземпляры данные из javaassist
getatonheim: Если под костылём подразумевается (100500 set(get())-ов), то это не так. Это не костыль, а просто некрасивый код, не более того. Я за 13 лет работы еще ни разу не встречал серьёзного приложения без некрасивого кода. Впрочем, и без костылей тоже не обходится. Такой код прост, понятен, и несмотря на то, что требует дальнейшей поддержки в случае добавления/удаления полей - эта поддержка осуществляется за считанные минуты без включения мозга (например, добавить get/set методы современные среды разработки позволяют комбинацией клавиш).
Моё мнение по поводу некрасивого кода и костылей - пусть будут, если их немного, они не разбросаны хаотично по всему проекту, костыли имеют хорошие комментарии, трудозатраты на попытки замены такого кода на "красивый" больше чем поддержка "некрасивого" кода ближайшие пару лет...
nitr1s: Да, конечно. Какой протокол инфообмена клиента с сервером не выбери - всегда какие-то данные, введенные пользователем, будут передаваться на сервер. Для REST это, обычно, JSON. Как я уже писал, REST/JSON имеют хорошую поддержку во многих фреймворках, поэтому формирование содержимого делается просто.
Вот пример для ExtJs (что было "под рукой"):
var record = какой-либо-JavaScript-объект;//например, User
var writer = Ext.create('Ext.data.writer.Json');
Ext.Ajax.request({
url: 'myUrl',
jsonData: writer.getRecordData(record),
method: 'POST',
Viktor Koltcov: Очевидные минусы знаю в сравнении с SOAP: протокол SOAP на порядок мощнее и лучше развит, но это относится к межсерверному взаимодействию, а не к взаимодействию клиент-сервер. Касательно клиент-сервера явных минусов не припомню, но я не вдавался в сравнения, может минусы и есть...
Выполнил ваш код, копия выглядит идентично оригиналу, по крайней мере в части форматирования ячеек. Может быть, проблема не в POI, а самом файле: часто бывает так, что даже сам Excel при открытии файла сообщает о том, что что-то не смог понять...
Это не я дал приложение, а Apache, я лишь нашел ссылку... Да, это готовое веб-приложение (сайт). Перед тем, как дать ссылку, я проверил его работоспособность: просто закинул в папку webapps в Tomcat-е и зашел по URL localhost/sample.
Я бы посоветовал больше читать Интернет, практиковаться и меньше задавать вопросов, если хотите расти профессионально...
Николай Павлов: затраты памяти - только одно из массы свойств фреймворка, а, как я уже говорил, у каждой технологии свои минусы и свои плюсы... JSF - серверное решение, поэтому ему нужны ресурсы сервера; GWT - это JavaScript, который позволяет немалую часть вычислений перенести на клиента. По поводу потребляемых ресурсов: у меня сейчас стартап с использованием JSF крутится на виртуальном хостинге. Там Windows (!), на нем MySQL и Tomcat вместе. Серверу выделен 1ГБ памяти, фактическое потребление 90% времени - 600МБ. Был момент, когда я 2 месяца туда не заходил, и за это время "утекло" 400 МБ; как оказалось, их "съели" пара служб Windows, которые я просто отключил. Приложению периодически приходится обрабатывать нагрузку до 20 запросов в секунду длительное время, без проблем с отзывчивостью. Да и вообще, в наше время ресурсы железа стоят копейки...
Николай Павлов: ну, мне незачем верить Вам на слово по поводу GWT, у меня есть опыт и в JSF и в GWT, причем многолетний. Это абсолютно разные технологии, трудно их сравнивать. Даже парадигмы прямо противоположные - GWT - это Single Page, JSF же позволяет делать и ближе к классике и Single Page. На JSF "плюются" больше потому, что порог вхождения гораздо выше. Причем этот порог начинает ощущаться не сразу, а позже, когда дело доходит до сложных вещей. После того, как этот порог перешагнешь, большинство задач реализуются быстро и красиво...
Николай Павлов: ни разу не видел ни одного фреймворка для визуализации, на который не плевались... У JSF (а точнее - у его реализаций) есть свои плюсы и свои минусы, как и у любых других технологий.
Ссылки я дал для первичного ознакомления с JEE, т.к. EE явно указано в вопросе.
"Зачем ему JPA" - в вопросе указано что будет работа с СУБД. Писать даже небольшое приложение на чистом JDBC - не комильфо. Лично я даже в небольших утилитах использую JPA, и только радуюсь, сложнее они от этого не становятся, а код чище и понятнее. По поводу "WebServices" - там в ответе новичку можно почерпнуть знания о серверах приложений в общем и целом, а не только о WebServices.
"Overhead у JEE явно выше, чем у Spring" - вовсе нет. Что Spring, что JEE в основном - набор аннотаций, которые вы указываете в своих классах, размер у них один и тот же. Более того, в абсолютном большинстве случаев приложение, использующее Spring, работает под управлением сервера приложений, а это контейнер в контейнере. Моё мнение по этому поводу по 4-й ссылке, повторю здесь: Какой web framework для java выбрать?