Spring Framework 2.5

> Java - это JIT-компилируемый язык со статической типизацией.

Намек: JSF/JSP у нас тоже JIT-компилируются?

тоже.

>Намек: JSF/JSP у нас тоже JIT-компилируются?

Да. JSP транслируется в Java-код, который компилируется в байт-код, который JIT-компилируется в нативный код. JSF - это просто набор тэгов для JSP.

>Да, полагаю при таком раскладе Ява должна выиграть. (но что же это за ява без JEE AS? Тут же можно было и django обойтись :)

Мы свой мини-AS сделали на основе Atomikos+Spring+JBoss Cache+такая-то-мать :)

> Да. JSP транслируется в Java-код, который компилируется в байт-код, который JIT-компилируется в нативный код.

Судя по цепочке, Django начнет проигрывать лишь при числе обращений к jsp, стремящемуся к бесконечности...

> тоже.

А xml-ы из WEB-INF?

>А xml-ы из WEB-INF?

А их один раз надо прочитать при запуске приложения, и все. Учти еще, что Java (в отличие от PHP) не запускает на каждый запрос по интерпретатору PHP.

> Судя по цепочке, Django начнет проигрывать лишь при числе обращений к jsp, стремящемуся к бесконечности...

Святая наивность! :)
Эта операция делается единожды при первом обращении.

> А xml-ы из WEB-INF?
Аналогично. Считываются один раз при старте приложения.

Поскольку отношения времени работы WEB-приложения к времени запуска малая величина. Расходами на старт можно пренебречь (в пределах разумного, конечно).

Как говорится. Долго запрягают, зато быстро ездят.

>Судя по цепочке, Django начнет проигрывать лишь при числе обращений к jsp, стремящемуся к бесконечности...

Во-первых, в production'е нужно прекомпилировать JSP в Java-байт-код. Во-вторых, компиляция замедляет только _самое_ _первое_ обращение к странице (замедляет, кстати, вполне заметно - бесит во время разработки).

>> А xml-ы из WEB-INF?

> А их один раз надо прочитать при запуске приложения, и все.

А в какой момент парсится значение внутри этого тега?

<value>#{param.someQueryParamName}</value>

> Учти еще, что Java (в отличие от PHP) не запускает на каждый запрос по интерпретатору PHP.

В Django тоже ;)

> <value>#{param.someQueryParamName}</value>
Насколько я понял из исходников JSP страницы после Tomcat - парсится один раз (при компиляции в Servlet API).

При выполнении по готовому "отпечатку" делается запрос с помощью рефлексии (reflection API). При этом работа с reflection API идет через кеш - что существенно ускоряет.

В итоге получается код примерно следующего вида:
Object paramObj = ...;
Method tmpMethod = getMethodForObject(paramObj, "getSomeQueryParamName");
Object value = tmpMethod.invoke();

out.write(value);

---
Но за точность не ручаюсь. Уж больно запутанный код выдается после JSP.

> Эта операция делается единожды при первом обращении.

А я спорил? При первом обращение будут такие жуткие тормоза, что Java не успеет выиграть до следующего изменения страниц дизайнером ;)

>Предлагайте тесты...

hello world -- вполне подойдет, для начала.

> При первом обращение будут такие жуткие тормоза, что Java не успеет выиграть до следующего изменения страниц дизайнером ;)

А вы сравниваете производительность WEB-приложений исключительно по скорости обработки _первого_ запроса? Или по старту?

Скажем, при малом количестве запросов (50 в секунду) только за один час будет обработано 180000 запросов. И тормоза при первом запросе даже на статистику уже не повлияют. А если учесть, что приложение работает не час, а месяцы?

При поддержке кластера скорость запуска и первого запроса становятся не принципиальны. Кстати, DJango нормально в кластере синхронизируется? И пользовательские сессии? И распределенные транзакции?

К тому же можно JSP скопилировать до установки приложения на сервер.
Либо после установки пройтись одним скриптом который "подергает" нужные страницы - варианты есть.

> hello world -- вполне подойдет, для начала.
Не показательно, совсем.
Лучше запрос с обработкой данных (парсингом, валидацией) и выдачей результата. Без обращений к файлам, БД и прочим ресурсам.
При этом чтбы вывод был с поддержкой i18n (зависил от параметра запроса).
Тогда в тест попадут:
1. URL mapping
2. Controllers
3. Data bindings
4. Validation
5. Business code
6. Rendering
7. Support i18n

