yoctoXML - маленький и быстрый XML парсер

>Бьюсь об заклад - вы скукожитесь очень скоро

Я такую херню каждый день вижу. properties формат log4j был послан далеко и надолго. Хотя бы по такой мелкой причине что xml комплитится IDE по схеме. И если уж мы говорим о мусоре то протрите глаза сколько одинаковых строк в этом тексте.

>Код для пропертей на жабе - несколько строк. ХМЛьный хандлер - во много-много раз больше, да ещё и намного
хуже для глаз админов. Зачем этот геморой??

У меня код на жабе что дял пропертей что для XML - одна строчка. При чем в одной и той же либе конфигурирования. Если у тебя несколько строк - исправь руки.

>Вы дадите бизнес-юзерам многостраничные ХМЛ, где чтобы понять контекст - надо мотать страницы?

Я делаю разные конфиги, как DSL так и "пропертиес" которе понимают все включая мультимапы, так и XML. У меня тараканов в голове нету. Но я ен буду писать DSL для непринципиального конфига. И таки да бизнес-юзера вполне осиливают XML. Если выши не осиливают - мои соболезнования.

>Тогда это нормально модифицируется человеком, в отличие от роботов.

Так вот даю справку - модифицироваться должно не только человеком но и роботом aka программой. Именно потому половина "удобных" конфигов или человек-писать/программа/читать конфиги или имеют страшную фразу "generated file do not modify". А все почему. Потому что первые не в состоянии нормально сохранить то что модифицирует программа, или потом не в состоянии прочитать - то что изменил человек.

Айм сори но я таким идиотизмом не страдаю, вроде "эти три цифры конфиг а эти надо хранить в mysql потому что юзер их из вебинтерфейса исправил". У меня конфигурации обычно работают в обе стороны, и пишутся и читаются и программой и человеком.

> Второе - очевиднее.

кому как

>Ты ХМЛ хедлеры будешь дольше прописывать и всё необходимое

Бред полнейший.

Configuration config = new DefaultConfiguraiton(
new XmlConfigProvider("/path/to.xml"),
new PropertiesConfigProvider("path/to.properties"),
new AppletConfigProvider(this)
);

гетерогенный конфиг, дальше все через единый API. _одинаковый_.

Если конфиг совсем специфичный

X x = Jaxb.unmarshal("/path/to.xml"); - десерериализует нативный объект.

Если без биндинга:

int value = XmlUtils.select(XmlUtils.parse("/path/to.xml"), "/the/x-path", INTEGER);

Ну и где хэндлеры? Все тараканы - в глове.

>ХМЛ - виндовоз-вей ещё и потому - что все случаи жизни хотят впихнуть в 1 функциональность и получают - "плохо" всегда и во всём.

Ты бы меньше на флаги кидлался и ярлыки клеил вроде виндовз-вей, которые просто слова, тогда бы тараканов меньше в голове было и не пришлось бы "писать хэндлеры".

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

А для меня - эффективность разработки в области функционал/время(деньги). Этим мы с тобой отличаемся.

>Впихивание же сложных вещей в ХМЛ - это игнорирование юзеров программером, который думает только о себе

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

> Но я ен буду писать DSL для непринципиального конфига

Где я говорил - что я использую DSL для простых конфигов?

>Так вот даю справку - модифицироваться должно не только человеком но и роботом aka программой.

в этом и проблема.
я чётко разделяю задачи и делаю их разными инструментами, не пытаясь использовать комбайны.
1) В конфиге - я отталкиваюсь от юзера у показываю в наиболее удобном формате - только самые нужные вещи в наипростейшем возможном представлении;
2) В RPC - я использую самых эффективный (для перформанса) способ: кастом протокол. Поэтому не использую вебсервисез а пользуюсь REST и набор сервлетов или CGI (да хоть PHP) - для их обработки. Полное изолирование. (аналог комманд-лайна в вебе). И поверьте - делаю это быстрее чем многие читают мануалы по вебсервисам.
3) сохраняемые конфиги - там сохраняйте хоть в бинарях. Это - способ программы - как обеспечивать персистенси состояния между ранами.

И не пытаюсь натянуть одну технологию на всё, делающую всё плохо (а с ХМЛ я работал и в конце 90-х, когда его никто ещё не знал и делал сложные вещи - кастом грамматики с громадными DTD и стайл-шитами по типу современного XML/XSL, так что ХМЛ я знаю, поверьте)

