Николай Павлов: Аргументация в вашем комментарии наводит на мысль о неприкрытом троллинге. Есть что сказать конкретно - говорите. Лень писать - сдержитесь и промолчите.
"в которую я посылаю запросы" - судя по всему, требуется не развернуть свой веб-сервис (серверную часть), а подключиться к существующему (клиент веб-сервиса).
Да, нужно сгенерировать классы. Когда будете разбираться с командой генерации настоятельно рекомендую найти опцию, указывающую в какой пакет их "положить", чтобы не мусорить в своих исходниках. Когда сгенерированные классы будут готовы, потребуется еще несколько строчек: создание экземпляра веб-сервиса, указание ему URL (зачастую URL в WSDL указывает не туда. например в localhost), и непосредственно вызов метода веб-сервиса.
URL url = new URL("localhost:9999/ws/hello?wsdl");
QName qname = new QName("ws.mkyong.com", "HelloWorldImplService");
Service service = Service.create(url, qname);
HelloWorld hello = service.getPort(HelloWorld.class);
BindingProvider bindingProvider = (BindingProvider) port;
bindingProvider.getRequestContext().put(
BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
"foo:8086/HelloWhatever");
System.out.println(hello.getHelloWorldAsString("mkyong"));
alexander007: Java EE - это не набор средств, а спецификация, набор абстрактных API, которые должны реализовывать фреймворки и сервера приложений. Прикладной разработчик использует API Java EE в своем коде, но работать оно не будет до тех пор, пока к проекту не будет подключен фреймворк(-и) или проект не будет развернут под управлением сервера приложений. При этом сервер приложений, по сути, просто набор тех же фреймворков, развернутых и настроенных на веб-сервере.
Пример. Указываю классу аннотацию @WebService. Согласно спецификациям Java EE обычный Java-класс после добавления этой аннотации должен стать веб-сервисом. Но если вы запустите Java-приложение, содержащее этот класс под управлением "голой" Java-машины, то ничего не произойдет, веб-сервис не появится. Если же развернуть приложение под управлением сервера приложений, реализующего спецификации Java EE, то он, с помощью фреймворков развернет класс как веб-сервис.
По поводу почитать, ничего не подскажу, т.к. сам полноценных книжек, увы, не читал, все что знаю почерпнул исключительно из практики...
Николай Григорьев: То ли невнимательно читаете, то ли в заблуждение вводите. У вас везде в примерах есть providerId, а вы говорите что нет. Ваш второй пример правильнее. А по поводу 2-х SQL-запросов - посмотрите что там за запросы, наверняка они осуществляют выборку связных таблиц и не имеют никакого отношения к тому, каким образом накладывалось условие выборки.
Настоятельно рекомендую рассмотреть возможность выполнения хотя бы части расчетов на клиенте. Андроид - это Java, "толстый" клиент, который может исполнять практически любую логику. Подумайте, что такого у вас есть на сервере, чего нельзя отдать клиенту? Наверняка, таких данных не так уж и много. Практически любое Андроид-устройство имеет в запасе приличные вычислительные мощности, а десяток современных смартфонов переплюнут по производительности любой доступный по цене VPS-сервер. Зачем нагружать сервер, при этом имея простаивающих в ожидании ответа клиентов? Пусть тоже работают!
А на каком этапе и с использованием каких средств вы видите "???". Есть вероятность того, что из БД считалось одинаково, а "сломалось" уже при отображении. Например, "обычное" приложение выводит результат в консоль среды разработки, а Tomcat в лог-файл, а это разные условия отображения. Если это так, то попробуйте посмотреть значения под отладкой, или напишите код, сохраняющий считанные значения в файл, и чтобы этот код был идентичен в обоих вариантах.
Обычно, тонкие клиенты в Java хранят данные в сессии на сервере, поэтому проблемы с сохранением быть не должно - объект даты создан на сервере и сохранен там же. Остается только проблема с верным отображением ее на клиенте, и тут - да, нужны определенные действия:
1. Везде, где дата преобразовывается в строковое представление, желательно применять форматирование с учетом временной зоны.
2. Соответственно, чтобы это работало, в сессии пользователя должна иметься его временная зона.
Временную зону можно вытащить в браузере JavaScript-ом. Чтобы не заморачиваться с возможными тонкостями и со спецификой различных браузеров, я использую готовое решение https://bitbucket.org/pellepim/jstimezonedetect. Имея эту библиотеку на странице, остается сделать примерно так:
var timezone = jstz.determine();
var input = $("#timezone_holder");
input.val(timezone.name());
Т.е. "вытащили" зону и сохранили в каком-либо элементе формы, чтобы затем сделать сабмит на сервер. Я использую JSF/AJAX, поэтому для того, чтобы сделать сабмит я сразу после получения делаю:
input.change();
Могут быть и другие варианты, главное что должно быть понятно куда "копать"...
Видимо, для своего API Вы решили использовать REST веб-сервисы? Тогда правильнее будет сказать "развернуть API на REST". Поясню - при реализации REST-сервисов вы будете использовать аннотации Java API, это интерфейсные аннотации, не привязанные к реализации. Такие фреймворки, как Jersey, AXIS или CXF, осуществляют реализацию интерфейсов. Таким образом, ваш код не должен изменится, если вы смените одну реализацию на другую. Измениться может лишь состав библиотек в вашем приложении и конфигурационные файлы. Т.е., вы сейчас потратите время на развертывание Jersey, а затем, при переходе на Spring и идущий с ним в комплекте движок веб-сервисов, придется еще раз потратить время на то, чтобы удалить Jersey из проекта, и настроить движок веб-сервисов в Spring. При этом REST-API вашего приложения не изменится
@UbuRus По поводу хостинга - это мое личное мнение. Мой стартап pdiag.ru крутится у них на хостинге уже более полугода, и никаких поводов для смены хостинга я не вижу. По поводу "не нравится" - сравните мой ответ и свой по информативности и полноте. Почему бы вам, как человеку "неприкрыто" рекламирующему Heroku не написать подробнее о личном опыте развертывания на нем Java-приложений? Лично мне бы было интересно, автору вопроса, скорее всего, тоже.
@bimeg, поддерживаю. Плюс не забываем о освобождении ресурсов, ведь автор с БД работает. В таких случаях нужен блок finally{} для освобождения ресурсов, а в catch{} неплохо бы подумать и о rollback...
Видимо, я не до конца понял суть вопроса. Т.е., объект Group в User вам вообще не нужен? Тогда работайте с groupId как с обычным полем, не указывайте никаких констрейнтов на уровне бизнес-логики, оставьте их лишь на уровне СУБД. Указание @ManyToOne требуется лишь в тех случаях, когда вы хотите дать команду Hibernate предоставить вам готовый объект, считанный из БД, а раз объект не нужен, то и аннотация не нужна. Насчет целостности - ее Hibernate не проверяет независимо от того, указан @ManyToOne для поля или нет, эта работа возлагается на СУБД при любом варианте.
Во втором вашем варианте просто замените @ManyToOne и @JoinColumn на @Basic
А зачем проверка name != null?
Так не проще ли:
if (name == null || name.trim().isEmpty()) { ...
Если первое условие true, то сразу будет переход в блок, без проверки следующего условия. Т.е., если name == null, то name.trim().isEmpty() не будет вызван, и, соответственно, дополнительная проверка на null не нужна.
Понятно. Имея EAR вам не нужно будет иметь конфиг в БД, его заменит application.xml. Вы же в любом случае при установке принимаете решение какие модули положить на сервер, думаю, что не проблема отразить это в application.xml. В принципе, можно иметь один EAR на все конфигурации, а при установке клиенту удалять ненужные модули в application.xml (JBoss 7 игнорирует модули, находящиеся в EAR, но не указанные в application.xml). Либо иметь набор преднастроенных конфигураций (файлов application.xml) и подменять их в пакете установки перед передачей клиенту.
Про то, чем является "лишняя сущность EAR" я уже итак немало написал. Добавлю лишь, что в JBoss 7 значительно изменились принципы и механизмы загрузки классов и доступности их приложениям. То, что у вас работало под JBoss 6, скорее всего, было идеологически/архитектурно неверно, и JBoss 7 прямо указал вам на ошибки архитектуры, выбросив исключение NoClassDefFoundError. Вы зря так упираетесь в нежелании что-то менять, это я вам говорю как человек, перенесший 2 серьезных JEE Системы по пути JBoss 4 -> JBoss 5 -> JBoss 7. Ни один из переходов не был безболезненным, причем последний JBoss 7 доставил наибольшее количество хлопот. В основном это связано с тем, что для полного его соответствия спецификации JEE 6 пришлось фактически разработать новый продукт.
Вам стоит принять решение - либо переработать ПО и соответствовать архитектуре JBoss 7 и JEE6, либо отказаться от перехода вовсе. В 7-ке нет каких-то особых новых крутых "фич" - лишь обновленные версии сервисов и новая архитектура. Более того, в ней нет многих вещей, которые были в предыдущих версиях и для моих проектов были просто незаменимы, т.е. перейдя на 7-ку пришлось делать их самому.
@opium т.е., любой субподряд можно считать нелегальным? Заказчик заключает договора и платит одной организации, а фактически работу выполняет другая - явно какой-то "черный метод"...
По поводу конфигурации я не понял, но, вероятно, следует пересмотреть принципы конфигурирования ПО. Конфигурация структуры приложения (в различных xml-файлах WAR-ов и EAR-ов) обычно меняется редко, и практически всегда связана с обновлением и редеплоем приложения. А вот за специфическую конфигурацию логики приложения ответственно оно само, и по хорошему конфигурация логики не должна быть связана со структурой приложения. Если я правильно понял, вы в админке меняете настройки и сохраняете в БД, но они вступают в силу только после редеплоя приложения. Такое может быть если настройки кешируются в памяти приложения. Тут стоит рассмотреть вариант обновления кеша: либо по событию, поступившему из админки при изменении параметра, либо по расписанию...
Если ваши WAR находились вне EAR (находились в папке deploy) - значит фактически это было не одно приложение, а несколько независимых приложений. Непонятно, каким образом в такой структуре разворачивались EJB - куда вы ложили JAR-файлы и каким образом указывали JBoss-у что это приложение, а не что-либо ещё...
В любом случае, настоятельно рекомендую объединить все модули (EJB, WAR и что там у вас еще есть) в EAR, только после этого их действительно можно считать единым приложением. Я добавил рекомендации о том, как это сделать, в свой ответ.
UserDAO.findUserItem(user, itemShop) с базой работает? Если да, то там создается новая сессия, и вряд ли после ее создания проходит "1 год" до достижения строчки session.merge(user).