Будет больше похоже на правду.

>Лучше запрос с обработкой данных (парсингом, валидацией) и выдачей результата. Без обращений к файлам, БД и прочим ресурсам. При этом чтбы вывод был с поддержкой i18n (зависил от параметра запроса).

Ну можно и так, но для начала helloworld будет достаточно.

>1. URL mapping 2. Controllers 3. Data bindings 4. Validation 5. Business code 6. Rendering 7. Support i18n

По пятому пункту не понял, что это, а остальное --- почему бы и нет. Да можно и ORM потестировать, для более объективной картины.

Надо бы еще yaws/erlyweb взять попробовать... Тем более Python, как мне что-то подсказывает, Tomcat/Jetty проиграет.

>> 5. Business code
> По пятому пункту не понял, что это

Какой нибудь процтецкий алгоритм на стороне сервера (чтобы контроллер не был пустышкой). Например расчет погоды, или движения частиц при термоядерной реакции.

>Какой нибудь процтецкий алгоритм на стороне сервера (чтобы контроллер не был пустышкой). Например расчет погоды, или движения частиц при термоядерной реакции.

Улыбнуло... А есть реально такие веб-сервисы, для расчета темоядерной реакции? )))))

> А есть реально такие веб-сервисы, для расчета темоядерной реакции?
Конечно!
Вот URL: http://abdulay.uk.gov
В качестве входных параметров указывай номер кредитки, ФИО и адрес.

>Надо бы еще yaws/erlyweb взять попробовать... Тем более Python, как мне что-то подсказывает, Tomcat/Jetty проиграет.

Я пробовал - yaws, он очень СТАБИЛЬНО держит большую нагрузку (Erlang, однако). Но вот скорость у него не особо большая. HiPE тоже не помогает.

PS: я тот аноним, который пиарит Spring :)

А что было за yaws в качестве помощи разработчику ?

>А что было за yaws в качестве помощи разработчику ?

То есть? Не понял мысли? Если про версию yaws - то 1.70.

Но там сильно много не поменяется - Erlang сам по себе не особо быстрый (так как тоже интерпретируется). Хотя они уже добавляют простую систему типов, так надежда есть.

> То есть? Не понял мысли? Если про версию yaws - то 1.70.

В смысле Erlyweb или все руками?

>Специально для тебя!

Специально для тебя: Мартин Фаулер ниразу не автор Inversion of Control. (Рефакторинга он тоже не изобретал).

>А обозначают они одно и то же. Только один предложили позже другого.

Если ты прочитаешь внимательно - то там написано, что из-за большого количества чайников, которые не врубаются в обобщенные понятия типа IoC, они (а именно Мартин с друзьями) стали называть его DI. Хотя DI всего лишь конкретная техника, которая может быть отнесена к обобщенному понятию IoC.

Если ты прочитаешь книжки по С++/Java/C# то ты почти никогда не найдешь там словосочетания "параметрический полиморфизм". Однако это не отменяет того факта, что всякие шаблоны и генерики это реализация параметрического полиморфизма в этих языках.

>"Учиться никогда не позна". "Век живи, век учись"

http://en.wikipedia.org/wiki/Inversion_of_control

http://en.wikipedia.org/wiki/Dependency_inversion_principle

Начинай.

>Покажи мне хоть одно слово "Питон" в моих постингах.

Там где ты ответил на то что я ответил не тебе - так вот в оригинальном посте упоминались питоновские модули vs singleton. А ты тут непричем:)

/me [прочитав весь тред и протирая глаза руками, спешно смотрит на URL] Это я на LOR зашёл? Цивилизованный спор без посылов в "биореактор", предложений "убить сибя ап стену" и прочего... Удивительно...

Осеннее !обострение на LOR?

>http://www.springframework.org/javaconfig

Смотрю. Как это мне поможет нормально подключить например mx4j или любую другую 3rd party либу которая не аннотирована соответствующим образом и не наследуется от спринговых классов? Никак? Спринг хороший фремфорк, но он глобальный: претендует нак то, чтобы все написать спринг вей (спринговые аннотации, спринговые интерфейсы или абстрактные классы). Это сильно биндит реализацию проекта к конкретному фреймворку и осложняет интеграцию левых компонентов. Я всяких контейнеров пописал дайбоже - чего-то у меня не возникало необходимости внедрять конфигурацию в код или "допараметризовывать код", чтобы контейнер врубился в зависимости или способы инициализации. ТЕм более что достоинством ИМХО является не засовывание подобных аннотаций в код или следование соглашениям спринга, а отсутсвие необходимости так делать.