> У меня код на жабе что дял пропертей что для XML - одна строчка. При чем в одной и той же либе конфигурирования. Если у тебя несколько строк - исправь руки.

у меня тоже будет одна - если таскать свой парсер. А зачем?
Доступаешься как блах.гет("соме.проперти");? (как XPath?)

а зачем тебе изначально ХМЛ? Почему юзеров не жалеешь?

>У меня конфигурации обычно работают в обе стороны, и пишутся и читаются и программой и человеком.

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

Я не вижу используемых классов в стандартных библиотеках, таким образом ты имеешь свой АПИ.
Теперь подсчитай суммарное количество строк, о которых я говорил.


Следующий код я использую с года 96-го (ява 1), и он работает, обеспечивая ту же функциональность:
---8<---
Properties props = new Properties();
props.load(new КакойНибудьСтрим());
---8<---

Вопрос: "ребята, зачем вы это всё писали - если юзерам удобнее мапы, и которые 2мя строками можно было считать всегда - если речь о жабе"? И все ваши
int value = XmlUtils.select(XmlUtils.parse("/path/to.xml"), "/the/x-path", INTEGER);

это жуткие костыли (посмотрите и увидьте наконец иерархии и в моих попертях, в томже log4j.properties)

> Ты бы меньше на флаги кидлался и ярлыки клеил вроде виндовз-вей
А ты бы поменьше лез с советами - что мне делать и я не буду тебя посылать.

>1) В конфиге - я отталкиваюсь от юзера у показываю в наиболее удобном формате - только самые нужные вещи в наипростейшем возможном представлении;

И что же это за наимпростейшее представление? Критерии простоты в студию.

>. Поэтому не использую вебсервисез а пользуюсь REST и набор сервлетов или CGI (да хоть PHP) - для их обработки

Можно узнать твои данные данные по сравнению перфоманса "REST" vs "SOAP".

>И поверьте - делаю это быстрее чем многие читают мануалы по вебсервисам.

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

>3) сохраняемые конфиги - там сохраняйте хоть в бинарях.

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

>а зачем тебе изначально ХМЛ? Почему юзеров не жалеешь?

Жалостью к юзерам я переполнен в области денег и времени затрачиваемого на разработку. Мои юзера не против XMLину шлепать даже в некоторых частях веб интерфейса абы не ждать сложной красивой формочки. Потому что время для них - это деньги. При чем то время которое происходит до выходы программы. А там где это некритично я изобретаю мегаконфиги вроде

#мультимапа
key = val1 -> 1,2,3;; val2 -> 3,4,5

или упражняюсь с антлром.

Но это там где я могу себе это позволить. Пока юзера мне не заказывалил конфиг как критичное требование. Как критичное требование у них обычно бизнесфункционал.

> Я и говорил - что в этом твоя проблема.

Нихрена се проблема. У меня программа и пользователь читает и правит один и тот же файл - он однозначен и как это по русски "comprehensive" и это проблема? ДА это немерянное преймущество - что одлмин в курсе что если написано port то это единственное место где оно есть.


>(а для каждой задачи - есть свои инструмент, наиболее простой и/или эффективный)

Недоказано что сумма наиболее простых инструментов оптимальна.

>Я не вижу используемых классов в стандартных библиотеках, таким образом ты имеешь свой АПИ.

Ох какой ужос мне пришлось написать простую очевидную библиотеку по типу тех что тут рекламируются, и заюзать ее в десятках проектов.

>Теперь подсчитай суммарное количество строк, о которых я говорил.

Ты что не видел там однострочники?

>Properties props = new Properties();
props.load(new КакойНибудьСтрим());

Рад за тебя. У тебя он сделает сабститьюшен? Сделает сабститьюшен к переменным окружения? К систем.пропертиес? НАсколько сложные значения он способен парсить?

data.dir = .data
key = ${user.home}/${data.dir}
map = xdir -> ${key}/x; adir -> ${key}/a; jvm -> ${jvm.version}

У меня
config.getMap("map")

Вернет Map с

xdir -> /home/r/.data/x
adir -> /home/r/.data/a
jvm -> 1.6

Я уже ярко себе представляю что за код у тебя будет после этих двух строчек с 96 года чтобы достигнуть такого же эффекта.

>это жуткие костыли (посмотрите и увидьте наконец иерархии и в моих попертях, в томже log4j.properties)

