Комментарии 38
Спасибо за ссылку на freenom.com, теперь буду использовать
Я использую gradle для spring-boot, и немного другой скрипт запуска:
Данный скрипт скидывает pid процесса в файл application.pid, и можно легко остановить приложение:
И я советую все таки использовать gradle, нежели maven, с ним все намного проще. Вот небольшое приложение (исходники) на spring-boot + gradle + шаблонизатор twig github.com/jphp-compiler/j-php.net
chmod +x gradlew
nohup ./gradlew bootRun > application.log 2> application.errors.log < /dev/null &
PID=$!
echo $PID > application.pid
Данный скрипт скидывает pid процесса в файл application.pid, и можно легко остановить приложение:
if [ ! -f application.pid ]; then
echo "Server is not running... ";
exit 0
fi
PID=$(cat application.pid)
kill $PID
И я советую все таки использовать gradle, нежели maven, с ним все намного проще. Вот небольшое приложение (исходники) на spring-boot + gradle + шаблонизатор twig github.com/jphp-compiler/j-php.net
Мдяя. Где Spring Data? Зачем городить закат солнца в ручную? Второй вопрос зачем вам spring boot если в итоге вы запускаете apache чтобы проксировать туда запросы? Для проксирования уж явно удобнее nginx. Ну а на уровне java лучше уже servlet container взять. Удобнее потом деплоить.
Где Spring Data?
Всмысле где spring data? А связка JPA+Hibernate и подключение к postgres — это не оно?
В том же Pom.xml есть
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
А почему я не использовал различные аннотации, я написал — все для производительности. Ну не нужно оно тут. Однако если к примеру в приведенном примере аннотировать метод через @Transactional, то это будет работать, через JpaTransactionManager. То есть если что-то конкретно тут не используется, то это не значит, что этого нет.
Зачем городить закат солнца в ручную?
Не совсем понял вопрос +)
Второй вопрос зачем вам spring boot если в итоге вы запускаете apache чтобы проксировать туда запросы?
Всмысле зачем? Я же написал, что если приложение работает на порте, отличном от 80, то потребуется прокси, чтобы не вводить порт вручную. А томкат по умолчанию работает на порте 8080. Конечно, может и можно было бы указать ему явно 80 порт, но к прокси серверу можно прикрутить еще немало интересных вещей, поэтому описал как это сделать.
Для проксирования уж явно удобнее nginx.
Можно и nginx, не спорю. Просто на моем сервере уже стоял настроенный apache2, поэтому привел его для примера. Примером про apache2 я пытался донести мысль, как реагировать, если приложение не будет открываться, когда и сервер вроде запущен, и DNS настроен, а сайт не открывается.
Ну а на уровне java лучше уже servlet container взять. Удобнее потом деплоить.
А по вашему на чем запускается описанное приложение? Embedded tomcat 8. Да, возможно у внешнего томката есть преимущества, но опять таки тут меньше настроек и быстрее развертывание.
Всмысле где spring data? А связка JPA+Hibernate и подключение к postgres — это не оно?
Нет. У Spring Data есть вполне конкретное применение. Убирание написания реализации репозитория. Т.е. будет:
import org.springframework.data.jpa.repository.JpaRepository;
public interface DataRepository extends JpaRepository<DomainObject, UUID> {
}
Вместо того что вы написали. И все. Надо добавить вызов? Добавляем декларативно метод или запрос через аннотацию. Ну и аннотировать не забываем таблицу аннотациями JPA. Это прям в документации Spring Data и написано. Он убирает одно из самых муторных действий при работе со Spring.
Всмысле зачем? Я же написал, что если приложение работает на порте, отличном от 80, то потребуется прокси, чтобы не вводить порт вручную.
Намекаю, apache2 не самый лучший вариант для проксирования.
А по вашему на чем запускается описанное приложение? Embedded tomcat 8. Да, возможно у внешнего томката есть преимущества, но опять таки тут меньше настроек и быстрее развертывание.
Угу, а потом еще одно приложение и еще один отдельный tomcat, я уже молчу про обновление приложения и радости администратора который будет это сопровождать.
Спасибо, теперь я понял, что вы имели ввиду =)
Постараюсь учесть это и вскоре применить на практике.
Постараюсь учесть это и вскоре применить на практике.
Там есть еще удобный AbstractPersistable и интеграция с QueryDSL. Если еще не видели посмотрите, да и вообще я бы советовал использовать QueryDSL.
Удобство это конечно хорошо, но как обстоят дела с производительностью? Как уже говорил, Hibernate+JPA очень сильно проигрывает в производительности тому же jdbcTemplate. А что с QueryDSL? Есть какие-нибудь результаты тестов для сравнения?
У Hibernate/JPA с производительностью все нормально, если уметь пользоваться. Просто на каждую возникающую проблему есть usecase, например n+1 проблема решается джоинами, либо дополнительным селектом.
Конечно есть ситуации когда приходится сидеть и разбираться что это он там копается и где это он там глючит и так далее. Но спустя время их почти не остается.
QueryDSL это типобезопасный язык запросов, все запросы(если они не динамические) компилируются, а следовательно не возникает проблем с опечатками, с забывчивостью в установке параметров запросов и так далее. Этот DSL может работать как поверх JDBC так и поверх JPA, и даже простых Java коллекций.
Больше всего проблем в связке Hibernate/JPA + Spring Data JPA + QueryDSL занимает Spring Data JPA, потому что API которое он предлагает по умолчанию очень слабое. Запросы пишутся либо с помощью аннотации Query, либо с помощью названия метода
findAllByAccount(String account)
либо с помощью стандартных средств Hibernate/JPA(я использую QueryDSL).
Получается что для простых ситуаций Spring Data подходит но для чего то посложней уже приходится искать более удобные варианты.
Ну и наконец касательно JDBC и производительности в целом, нет ничего лучше чистого JDBC(для Java) для написания запросов в плане производительности, тут у нас полная свобода пишем что хотим управляем кешированием зарпосов и так далее. Но часто нам нужен компромис между скоростью запросов и скоростью написания кода, в таком случае лучше начать с Spring Data и плавно переводить узкие места на JDBC. Например JPA очень плохо(во всяком случае я не нашел) работает с деревьями, нет штатных средств для Closure Table, Nested Sets и т.д. Тут мы используем чистый JDBC(у нас Closure Table в которой храним инфу о дереве).
Конечно есть ситуации когда приходится сидеть и разбираться что это он там копается и где это он там глючит и так далее. Но спустя время их почти не остается.
QueryDSL это типобезопасный язык запросов, все запросы(если они не динамические) компилируются, а следовательно не возникает проблем с опечатками, с забывчивостью в установке параметров запросов и так далее. Этот DSL может работать как поверх JDBC так и поверх JPA, и даже простых Java коллекций.
Больше всего проблем в связке Hibernate/JPA + Spring Data JPA + QueryDSL занимает Spring Data JPA, потому что API которое он предлагает по умолчанию очень слабое. Запросы пишутся либо с помощью аннотации Query, либо с помощью названия метода
findAllByAccount(String account)
либо с помощью стандартных средств Hibernate/JPA(я использую QueryDSL).
Получается что для простых ситуаций Spring Data подходит но для чего то посложней уже приходится искать более удобные варианты.
Ну и наконец касательно JDBC и производительности в целом, нет ничего лучше чистого JDBC(для Java) для написания запросов в плане производительности, тут у нас полная свобода пишем что хотим управляем кешированием зарпосов и так далее. Но часто нам нужен компромис между скоростью запросов и скоростью написания кода, в таком случае лучше начать с Spring Data и плавно переводить узкие места на JDBC. Например JPA очень плохо(во всяком случае я не нашел) работает с деревьями, нет штатных средств для Closure Table, Nested Sets и т.д. Тут мы используем чистый JDBC(у нас Closure Table в которой храним инфу о дереве).
Я кстати ради интереса делал тест сравнения jdbcTemplate и чистого jdbc-драйвера. Результаты оказались практически одинаковыми(запросы попеременно выполнялись быстрее то на jdbcTemplate, то на jdbc-драйвере, что означает что тут уже на производительность влияла сама база данных).
А из личного опыта, если нагрузка очень большая и данных терабайты, то приходится переписывать код на hibernate на чистый SQL, причем не абы какой, а оптимизированный под конкретную базу данных. А все потому что есть некие тайные знания под каждую базу данных(или ее особенности), которые позволяют ускорить некоторые запросы на порядки. Я не DBA, но на эту тему вроде где-то есть презентация на www.highload.ru для postgres'а. Поэтому да, для проектов, где нагрузка относительно небольшая, можно использовать JPA+Hibernate. Но случись что, потом придется долго и мучительно переписывать код, если вдруг концепция поменяется :)
А из личного опыта, если нагрузка очень большая и данных терабайты, то приходится переписывать код на hibernate на чистый SQL, причем не абы какой, а оптимизированный под конкретную базу данных. А все потому что есть некие тайные знания под каждую базу данных(или ее особенности), которые позволяют ускорить некоторые запросы на порядки. Я не DBA, но на эту тему вроде где-то есть презентация на www.highload.ru для postgres'а. Поэтому да, для проектов, где нагрузка относительно небольшая, можно использовать JPA+Hibernate. Но случись что, потом придется долго и мучительно переписывать код, если вдруг концепция поменяется :)
Проблема в том что любой ORM это текущая абстракция. Это надо учитывать при реализации и написании запросов.
Исправил статью, описал как настраивать nginx.
Угу, а потом еще одно приложение и еще один отдельный tomcat, я уже молчу про обновление приложения и радости администратора который будет это сопровождать.
Лучше множество маленьких приложений, чем одна большая JVM.
Маленькое приложение можно рестартануть в случае проблем, с большим могут быть проблематично это сделать.
Да, есть лишние траты на память, но плюсов несравненно больше.
Изолированность, возможность выдерживать нагрузку (если, к примеру, идет нагрузка на определенный компонент, то можно запустить еще 10 нод только с этим компонентом).
Microservices, в общем.
Спасибо добрым дядям, что напомнили про XSS :)
Использовал StringEscapeUtils.escapeHtml4, но может кто-то знает более эффективные вещи?
Слышал про некий ESAPI от OWASP, но пока не разобрался в каком состоянии эта библиотека и стоит ли ее применять.
Использовал StringEscapeUtils.escapeHtml4, но может кто-то знает более эффективные вещи?
Слышал про некий ESAPI от OWASP, но пока не разобрался в каком состоянии эта библиотека и стоит ли ее применять.
Intellij Idea 14.1
А там вроде до сих пор не сделали нормальную поддержку Java config'а (вместо xml)?
В смысле, что в MVC будет варнинг о неиспользованном контролере, не будет подсказок во вью и т.п.:(
youtrack.jetbrains.com/issue/IDEA-87346
Сижу на 14.1.2, у меня Java based config, контроллер IDE вполне себе видит, да и все остальное тоже.
Странно, у меня тоже 14.1.2, только что проверил и в spring-boot-sample-web-jsp из офф. самплов, и в новом spring boot проекте с web + thymeleaf созданном через Idea, вышеописанные симптомы есть.
Продукт идеологически очень нужный и очень востребованный.
Однако настолько сырой, что пользоваться им нормально не представляется возможным… Изучение также начал с простой архитектуры, по учебнику все очень классно получается. Но только начинаешь наращивать функционал, тут же вылазит такое количество нюансов и специфических моментов, что вся эта экономия конфигурации становится просто смешной на фоне трудозатрат по имплементации своего функционала. Я сейчас не возьмусь перечислять все проблемы, решая которые, приходилось извращаться, но побившись об стену и получив кода больше, чем это делаешь традиционным способом, отказался пока от этой идеи. Поглядим за развитием продукта… возможно, чуть позже станет проще. В любом случае, для наращивания опыта и экспериментов использовать можно, но для серьезных проектов этот продукт пока не подходит.
Однако настолько сырой, что пользоваться им нормально не представляется возможным… Изучение также начал с простой архитектуры, по учебнику все очень классно получается. Но только начинаешь наращивать функционал, тут же вылазит такое количество нюансов и специфических моментов, что вся эта экономия конфигурации становится просто смешной на фоне трудозатрат по имплементации своего функционала. Я сейчас не возьмусь перечислять все проблемы, решая которые, приходилось извращаться, но побившись об стену и получив кода больше, чем это делаешь традиционным способом, отказался пока от этой идеи. Поглядим за развитием продукта… возможно, чуть позже станет проще. В любом случае, для наращивания опыта и экспериментов использовать можно, но для серьезных проектов этот продукт пока не подходит.
Вполне возможно. Но по идее же spring boot создает чисто каркас с нужными библиотеками и с парой аннотаций, которые подключают те же стандартные аннотации? А дальше уже чистый спринг, с его новомодной java based конфигурацией. Согласен, немного непривычно после xml, но плюс мне видится в том, что конфигурационная логика тут может быть гораздо более гибкой.
Кстати что именно нельзя сконфигурировать таким образом? Можете привести пример? Или вы имеете ввиду какие-нибудь специфичные xml-теги? Но даже если так, то разве нельзя подключить тот же xml при запуске, если вдруг потребуется?
Кстати что именно нельзя сконфигурировать таким образом? Можете привести пример? Или вы имеете ввиду какие-нибудь специфичные xml-теги? Но даже если так, то разве нельзя подключить тот же xml при запуске, если вдруг потребуется?
Ну, я xml вовсе не рассматривал как альтернативу. У меня была готовая Java конфигурация без единого xml со встроеным сервером (пробовал и Томкет, и Джетти). Я пробовал с нуля заменить ее на Spring Boot. Кроме этого, у меня в конфигурации был Security, а тут у Boot начинаются мраки. Видимо, прийдется заново попробовать настроить, чтобы поднять в памяти все подножки, иначе это бульки на воде.
Пул потоков мы берем самый модный и производительный (HikariCP).Какое отношение оно имеет к thread pool'ам? Оно же connection pool (замена dbcp/c3p0/tomcat-dbcp и подобных).
Еще бы приложение запакетировать в debian пакет и вообще будет здорово или хотя бы стартовать его через upstart \ systemd.
Мы используем Spring Boot как основу для всех наших сервисов. Оказалось очень удобно иметь во всех модулях одинаковую основу для запуска а также не быть зависимым от отдельного Tomcat (Используем Embedded Tomcat) Экономит кучу времени, сил и нервов: не приходиться вспоминать где, как, что нужно делать для запуска, что локально, что на сервере.
Насколько я помню, вот это все:
для MySQL драйвера, а не для Postgres
config.addDataSourceProperty("cachePrepStmts", "true");
config.addDataSourceProperty("prepStmtCacheSize", "250");
config.addDataSourceProperty("prepStmtCacheSqlLimit", "2048");
config.addDataSourceProperty("useServerPrepStmts", "true");
для MySQL драйвера, а не для Postgres
Для Spring довольно удобный Initializr на Web существует
start.spring.io
start.spring.io
Оставлю это здесь http://jhipster.github.io/
По поводу перезагрузки ресурсов без перезагрузки сервера. В офф доке сказано, что достаточно добавить maven-плагин (пруф):
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>springloaded</artifactId>
<version>1.2.0.RELEASE</version>
</dependency>
</dependencies>
</plugin>
В идеале хватит VPS. Достать его можно в разных местах, например www.digitalocean.com
раз уж тут и об этом зашла речь то дешевле достать можно тут, в наш век «импортозамещения» особенно )
Что-то я не понял, где идёт маппинг на index.html?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Spring Boot: от начала до продакшена