>Spring в отношении buzzword'ов - это феномен, так как именно Spring единолично _запустил_ buzzword IoC года так три-четыре назад.

Щас. Это из разряда "Microsoft изобрел internet".

>Намек: JSF/JSP у нас тоже JIT-компилируются?

Да.

><value>#{param.someQueryParamName}</value>

Во время компиляции. Приблизительно в

out.write("<value>" + request.getParameter("someQueryParamName") + "</value");

>Да можно и ORM потестировать, для более объективной картины.

ЗАчем тебе ORM? Вообще народ заболел - данные из табличного вида в базе в табличный вид на странице через орм - это мазохизм какой-то.

> А что такое по твоему JEE?

Ну это практически все, начиная от JMS/JSP/J*/Servlets, и заканчивая фреймворками поверх JSF и EJB. Не прав?

> Во время компиляции. Приблизительно в

Это был кусок из сочленепия с Backing beans, out.write тут не причем, полагаю...

>Ну это практически все, начиная от JMS/JSP/J*/Servlets, и заканчивая фреймворками поверх JSF и EJB. Не прав?

Но во всем этом есть смысл. Его не видно если писать аппликуху назначение которой на вебе показывать содержимое базы - ну так не все этим занимаются. Конкретный пример - тебе надо сделать атомарную запись в базу и файла на диск (upload image). Твои действия? А вот тут мы вспомним про JTA, засунем commons-transactions/file в JEE контейнер и совсем прозрачно сделаем транзакционную запись в базу и на диск. А если надо в 2 базы писать? Тут и вспомним про распределенные транзакции. А если это мегасистема? Понятно не все их пишут - но вот у нас например там в одной системе с разделямыми базами под 40 здоровых приложений многие в кластерных вариантах по миру и мультимастер репликациями. Тут уж "спринг или не спринг" не вопрос - удобство фреймфорка - это вообще мелкие проблемы.

> Во время компиляции. Приблизительно в
> out.write("<value>" + request.getParameter("someQueryParamName") + "</value");

Нет. Совсем не так. Сложнее. поскольку переменная param из выражения #{param.someQueryParamName} может быть найдена в:
1. request scope
2. page scope
3. session scope
4. application scope

И из-за этой неоднозначности и не люблю JSP и все, что на нем построенно.
Это реальный bottle-neck и возможность взлома сайта.

> Это был кусок из сочленепия с Backing beans, out.write тут не причем, полагаю...

Да, верно. out.write - для JSP. И у JSP несколько другой подход к парсингу (учитывается области видимости переменных).

>Сложнее. поскольку переменная param из выражения #{param.someQueryParamName} может быть найдена в:

pageContext::findAttribute(String name)

Searches for the named attribute in page, request, session (if valid), and application scope(s) in order and returns the value associated or null.

Но вообще там неоднозначности нет. Как раз пыховой проблемы с инжекшенами в жабских приложениях я не помню ни одной - по причине что там find вызовешь если оно тебе надо (а не стратегия по умолчанию), а в остальных случаях где что брать нотация точная.

> Вообще народ заболел - данные из табличного вида в базе в табличный вид на странице через орм - это мазохизм какой-то.

Для homePage, forum это не нужно.
ORM - позволяет осуществлять контроль над данными не только на уровне выполнения, но и на уровне компиляции - это раз.
Во вторых потеря на mapping с лихвой окупается прозрачностью для валидации и независимостью к представлению (например если контент выдает ся в разном виде или просто участвует в расчетах).

Не нужно забывать что: ORM может происходить в одном приложении, а его результатами пользуются другие приложения.
Банально:
1. для приложений B, C нет прямого доступа к БД и ее данным.
2. Приложения B, C имеют доступ к приложению A.
3. приложение А имеет доступ к БД.
В этом случае между приложениями A,B,C проще и правильнее осуществлять взаимодействие с помощью Object (serializable), чем с помощью листов в которых лежат хэши (или другие листы).

> ...а в остальных случаях где что брать нотация точная.

Т.е. если на JSP написать запись вида ${someObject} - то мы здесь точно знаем из какого скопа будет взят объект (атрибут) с именнем someObject?

И записи вида ${pageScope.someObject}, ${requestScope.defCountry} совсем не нужны?

Я сильно ощущаю, что мы говорим о разных вещах?