Такое представление иерархий - это жуткий ужас. Опять позиционный конфиг который можно только линейно интерпретировать. Скобочки им мешают а писать в каждой строчке одно и тоже с различным суффиксом - это нормально.

> А для меня - эффективность разработки в области функционал/время(деньги). Этим мы с тобой отличаемся.

поэтому качество т.н. энтерпрайзнутого софта - ниже табуретки, средняя продолжительность жизни - несколько лет. А мой код работает в продакшенах в нескольких всем известных компаниях (и работает со всеми версиями, если на жабе - то и под свободными VM, если на C - то ANSI C) и люди при встрече говорят: "представляешь - твой код до сих пор работает - уже 10 лет прошло, и совсем без супервижена".
Это если немного подумать ещё о красоте, простоте, юзабилити, эффективности и потратить иногда чуть больше времени (а чаще - даже меньше) - чем с твоим подходом.
Как-то раз даже казус вышел - никто не знал про прогу которая работала годами, сервируя бизнес-юзеров со всей америки, потом за много лет накопилось на диске несколько гигабайт мусора - после жёстких рестартов (не поставили просто изначально путь на tmp почему-то). Вспомнили. Вот так надо писать (не будучи нескромным, просто для иллюстрации - к чему надо стремиться в идеале). Юниксовые проги работают десятилетиями и интерфейсы там не меняют каждые несколько лет (за то и любим их).
Только ХМЛщики что-то там изобретают, публикуют стандарты и решают задачи которые по-сути решали и 20 лет назад (но только гораздо более кривым и изощрённым способом). Ну, время нас рассудит.


> Программер думает только о себе когда он просирает деньги заказчика на "удобный конфиг", который может быть нихрена не удобный и не заказываемым, и вообще за время жизни программы менятся один раз - при установке.

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

конфиг как я сказал - это несколько часов (на Ц, на жаве - вообще 2 строки), зато потом - ни разу не иметь с ним проблем, а только добавлять и добавлять значения и параметры за секунды (и удобные комментарии в строковом формате, а не кривые <!-- --> + получать косоглазие от вложенности к концу проекта, не говоря о контексте).

Для меня однозначен ответ на вопрос - кто из нас просирает деньги заказчика.

ладно, если не понимаешь - поймёшь это когда-то, после ещё 10 лет опыта.

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

Не обоснованное утверждение. Разве что ты качество меряешь наличием или отсутствием XML.

>Это если немного подумать ещё о красоте, простоте, юзабилити, эффективности и потратить иногда чуть больше времени (а чаще - даже меньше) - чем с твоим подходом.

Еще одно необоснованное утверждение.

Ты просто кладезь подобных фраз - найти кого-то, обозвать своим необоснованным мнением (например "виндовс-вей"), потом на основе своего же необснованного мнения сделать свои же далеко идущие выводы.

>Юниксовые проги работают десятилетиями и интерфейсы там не меняют каждые несколько лет (за то и любим их).

Ты видать незнаком с такой "юниксовой" прогой как ядро linux.

>Ну, время нас рассудит.

Вот еще одно заблуждение. Ты думаешь что будет точка во времени которая что-то там покажет и на этом все кончится. Нет не удет такой точки. Все будет двигаться дальше. Все время. Все меняется, идеальных технологий не бывает. А прогресс одно направление имеет - дешевизна производства.

>если твой конфиг меняется 1 раз - зачем тебе вообще конфиг???

Потому что он ставится на 5000 тачек. Есть у нас такая ботва. И на этих тачках иногда все не совсем одинаковое. Понимаешь ли.

>потом, я решаю задачи гораздо быстрее чем ты думаешь

Давай пригласим сюда PHP шников и заведемся с ними кто быстрее сайт склепает.

>конфиг как я сказал - это несколько часов (на Ц, на жаве - вообще 2 строки), зато потом - ни разу не иметь с ним проблем

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

> Для меня однозначен ответ на вопрос - кто из нас просирает деньги заказчика.

Для меня тоже. Я сделал работу один раз и больше к ней не возвращаюсь. Ты в каждом проекте начинаешь стого что изобретаешь велосип^H конфиг, протокол и т.д.

Пока ты свою программу напишешь у моей уже жизненный цикл кончится с таким подходом.

>ладно, если не понимаешь - поймёшь это когда-то, после ещё 10 лет опыта.

