(no subject)

[exceed_er]

Башорг удивил философским замечанем прямо в точку:
«Cамый кайф в программировании - это когда начинает получается то, что хочешь, а не то, что надо...»

Времени писать вообще нет. Да и посты такие в голове появляются... Например, что вот ну почему создателям Servlet API ни разу не пришло в голову разрешить вопрос с раздачей дискового места централизованным способом. Ну не правильно же, что все пишут всякую фигню в medved2ee/WEB-INF/bobrujsk. А jackrabbit нужен отнюдь не кажому.

Comments

[soul-baby.livejournal.com]

ого мысли)))))))))

[exceeder.livejournal.com]

ну на "ого" не тянут, не. На "мисли" максимум :)

[jdevelop.livejournal.com]

фактически я полагаю, что товарищи вполне сознательно это не думали, ибо к спецификации сервлетов стораджные вопросы с моей точки зрения отношения не имеют

ведь есть такая пипецка как getRealPath (но ты про неё знаешь), которая типа этим всем и рулит? или я не понял мысли

[exceeder.livejournal.com]

Ну да, getRealPath() все и пользуются, в том числе и я :) В итоге обычно заводят свои данные в WEB-INF где-нибудь... Неудобств у этого места выше крыши. Начиная с того, что многие сервлет контейнеры вообще не раскрывают .war файлы на диск и при этом вполне себе работают.
В итоге приходится заставлять людей задавать конфигурацию. А хорошо-бы чтобы WEB-INF соответствовал состоянию в WAR 1:1. Где хранить конфигурацию? Предложенный способ в виде параметров в web.xml ужасен, потому что update с помощью war его потенциально затрет. Отдельный файл типа webapp.properties уже чуть лучше, но есть проблема где его держать все-таки. Если идти за философией 1:1.

[jdevelop.livejournal.com]

посмотри SRV.3.7.1 Temporary working Directories в спецификации, как вариант
может пригодиться, правда контейнер не гарантирует что там чего-то будет после
перезапуска. Это единственное что я нарыл в спецификации 2.4, может в 2.5
что-то более интересное есть.

[jdevelop.livejournal.com]

но вот как альтернатива всяким каталогам для аплоада файлов оно таки рулит

[katren.livejournal.com]

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

так же и с web-inf - куда можно писать (доступные потоки для записи) в общем случае неизвестно - поэтому нужны конфигурации.
Если вас смущает, то что нельзя сделать универсальный war и всем его раздавать - так это потому что war это всего лишь архив, настройки внутри - сделал настройки запаковал в war - deploy.
Или я не понимаю?

[exceeder.livejournal.com]

Т.е. ваше предложение (кстати, со мной можно на ты) это создавать индивидуальные war файлы с конфигурацией для каждого сервера.

Если я продаю своё веб приложение, скажем, тысяче клиентов в месяц, я должен им, к примеру, чтобы и выглядить профессионально и хоть как-то не сойти с ума, предоставить https форму на моем сайте, в которую они вобьют свои пароли к базе данных и другие параметры, а я это все сложу в WAR и предложу для скачивания на их личном аккаунте? В общем, наверное, так можно сделать, но нигде такого не видел. Особенно если я предлагаю бесплатное решение с открытым кодом, есть неудобства с таким подходом, по крайней мере это дороже.

Чего хотелось бы в идеале, это getServletContext.getApplicationContextProfilePath()
а в Томкате, к примеру, было бы /profiles/.myWebApp
как общее соглашение. При этом место где хранятся profiles можно было бы регулировать.

Конечно, сейчас можно взять из перменных окружения System.getProperties("user.home") и воспользоваться ей. Но это тоже как-то нестадартный подход. По крайней мере не для веб приложений. На линухе это скорее всего попадет в root, на виндоус - в Documents and Settings\All Users, если на Томкате.

[katren.livejournal.com]

"user.home" это как раз стандартный подход

тысяче клиентов в месяц надо отдавать war который работает out-of-the-box, если они хотят изменить стандартные настройки это можно сделать в процессе инсталяции (см как себя инсталирует JForum) или после запуска (см JIRA)
все настройки можно и руками потом поменять

не надо пытаться сделать так что бы war был одновременно один и разный - это как раз и есть тот корень вокруг которого у тебя все проблемы.

Ну и в конце концов, когда у тебя будет 1000 клиентов с деньгами в месяц - ты не только war будешь на ура перепаковывать, а даже специалиста выслать. :-)