Java вывод stackTrace в логах

[Хлорка]

Хлорка старается избегать подключения каких-либо дополнительных библиотек к своим программам, особенно Apache. В силу того, что они имеют свойство включать внутрь слишком много лишнего и весить в размере соответсвенно. Встроенный java.util.logging всем устраивает, включая простоту использования. Достаточно реализовать собственный Formatter чтобы выводить трассу в филе или на экран куда там надобно. Способов вывода трассы полно в Интернете, наиболее простой StringWriter. Ради этого совсем необязательно качать Апач.

Ради примера есть такой говно-пакет в Apache называется Axis2, о котором можно вспомнить только матерным словом. Мало того что там куча всего лишнего, так и производительность всех этих 20-ти мегабайтовых библиотек при запуске простенького встроенного примера заставляет отказаться от него. А ведь Apache SOAP больше несуществует, теперь он входит внутрь Axis-а, который еще и не совместим с Microsoft SOAP. Кароч как я посмотрел время выполнения примера передачи строки, я решил для моих задач будет достаточно XML RPC. А вам ASevenfold, я рекомендую использовать мод Rampart для апача еще так мегабайт на 15 поверх Axis2 чтобы ваш комп "сдох" от бесконечных рекурсий и пустых циклов в конце которых, выйдет долгожданное слово "Hello I'm Batman!". Однозначно нельзя сказать, что тут можете обойтись одной строчкой. Ненадо забывать что за одной строчкой текста может скрываться мегабайт 20 кода, так что применять такие вещи надо по необходимости. Apache Common Logging полезен для создания промежуточных пакетов, которые предполагается использовать в разных приложениях, для конечного - ненадо.

Aquanox, давай дружить?

[ANZO]

Да хоть на овер9к библиотек нагрузите в cp - работу приложения это не замедлит.

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

[Aquanox]

<![OFFTOP[

jarjar решит ваши проблемы с упаковкой библиотек раз и навсегда =)

Знакомый показывал модификацию этого упаковщика, которая включает в конечный jar только используемые классы (анализом байткода выбирает классы + include/exclude package) - это был его шедевр, но его исходники не сохранились, а написать с нуля такую вещь у меня не хватило терпения (так гдето и валяется заготовка)

]]>

[Хлорка]

<![OFFTOP[

jarjar решит ваши проблемы с упаковкой библиотек раз и навсегда =)

Знакомый показывал модификацию этого упаковщика, которая включает в конечный jar только используемые классы (анализом байткода выбирает классы + include/exclude package) - это был его шедевр, но его исходники не сохранились, а написать с нуля такую вещь у меня не хватило терпения (так гдето и валяется заготовка)

]]>

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

[n3k0nation]

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

[Хлорка]

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

Вы оперируете каким-то непонятными мне терминами. С вас пыво.