Да - я тоже в детсве начинал с того что изобретал свой логгинг (конечно же круче чем предидущий) свой конфиг (конечто же фичастее чем предидущий). Я из этого возраста вышел когда понял что платят мне не за это. Ты похоже нет.

PS: при чем я велосипедист такой что еще поискать. К тому же крайний перфекционист. Но по крайней мере стараюсь отличать существенное для заказчика от желаемого для меня.

>Такое представление иерархий - это жуткий ужас. Опять позиционный конфиг который можно только линейно интерпретировать. Скобочки им мешают а писать в каждой строчке одно и тоже с различным суффиксом - это нормально.

ужас - только в твоём представлении иерархий (а представление может быть любым, хоть бинарными структурами).
Нелинейность - в интерпретаторе. Иерархии же в моём линейном представлении - это наиболее читаемый формат (спроси у админов).
Скрипт фаерволов на iptables (набор правил) такой же повторяющийся - как и любой другой скрипт, в отличие от вложенного кода. Почему бы не захерачить сразу всё в одно большое дерево (во что эти рулы будут всё равно преобразованы)? Деление на кусочки, правила (по "Divide and conquer" принципу) позволяет сделать модификацию каждого кусочка независимым от других. В этом - сила рул-энджинов (а так да, всё можно было-бы написать в виде одной лисповой функции).
А всё потому - что не-роботу проще читать отдельными короткими правилами.

>Мне например наплевать откуда беруться параметры - из настройки вебконтекста, из аплетных параметров или из файла конфигурации.

Мне тоже. у меня обычно они приходят также из позиксовых аргументов и из базы.

А теперь вопрос. Ты конечно (когда в базе) - ХМЛьные конфиги хранишь в каких-нибудь клобах, ненормализовано даже до 1 формы? Зачем реляционкой тогда пользуетесь? (в некоторых местах требование - минимум 3 форма).
Но это - оффтопик.
Так как ты будешь передавать те-же параметры из позиксовых параметров? (повторять всё то-же самое, но уже вне ХМЛя?) у меня же ничего не изменится - я даже ключи (для long-представления) использую ингода одни и те-же для простоты.
Я же знаю - что по-сути костылей у тебя будет гораздо больше!

> Пока ты свою программу напишешь у моей уже жизненный цикл кончится с таким подходом.

во-во, только жизненый цикл у неё кончится быстро имхо по другой причине, по той-же что и почему 75% проектов - накрываются сегодня медным тазом.

Откуда знаю? Опыт, опыт, батенька, в больших конторах, обрабатывающих либо миллионы уникальных юзеров в день, либо миллионы транзакций в день, либо 200к транзакций в секунду, либо объёмы данных жёлтых страниц масштаба страны (можешь представить обьёмы), либо мейнфреймы ретейлеров ранга валмарта. И везде в вышеупомянутом неполном списке - очень и очень не любят ХМЛ. Сказать почему? Повсему.

Поэтому совет на будущее (уж не пинайте за совет). Когда будете разговаривать (и особенно продавать свои услуги) с людьми обрабатывающими большую дату (со спецами, не менагерами, всё равно спецы будут решать) - не говорите что вы - сторонник ХМЛ. Не поймут. И выберут юниксоидов и компании, знающие толк в обработке данных эффективно.
А в случае конфигов - представляющие данные - в наиболее удобной форме (в том числе и в виде позиксных рагументов, для автоматизации из скриптов)

> PS: при чем я велосипедист такой что еще поискать. К тому же крайний перфекционист. Но по крайней мере стараюсь отличать существенное для заказчика от желаемого для меня.

вот это внушает надежду. Что скоро тоже найдёшь Дзэн.
А заказчики они тоже умнеют и выходят из каменного века в бронзовый.

> А прогресс одно направление имеет - дешевизна производства.


дешевизна как-раз на моей стороне.
Я свои 2 строки гораздо быстрее пишу чем ты парсеры копируешь и они работают и под юбунтой и под ибм-овскими старыми ВМ, и везде где есть жаба.
А об абтоматическом сохранении - я даже не заикаюсь. Я уже вижу что ты и комментарии теряешь - если один конфиг используешь и для ручной правки, и для автосохранения (а у меня конфиги - самодокументируемы, отформатированы красово, с отступами, с дефолтовскими значениями итд - всё что юзеру надо - и доки не надо читать).
Потом - ты в таком случае теряешь исходные дефолтные значения и не можешь дать кнопку "резет то дефолт". И прочее.
Опыт, его не пропьёшь...