>ORM - позволяет осуществлять контроль над данными не только на уровне выполнения, но и на уровне компиляции - это раз.

В каком месте контроль над _данными_ осуществляется на уровне компиляции?

>Во вторых потеря на mapping с лихвой окупается прозрачностью для валидации

В каком месте? Валидируется запрос. Содержимое запроса может нарушать инвариант бина - валидировать в бине нельзя. Простой пример - в бине int в запросе пусто. Все фреймворки валидирующие запрос после присваивания лажаются тут - в бине null превращается в 0, что в общем случае неверно.

>и независимостью к представлению (например если контент выдает ся в разном виде

А в каком месте табличное (или xml) зависимо от представления?

> или просто участвует в расчетах).

А вот это другое дело. Но опять же - depends on типы расчетов.

>В этом случае между приложениями A,B,C проще и правильнее осуществлять взаимодействие с помощью Object (serializable), чем с помощью листов в которых лежат хэши (или другие листы).

Я не говорю что orm не нужен. Я говори о том что o/r mapping так же переюзан как JEE/EJB в начале своего пути где форумы писали на аппликейшен серверах. Во многих случаях объектное представление данных ни разу не удобнее, чем например табличное. А превращать табличные/xml данные в объекты чтобы потом првератить в ьаркап типа html.... зачем? Из любви к искусству?

> В каком месте контроль над _данными_ осуществляется на уровне компиляции?
Данные это не только значение, но и отсутствие и его тип.

> Содержимое запроса может нарушать инвариант бина - валидировать в бине нельзя.
Кто сказал, что "валидировать в бине нельзя"? Есть AOP, аннотации.

> Простой пример - в бине int в запросе пусто. Все фреймворки валидирующие запрос после присваивания лажаются тут - в бине null превращается в 0, что в общем случае неверно.
Для таких случаем используются объекты вместо примитивов.

> А в каком месте табличное (или xml) зависимо от представления?
В общем случае ORM и есть представление данных, не находите?

>Т.е. если на JSP написать запись вида ${someObject} - то мы здесь точно знаем из какого скопа будет взят объект (атрибут) с именнем someObject?

pageScope.

>И записи вида ${pageScope.someObject}, ${requestScope.defCountry} совсем не нужны?

Я и говорю о том что из реквеста, сессии, аппликейшена и пейджи объекты извлекаются по разному. И потому ты не сделаешь инжекшен в сессию подсунув рукамиписанный параметр в запросе - потому что обекты извлекаются по разному из сессии и из реквеста. Где ты тут дырку в безопасности увидел я не знаю>

> Во многих случаях объектное представление данных ни разу не удобнее, чем например табличное.
Это утверждение верно только в случае если данные на выходе будут представлены таблично.

> А превращать табличные/xml данные в объекты чтобы потом првератить в ьаркап типа html.... зачем? Из любви к искусству?
А оперировать байтами и строками вместо бит... зачем? Из любви к искусству?

Перевод в объект - унификация внутреннего (и, в частности, внешнего) представления данных для взаимодействия между компонентами системы и уменьшение зависимости как от источника данных, так и от представления.

Согласен, что ORM не подходит для всех случаев. Но в большинстве он удобен и упрощает разработку и сопровождение.

>>Т.е. если на JSP написать запись вида ${someObject} - то мы здесь точно знаем из какого скопа будет взят объект (атрибут) с именнем someObject?

> pageScope.

Ответ не верен. Можете выполнить пример:
http://www.java2s.com/Code/Java/JSTL/Variablescopepagesessionandapplication.htm

> Я и говорю о том что из реквеста, сессии, аппликейшена и пейджи объекты извлекаются по разному.
Они могут извлекаться по разному, но при ${someObject} извлекаются из разных scope по порядку пока в одном из них не будет найдет запрашиваемый объект (атрибут). В этом и заключается проблема - зная имена и на каком уровне находится значение - есть вероятность "подсовывания" посторонних данных.
Вероятность мала, но на моей практики знаю два случая когда через этот механизм были взломаны сайты.

>Данные это не только значение, но и отсутствие и его тип.

ДАнные в запросе - нетипизированы. ДАнные в базе никак не проверяются компилятором. Их изменение может происходить мимо ORM. Дальше что?

>Кто сказал, что "валидировать в бине нельзя"? Есть AOP, аннотации.

