Comments 15
А jade не рассматривали или чем то не угодил? scalate.fusesource.org/documentation/jade.html
После двухгодичного использования slim на ruby (потомок jade, кстати) обычные теги глаза режут)
После двухгодичного использования slim на ruby (потомок jade, кстати) обычные теги глаза режут)
0
Scalate, круто, мы вот с thymeleaf мучаемся, но тихонько смотрим в сторону Scalate. Пугают огромные размеры scala библиотек.
0
Действительно, мой собранный проект-пустышка занимает сейчас 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
0
Так ведь большинство библиотек можно положить в контейнер и не таскать каждый раз в war.
0
Да, но на мой взгляд в этом нет большого смысла — кроме нескольких секунд сэкономленных при заливании war'a на сервер и его распаковке мы фактически ничего не выигрываем, а скорее наоборот обновлять библиотеки становится проблематичным, ведь допустим с минорным апдейтом того же Spring'a, скажем с версии 4.0.2 на 4.0.3 какая-то из его транзитивных зависимостей может поменяться и, получается, придется вручную все это просматривать и следить за всем этим.
0
а так можем словить OOM при deploy, ежели со всеми зависимостями заливать.
Библиотеки когда меняются, несложно их перезалить в shared-lib каталог Tomcat. Да и перезаливка war всяко чаще происходит чем обновление версий зависимостей.
Библиотеки когда меняются, несложно их перезалить в shared-lib каталог Tomcat. Да и перезаливка war всяко чаще происходит чем обновление версий зависимостей.
0
Я, и в фирме где я работаю, существует внегласное правило — под одним контейнером бежит одно приложение. Поэтому, у нас деплоймент выглядит следующим образом:
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 изменениях базы данных.
0
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…
0
У нас 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, где внешний вид не важен, так как кастомизировать отображение выходит сложнее, чем если это написать все с использованием более простых технологий.
+1
Насчет фич 8-ой java и дергания логики из View — на мой взгляд не очень хорошая идеяНу, логика — понятие растяжимое, даже в вашем примере person.id вполне мог бы быть default методом какого-нибудь интерфейса Identifier, например, при каждом обращении к getId генерирующим новый сиквенс, чисто теоретически…
По поводу технологий — вечный холивар, у каждой есть плюсы и минусы, не будем об этом. Но вот по поводу JSP — мне кажется, что довольно тяжело расписывать для каждой странички каждый тег. Либо ваша Admin Panel выглядит очень убого, либо на каждую страничку у вас исходники на много сотен строк, либо у вас не чистый JSP, а подключена какая-то библиотека виджетов. Насколько я помню, на заре JSF нередко View рисовался именно на JSP-странице. В общем, чисто из любопытства, скажите, что представляет из себя ваша Admin Panel: много ли страничек, каков внешний вид, какой объем кода типичной странички?
0
Общий шаблон у нас вынесен и используется sitemesh. Остальные странички выглядят довольно просто. Сейчас в admin panel'e что-то около 15-20 страниц. Используется twitter bootstrap, что делает страницу относительно симпатичной, jQuery библиотека, underscore js и еще несколько по мелочи. Объем кода на страничках варьируется. В среднем что-то около 50-100, если нигде js не понаписан дополнительный.
+1
Sign up to leave a comment.
Java 8, Spring, Hibernate, SSP — начинаем играться