и последнее.

Пожалуйста, перестаньте всё выворачивать на изнанку - называя велосипедостроительством ини/проперти, существовавшие и в конце 80-х.
Всё наоборот: это ХМЛ, появившийся на волне дот-гона - притащил много подобного мусора (так как хватали всех - кто не боялся программировать, и всё что валяется). Через несколько лет - все стали кручать уже - что как-бы уже и стандарт.
Хотя в больших конторах стандартом как и 20 лет назад являются мейнфреймы и рекорды фиксированной длины и делимитед. И ХМЛ - ещё даже не велосипед.
Так что не выдавайте желаемое за действительное.
В вебе - да, там много пионерии. А на действительно ответственных участках - пока ещё достаточно квалифицированные люди (почти уже пенсионеры) - чтобы не допустить безответственные игры с дорогим железом и большим бизнесом.

>А всё потому - что не-роботу проще читать отдельными короткими правилами.

Где там короткое правило?

>во-во, только жизненый цикл у неё кончится быстро имхо по другой причине, по той-же что и почему 75% проектов - накрываются сегодня медным тазом.

Я работаю не на галере - у меня 100% проектов в продакшене. ЧЯДНТ?

>И везде в вышеупомянутом неполном списке - очень и очень не любят ХМЛ. Сказать почему?

Ага - в этом списке еще и программы на коболе встречаются. Дальше что?

И еще не надо пугать страшными цифрами - они ничего не обозначают. В том смысле что принципы написания разных програм - разные. 200k транзакций в секунду - это требование. Ты и хомепагу будешь писать так как будто ее надо обработать 200k транзакций в секунду? Ну так любой phpшник тебя сделает. И будет абсолютно прав. Потому что не надо искать проблем где их нет, и выдумывать себе требования не заложенные в проекте.

>Когда будете разговаривать (и особенно продавать свои услуги) с людьми обрабатывающими большую дату (со спецами, не менагерами, всё равно спецы будут решать) - не говорите что вы - сторонник ХМЛ. Не поймут.

Я человек обрабатывающий большую дату. Media Assets. Работаю в корпе который на этом специализируется - телевизор смотрел? Рекламу видел? Международную? Журналы типа "Максим" видел в ларьках? The Times читал? Вот есть большая вероятность что евро-аме-аввстра версии этих журналов или реклама была отколбашена именно через наши системы. В которой они анализировались, транскодировались, оцифровывались или растериировались и т.д. Не поверишь - XMLа по самое нехочу.

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

Посмотри что такое JDF.

Дальше покури что такое группа IPTC и ее стандарты для индустрии: IPTC, NewsML, SportsML, EventsML, и т.д. - обана международные индустриальные стандарты - все XML.

Покури что такое MPEG-7 и удивись что там тоже XML.

Так что не надо мне рассказывать сказок про то как обрабатываются большие данные - я этой фигней себе на жизнь зарабатываю. И первое требования у нас "а можно всем понятный XML который можно подсунуть чтобы побыстрому все было даже когда интерфейсов еще нет".

>Где там короткое правило?

каждая строка в проперти-версии log4j - независимая от других строк и её можно расценивать как правило, одна логическая клауза. Так-же как и в строке фаэрвола на iptables, приведённого для примера. Так-же как и в скрипте.

ХМЛ требует контекс и есть суть - большая иерархия (я уж не говорю про то что это не масштабируемый подход, например с большими и очень большими файлами), а строки я могу кормить порциями, по мере надобности, инкрементально. Итд.

> Я работаю не на галере - у меня 100% проектов в продакшене. ЧЯДНТ?

я говорил про статистику по индустрии. Если у тебя 100% - то ты велосипедист в хорошем смысле слова, тогда - уважуха.


...

да я понимаю...
(я работал когда-то с паблишингом, в конторе со статьями в SGML, кваркэкспрессами итд и знаю что там сейчас тоже наверняка один ХМЛ, заменил SGML).

> И первое требования у нас "а можно всем понятный XML который можно подсунуть чтобы побыстрому все было даже когда интерфейсов еще нет".

а у нас - делимитед или фиксед-ленгтх, где всё ещё понятнее, можно делать и комментарии, и шапки, и секции, а на самом деле это занимает гораздо меньше времени чем ХМЛ-парсинг - если правильно готовить.

ладно, успехов.