Вперед - технологию валидации отсутсвия значения в запросе для бина содержащего int в студию. (про черезодноместоворкараунды с враппер классами и стрингами я в курсе - это не разу не удобно - это воркараунды, потому что технология неприменима).

Второй пример: поле a может принимать значение 1 или 2 в случае если поле b положительное, и 3 или 4 если отрицательное. Сам факт присваиваяния из запроса a=1, b=-1 нарушает бизнес-инвариант бина, следовательно или мы имеем невалидные данные (аналог базы данных без констрейнтов), а следовательно в некоторые моменты времени бизнес-данные в невалидном состоянии - что вообще ни в какие ворота, либо по смыслу сам бин представляет собой обобъекченный запрос, и посему не является ниразу продуктом o/r маппера (потому что бин находится в состоянии, которое не может быть сохранено в базу - если база данных грамотная то вылетит SQLException: constraint violation - нихрена себе абстрагировались). А если это еще и модификация существующих данных, то мы получаем вообще шизу - в транзакции управляемой маппером появляется бин, состояние которого невалидно (и в базе существовать не может), и он доступен всем в контексте этой транзакции. Ничего себе решение.

>Для таких случаем используются объекты вместо примитивов.

Для таких случаев не надо страдать фигней. В запросе может прийти любой набор нетипизированных данных в текстовом представлении: он приходит из другого приложения в открытом виде, может быть послан любой чужой системой. Протаскивать эти данные в область представления данных из DB не провалидировав перед этим - прямая дыра в системе. Что вы там говрили про безопасность?

>В общем случае ORM и есть представление данных, не находите?

В общем случаем представление данных мильен. Структура хранения - таблица/xml(markup). Структура отображения - html(markup). Я все еще не вижу зачем нужно преобразование данных в объектную форму, если задача одно дерево (xml) првератить во второе дерево(html). Чтобы память было куда расходовать?

>Ответ не верен. Можете выполнить пример:

c:out реализован через findAttribute. ССЗБ.

Начнем с конца:
> Протаскивать эти данные в область представления данных из DB не провалидировав перед этим - прямая дыра в системе. Что вы там говрили про безопасность?
В ходе беседы ни разу не говорил, что валидации перед DB не нужно.

> ДАнные в запросе - нетипизированы.
HTTP-запрос? Да.

> ДАнные в базе никак не проверяются компилятором. Их изменение может происходить мимо ORM.
Это только если вы позволяете это делать. Если же архитектурно не возможно иметь Application Server через который все работают с данными... То и в этом случае не должно вызывать серьезных проблем. В этом случае только одна серьезная проблема - синхронизация.

> Вперед - технологию валидации отсутсвия значения в запросе для бина содержащего int в студию.
Почему примитив? Наследие поддержки? Да и в этом случае нормальные ORM позволяют расширять binding не только после стандартного механизма, но
и до и замещать его. В этом случае, например Spring при работе с command имеющий int поле и данными "ААААА" для него будем иметь в поле
0 и в errors объекте rejectValue на это поле с описанием причины почему значение для этого поля было отклонено.
При наличии записи в errors обработка запроса дальше формы ввода не пройдет и в БД не попадет.

> Протаскивать эти данные в область представления данных из DB не провалидировав перед этим - прямая дыра
Согласен. Я вообще сторонник многоуровнего контроля данных:
1. JavaScript (client side)
2. Business code (server side)
3. Checks, constraints (DB side)

Уровни 1 и 2 удается "общединить" с помощью соответствующих аннатаций на атрибутах объекта. По этим аннотациям при HTML-представлении к полям ввода добавляется соответсвующий JavaScript код.
И при binding & validation на стороне business code происходит контроль данных.

Вот, кстати, и преимущество ORM - наличие единых правил для валидации.

> Я все еще не вижу зачем нужно преобразование данных в объектную форму, если задача одно дерево (xml) првератить во второе дерево(html).

Ваше право.

> Чтобы память было куда расходовать?
Вы данные в любом случае храните в памяти. В табличном, XML или объектном виде. Разница в расходе по памяти (только не XML) мала.
Здесь большей проблемой может выступать overhead за счет создания новых объектов и вызов SET методов.
Но это решается за счет использования пула объектов, в частности.

Замерьте. Вы увидите, что расход памяти не сильно возрастет (если, конечно, не плодить мильены и не отдовать их GC).

> c:out реализован через findAttribute. ССЗБ.
Посмотрите исходники и просьба, обратите внимание на rtexprvalue... Дальше, думаю найдете.