Comments 15
А jade не рассматривали или чем то не угодил? scalate.fusesource.org/documentation/jade.html
После двухгодичного использования slim на ruby (потомок jade, кстати) обычные теги глаза режут)
После двухгодичного использования slim на ruby (потомок jade, кстати) обычные теги глаза режут)
Scalate, круто, мы вот с thymeleaf мучаемся, но тихонько смотрим в сторону Scalate. Пугают огромные размеры scala библиотек.
Действительно, мой собранный проект-пустышка занимает сейчас 39 мегабайт. Scala библиотеки отъедают около половины(~ 25 мегабайт).
В моем случае размер получаемого war-архива не столь критичен.
Подробнее какие библиотеки(что сколько чего занимает в предлагаемом примере):
В моем случае размер получаемого war-архива не столь критичен.
Подробнее какие библиотеки(что сколько чего занимает в предлагаемом примере):
drwxr-xr-x 42 dionis staff 1.4K May 6 13:20 ./
drwxr-xr-x 10 dionis staff 340B May 6 13:20 ../
-rw-r--r-- 1 dionis staff 435K Feb 20 10:58 antlr-2.7.7.jar
-rw-r--r-- 1 dionis staff 4.4K Feb 20 10:57 aopalliance-1.0.jar
-rw-r--r-- 1 dionis staff 108K Feb 20 21:44 bonecp-0.8.0.RELEASE.jar
-rw-r--r-- 1 dionis staff 1.6K May 5 14:11 common-1.0-SNAPSHOT.jar
-rw-r--r-- 1 dionis staff 376K Feb 20 21:44 commons-lang3-3.2.1.jar
-rw-r--r-- 1 dionis staff 61K Feb 20 10:58 commons-logging-1.1.3.jar
-rw-r--r-- 1 dionis staff 12K May 5 14:11 data-1.0-SNAPSHOT.jar
-rw-r--r-- 1 dionis staff 307K Feb 20 10:58 dom4j-1.6.1.jar
-rw-r--r-- 1 dionis staff 2.1M Feb 20 21:45 guava-15.0.jar
-rw-r--r-- 1 dionis staff 1.5M Feb 20 21:45 h2-1.3.172.jar
-rw-r--r-- 1 dionis staff 80K Feb 20 10:58 hibernate-commons-annotations-4.0.2.Final.jar
-rw-r--r-- 1 dionis staff 4.4M Feb 20 10:58 hibernate-core-4.2.2.Final.jar
-rw-r--r-- 1 dionis staff 473K Feb 20 10:58 hibernate-entitymanager-4.2.2.Final.jar
-rw-r--r-- 1 dionis staff 100K Feb 20 10:58 hibernate-jpa-2.0-api-1.0.1.Final.jar
-rw-r--r-- 1 dionis staff 34K Feb 20 21:44 jackson-annotations-2.3.0.jar
-rw-r--r-- 1 dionis staff 193K Feb 20 21:44 jackson-core-2.3.0.jar
-rw-r--r-- 1 dionis staff 893K Feb 20 21:44 jackson-databind-2.3.0.jar
-rw-r--r-- 1 dionis staff 633K Feb 20 10:58 javassist-3.15.0-GA.jar
-rw-r--r-- 1 dionis staff 59K Feb 20 10:58 jboss-logging-3.1.0.GA.jar
-rw-r--r-- 1 dionis staff 25K Feb 20 10:58 jboss-transaction-api_1.1_spec-1.0.1.Final.jar
-rw-r--r-- 1 dionis staff 470K Feb 20 21:44 log4j-1.2.16.jar
-rw-r--r-- 1 dionis staff 14M May 5 13:54 scala-compiler-2.10.4.jar
-rw-r--r-- 1 dionis staff 6.8M Mar 19 20:08 scala-library-2.10.0.jar
-rw-r--r-- 1 dionis staff 3.0M Mar 19 20:06 scala-reflect-2.10.0.jar
-rw-r--r-- 1 dionis staff 1.9M Feb 20 21:45 scalate-core_2.10-1.6.1.jar
-rw-r--r-- 1 dionis staff 24K Feb 20 21:45 scalate-spring-mvc_2.10-1.6.1.jar
-rw-r--r-- 1 dionis staff 288K Feb 20 21:44 scalate-util_2.10-1.6.1.jar
-rw-r--r-- 1 dionis staff 25K Feb 20 21:44 slf4j-api-1.7.5.jar
-rw-r--r-- 1 dionis staff 8.7K Feb 20 21:44 slf4j-log4j12-1.7.5.jar
-rw-r--r-- 1 dionis staff 344K Mar 19 17:24 spring-aop-4.0.2.RELEASE.jar
-rw-r--r-- 1 dionis staff 653K Mar 19 17:26 spring-beans-4.0.2.RELEASE.jar
-rw-r--r-- 1 dionis staff 951K Mar 19 17:26 spring-context-4.0.2.RELEASE.jar
-rw-r--r-- 1 dionis staff 132K Mar 19 17:26 spring-context-support-4.0.2.RELEASE.jar
-rw-r--r-- 1 dionis staff 938K Mar 19 17:26 spring-core-4.0.2.RELEASE.jar
-rw-r--r-- 1 dionis staff 200K Mar 19 17:26 spring-expression-4.0.2.RELEASE.jar
-rw-r--r-- 1 dionis staff 410K Mar 19 17:26 spring-jdbc-4.0.2.RELEASE.jar
-rw-r--r-- 1 dionis staff 358K Mar 19 17:26 spring-orm-4.0.2.RELEASE.jar
-rw-r--r-- 1 dionis staff 242K Mar 19 17:26 spring-tx-4.0.2.RELEASE.jar
-rw-r--r-- 1 dionis staff 649K Mar 19 17:26 spring-web-4.0.2.RELEASE.jar
-rw-r--r-- 1 dionis staff 645K Mar 19 17:26 spring-webmvc-4.0.2.RELEASE.jar
Так ведь большинство библиотек можно положить в контейнер и не таскать каждый раз в war.
Да, но на мой взгляд в этом нет большого смысла — кроме нескольких секунд сэкономленных при заливании war'a на сервер и его распаковке мы фактически ничего не выигрываем, а скорее наоборот обновлять библиотеки становится проблематичным, ведь допустим с минорным апдейтом того же Spring'a, скажем с версии 4.0.2 на 4.0.3 какая-то из его транзитивных зависимостей может поменяться и, получается, придется вручную все это просматривать и следить за всем этим.
а так можем словить OOM при deploy, ежели со всеми зависимостями заливать.
Библиотеки когда меняются, несложно их перезалить в shared-lib каталог Tomcat. Да и перезаливка war всяко чаще происходит чем обновление версий зависимостей.
Библиотеки когда меняются, несложно их перезалить в shared-lib каталог Tomcat. Да и перезаливка war всяко чаще происходит чем обновление версий зависимостей.
Я, и в фирме где я работаю, существует внегласное правило — под одним контейнером бежит одно приложение. Поэтому, у нас деплоймент выглядит следующим образом:
1). Останавливается контейнер(в нашем случае — Tomcat).
2). Стирается все из webapps директории
3). Стирается все из work директории
4). Заливается новый war
5). Контейнер(Tomcat) запускается
Таким образом мы избегаем главной проблемы, связанной с redeployment'ом — OOM.
Это работает в случае с приложениями, где down-time возможен и не мешает.
В случае, где downtime недопустим — у нас бежит несколько инстансов томката за лоадбалансером, и каждый инстанс редеплоится именно таким образом, что исключает downtime при backward-compatible изменениях базы данных.
1). Останавливается контейнер(в нашем случае — Tomcat).
2). Стирается все из webapps директории
3). Стирается все из work директории
4). Заливается новый war
5). Контейнер(Tomcat) запускается
Таким образом мы избегаем главной проблемы, связанной с redeployment'ом — OOM.
Это работает в случае с приложениями, где down-time возможен и не мешает.
В случае, где downtime недопустим — у нас бежит несколько инстансов томката за лоадбалансером, и каждый инстанс редеплоится именно таким образом, что исключает downtime при backward-compatible изменениях базы данных.
UFO just landed and posted this here
Мне в последние годы казалось, что Server Pages — сильно устаревшая технология, т.к. все тонкие клиенты для JEE, с которыми сталкивался (существующие или которые начинал с нуля сам) делались на JSF либо GWT. Да и вообще, за 10+ лет разработки на Java ни разу не видел JSP в качестве основного инструмента «рисования» View. Мне вот интересно, кроме примера в статье, у Вас реальные JEE проекты крутятся на JSP/SSP?
По поводу перехода на Java 8. Есть у меня проект на Java 7, Tomcat 7, MySQL, JSF, Hibernate. Попытался переключиться на Java 8, вроде без проблем. Попытался тут же применить что-то новое, нашел подходящую структуру, в которую «просился» default метод интерфейса. Переделал, запустил, но — увы — реализация EL на JSF страничке, которая раньше «понимала» метод в абстрактном классе, не нашла тот же метод в интерфейсе. Ну понятно, думаю, 7-й Tomcat восьмую Java не поддерживает, надо 8-й Tomcat попробовать (библиотека EL идет в комплекте с Tomcat-ом). Ставлю 8-й Tomcat, который как оказалось стартует вдвое дольше 7-го, и вижу, что ничего не изменилось — та же ошибка. Дальше копать не стал, т.к. в моем случае овчинка выделки не стоит… И, кстати, поиграйтесь с фичами Java 8 на JSP страничке, вполне вероятно, что интерпретатор JSP тоже «сломается», как и парсер EL…
По поводу перехода на Java 8. Есть у меня проект на Java 7, Tomcat 7, MySQL, JSF, Hibernate. Попытался переключиться на Java 8, вроде без проблем. Попытался тут же применить что-то новое, нашел подходящую структуру, в которую «просился» default метод интерфейса. Переделал, запустил, но — увы — реализация EL на JSF страничке, которая раньше «понимала» метод в абстрактном классе, не нашла тот же метод в интерфейсе. Ну понятно, думаю, 7-й Tomcat восьмую Java не поддерживает, надо 8-й Tomcat попробовать (библиотека EL идет в комплекте с Tomcat-ом). Ставлю 8-й Tomcat, который как оказалось стартует вдвое дольше 7-го, и вижу, что ничего не изменилось — та же ошибка. Дальше копать не стал, т.к. в моем случае овчинка выделки не стоит… И, кстати, поиграйтесь с фичами Java 8 на JSP страничке, вполне вероятно, что интерпретатор JSP тоже «сломается», как и парсер EL…
У нас Web(фронт-энд для нашего rest-service'a) и Admin Panel крутится сейчас именно на Spring, Spring MVC и JSP используется в качестве View. Насчет фич 8-ой java и дергания логики из View — на мой взгляд не очень хорошая идея. У нас на/c JSP передаются DTO объекты, которые в свою очередь трансформируются в DTO объекты сервисного уровня, которые уже в свою очередь преобразуются из/в объекты модельного уровня. С одной стороны, это может показаться избыточным(для простых приложений), с другой стороны это лучше позволяет разделить слои приложений и переиспользовать код.
Насчет SSP — я его обкатываю на своих личных проектах в первую очередь, прежде чем предложить использовать его в Production(с большой буквы), но пока что в целях — есть желание внедрить эту технологию отображения для начала, хотя бы для Admin Panel нашего сервиса.
Насчет JSF — личного опыта работы с ним я не имею, но от своих коллег, которые работали с данной технологией, я слышал не лестные отзывы. К ним относится — тормозит, если написаны какие-то кастомные компоненты, то при апгрейде на новую версию JSF их нужно зачастую сильно переделывать, что бы они заработали, кастомизировать под свои нужды внешний вид — тоже то еще занятие.
Насчет GWT — я немного пощупал эту технологию, и мне в принципе даже понравилось, но из минусов — довольно сложно изменять внешний вид, то есть я бы стал использовать только в том случае, если нужно набросать по-быстрому какой-то административный UI, где внешний вид не важен, так как кастомизировать отображение выходит сложнее, чем если это написать все с использованием более простых технологий.
Насчет SSP — я его обкатываю на своих личных проектах в первую очередь, прежде чем предложить использовать его в Production(с большой буквы), но пока что в целях — есть желание внедрить эту технологию отображения для начала, хотя бы для Admin Panel нашего сервиса.
Насчет JSF — личного опыта работы с ним я не имею, но от своих коллег, которые работали с данной технологией, я слышал не лестные отзывы. К ним относится — тормозит, если написаны какие-то кастомные компоненты, то при апгрейде на новую версию JSF их нужно зачастую сильно переделывать, что бы они заработали, кастомизировать под свои нужды внешний вид — тоже то еще занятие.
Насчет GWT — я немного пощупал эту технологию, и мне в принципе даже понравилось, но из минусов — довольно сложно изменять внешний вид, то есть я бы стал использовать только в том случае, если нужно набросать по-быстрому какой-то административный UI, где внешний вид не важен, так как кастомизировать отображение выходит сложнее, чем если это написать все с использованием более простых технологий.
Насчет фич 8-ой java и дергания логики из View — на мой взгляд не очень хорошая идеяНу, логика — понятие растяжимое, даже в вашем примере person.id вполне мог бы быть default методом какого-нибудь интерфейса Identifier, например, при каждом обращении к getId генерирующим новый сиквенс, чисто теоретически…
По поводу технологий — вечный холивар, у каждой есть плюсы и минусы, не будем об этом. Но вот по поводу JSP — мне кажется, что довольно тяжело расписывать для каждой странички каждый тег. Либо ваша Admin Panel выглядит очень убого, либо на каждую страничку у вас исходники на много сотен строк, либо у вас не чистый JSP, а подключена какая-то библиотека виджетов. Насколько я помню, на заре JSF нередко View рисовался именно на JSP-странице. В общем, чисто из любопытства, скажите, что представляет из себя ваша Admin Panel: много ли страничек, каков внешний вид, какой объем кода типичной странички?
Общий шаблон у нас вынесен и используется sitemesh. Остальные странички выглядят довольно просто. Сейчас в admin panel'e что-то около 15-20 страниц. Используется twitter bootstrap, что делает страницу относительно симпатичной, jQuery библиотека, underscore js и еще несколько по мелочи. Объем кода на страничках варьируется. В среднем что-то около 50-100, если нигде js не понаписан дополнительный.
Sign up to leave a comment.
Java 8, Spring, Hibernate, SSP — начинаем играться