>каждая строка в проперти-версии log4j - независимая от других строк и её можно расценивать как правило, одна логическая клауза.

Фига с два. Она тесно связана с предидущими и последующими определениями.

>ХМЛ требует контекст

Когда он там есть. Так вот в log4j он есть. Или ты уже покажещшь как две строки:

log4j.appender.stdout=org.apache.log4j.FileAppender
log4j.appender.stdout.File=logs/file.log

Не связаны и имеют смысл одна без другой?

В пропертевом log4j строки _связаны_. Это и призван обозначить общий префикс. Именно потому эти имеют длинный общий префикс. А ты думал для красоты?

>а строки я могу кормить порциями, по мере надобности, инкрементально. Итд.

ты занимаешься кормлением строк?

>я говорил про статистику по индустрии.

Нет - ты натягивал статистику индустрии на XML не имея малейших на то оснований. Так вот - эта статистика проистекает не из формата конфигов, а из-за неправильного проджект менеджмента, несоответствия работы-ожиданием, несоответствия заказа-деньгам, старт проекта без представления что оно должно делать, и от ненужности заказываемых проектов по сути.

> Фига с два. Она тесно связана с предидущими и последующими определениями.

Как и в случае с фаерволом - понятно что всё связано. Но правила - всё же логически независимы для читателя/писателя, который копипастит их построчно/ может перенести, поменять порядок, дать комментарии, шапки итд.

>log4j.appender.stdout=org.apache.log4j.FileAppender
>log4j.appender.stdout.File=logs/file.log

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

да, я могу легко отгрепать, сабститьютуть одну строку (поменять имя файла или любой другой параметер) юниксовыми тулами. В случае с ХМЛем - это так просто не сделать (проперти - строковый формат, ХМЛ - скобочный)

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


надо бежать работать.

В заключение:
П.С. Если в паблишинге без ХМЛ нельзя - то по-крайней мере для конфигов - старайтесь не использовать ХМЛ. Эти задачи ведь никак не связаны. Делайте всё проще и читаемее (а если что-то можно вписать в конфиг - то то-же самое нужно иметь возможность передать через посикс-аргументы по-хорошему. И вот тут ХМЛ не впишется никак, а проперти впишутся - как родные).

>Как и в случае с фаерволом - понятно что всё связано.

Не надо слиывать на файрвол.

>Но правила - всё же логически независимы для читателя/писателя, который копипастит их построчно/ может перенести, поменять порядок, дать комментарии, шапки итд.

Сурьезно? Нука поменяй строчки местами там где опредеяется аппендер и там где он параметризуется. Хочу увидеть в цвете и со звуком.


>безусловно, это - 2 разных клаузы: одна - определяет класс аппендера, другая - определяет имя файла для этого аппендера.

Одна без другой не имеет смысла, и более того последовательность жеско закреплена и тем не менее ты продолжаешь утверждать что они не связаны?

>безусловно. например, добавить в конце новый аппендер легко через пайпы

Ага. После определения rootLogger. Или категорий которые должны туда кидать.

Ох уж эти сказочники-теоретики.

>Эти задачи ведь никак не связаны.

Эти задачи у свяжуться как только осознаешь что нет никаких конфигов и майэскуэлей - есть код (статичная часть программы) и есть данные (изменяемая часть программы). Одно не меняется без вмешательства разработчика, второе меняется. А дальше надо проявить фантазию и этим воспользоваться. А все предрассудки и "само собой разумеется" выкинуть из головы.

не хотел отвечать, но здесь не могу этого не сделать.

Ты бы уж не позорился в:

>Сурьезно? Нука поменяй строчки местами там где опредеяется аппендер и там где он параметризуется. Хочу увидеть в цвете и со звуком.
>Ох уж эти сказочники-теоретики.


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

И я, например, часто динамически изменяю, добавляю новые проперти и из кода, и из аргументов (которые оверридят те пропертя, которые засосаны из дефолтового конфига), затем оверридю преференсами юзера (т.е. я поддерживаю и персистенс персональных настроек) а также даже эвристику (на случай падений или недостатков):

------8<------
Properties logProps = new Properties();
InputStream in = getInputStreamFromResource("log4j.properties");
logProps = new Properties();
logProps.load(in);
in.close();

//override by user preferences
//override by args passed
//heuristics and other hardcoded overwites

PropertyConfigurator.configure(logProps);
------8<------

Так что прежде чем бросаться "сказочниками-теоретиками" - потрудитесь хотя бы изучить предмет.

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

Подумай на досуге - как сделать то-же самое (с передачей и оверридом, например флага
--trace trace5
который покажет только например определённые запросы в рантайме).
Только с пропертями можно делать подобное.

бай-бай

П.С. я понял, ты даже мыслишь в терминах пасинга одного хмльного конфига: ясно же что поменяв порядок в ХМЛ конфиге логгера - всё накроется, так как важен порядок, таги и прочие ненужные артефакты, приходящие от недостатков имплементации.
Хотя по сути - это набор независимых правил, которые могут приходить из разных источников (юзер преференсы могут переопределить что-то, посикс-аргументы - важнее дефолтов итд).
Ты из-за ограничний технологии, которые тебе навязал ХМЛ - даже не думаешь - что всё это возможно.
О чём и речь выше во всём треде.

говорю же - ещё десяток лет опыта...
пока

>Ты бы уж не позорился в:

Серьезно?

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
#log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n
log4j.rootLogger=debug, stdout

=============
log4j:ERROR Could not find value for key log4j.appender.stdout.layout
log4j:ERROR No layout set for the appender named [stdout].


#log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n
log4j.rootLogger=debug, stdout

=============
log4j:ERROR Could not find value for key log4j.appender.stdout
log4j:ERROR Could not instantiate appender named "stdout".
log4j:WARN No appenders could be found for logger (.........).
log4j:WARN Please initialize the log4j system properly.



Как ты там говорил? Независимые строки?

>Хотя по сути - это набор независимых правил,

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

ты возможно используешь старую версию или слишком новую в которой что-то поломали.
У меня нет времени тестировать. Посмотри в проекте:
http://sourceforge.net/projects/ais/
там простейший вариант работает (без юзер преференсов, конечно, без эвристик итд)
-- даст работающий log4j.jar и метод считывания по крайней мере (в классе Config несколько строк)

Я пользуюсь этим подходом почти 10 лет когда log4j появился (включая очень навороченные конфиги со многими аппендерами), а до этого использовал свои логгеры с таким же подходом).

там только 2 проперти необходимых-в каждом аппендере, остальные админ может покомментить. (я обычно их две дополнительно и кладу в эвристику в коде - для надёжности - если покомментил как ты говоришь ;)

извини нет времени разбираться с твоими пропертями (с ХМЛем поверь - намного больше _дополнительных_ проблем, я работал много и с хмльным конфигом log4j).

Я обычно копирую готовый конфиг например с AIS проекта, а затем добавляю нужные аппендеры (чаще - только корневой лог уровень меняю и админов учу). Если надо больше - есть доки или экстендю.

>ты возможно используешь старую версию или слишком новую в которой что-то поломали.

Оно по другому работать не может. По той простой причине что настройки _зависимы_, и нельзя настраивать лейаут несуществующего аппендера.

>ХМЛем поверь - намного больше _дополнительных_ проблем,

На самом деле это очень смешно называть проблемой.

Когда-то один раз написал себе класс для конфигов, по умолчанию формат:

[Appearance/Fonts]
Default=Helvetica,10
Editor=Terminus,12

[Appearance/Colors]
Back=white
....


т.е. старый добрый .ini, разве что добавил для себя "плюшки" в реализацию в виде сохранения массивов, изображений и т.д., как по мне и log4j и xml ему проигрывают, как по читабельности, так и по компактности

Всё фигня, кроме пчёл. Да и сами пчёлы тоже фигня, если вдуматься. Да, о чём это я...

Ну так вот, предлагаю мировую. Хотя я и не согласен категорически с подходом r (всё фигня, кроме сроков; есть только код и данные; главное, чтобы мне было удобно), но это тоже подход, и за него таки платят деньги. Остаётся только надеяться, что мой кумир Витсе Венема не сменит конфиг постфикса на xml :) Равно как и прочие разработчики прекрасных сетевых серверов (они-то знают, что админам нужно :) ). А пока такие, как r, не лезут в исконно админскую область со своими монструозными конфигами и дремучими с точки зрения предметной области определениями - пусть делают, что хотят и получают свой маленький гешефт. Обидно только за hal и fontconfig. А сегодня к списку НЕНАВИСТИ прибавился ещё и Tomcat.

Трудитесь и зарабатывайте, братья и сестры, и да не помешайте ближнему своему