log4j.xml в клиентских банках
С SVN + Apache (mod_dav_svn.so, mod_authz_svn.so) кажется, что я получаю:
- Анонимный доступ только для чтения по протоколу HTTP с широким диапазоном поддерживаемых клиентов для загрузки (wget / curl из GNU Сделай, задание для Apache Ant).
-
Простой поддерживаемый доступ для записи для пользователей / групп (простой синтаксис):
[repo:/path] user = rw
с помощью утилиты Cadaver.
-
Интеграция с LDAP.
- История выпусков (когда, что и кто).
- Атомная операция (предотвращение одновременных выпусков и откат при ошибках).
5 ответов
Yes, leave it out. It's an utter nuisance when your log4j configuration file is ignored because one of the 60 third-party libraries of your app contains its own.
The good thing about log4j in your case is that your jar really shouldn't have to worry about it. The basic use case of log4j is:
- Obtain a logger object for the current class
- Call one of the methods on that logger, such as
debug("some message");
If the jars you are shipping are to be used by a larger application, then ideally your code will only do the two steps listed above. In this way, your code will simply obtain logger objects from the already-configured log4j instance in the client's application. Your production code is then decoupled from having to know how to configure log4j.
Any logging you need to see for your development of the jars can be accomplished by configuring a log4j instance in unit test setUp() methods or something similar that won't get bundled with the production code going to the client.
I would put a default log4j configuration that you expect will be useful to your clients in the documentation. This way interested people can see what logging options you have (usually certain classes have more interesting log messages, from the user's perspective). I find it annoying when I have a third-party lib using log4j and it has no documentation, and there are log messages filling my screen and I have to try to figure out how to enable or suppress certain log messages.
If you are using log4j in your application then you include it in your project. If you are not, then why would you put it in there? What if client A wants log4j version 1.2 and client B wants log4j version 1.3.
Let them decide what they need for their projects and worry about what you need for yours.
Я бы добавил конфигурационный xml и загрузил его с инструкциями для пользователя, показывающими различные конфигурации и параметры. Это упростит для них или поддержки включение дополнительного ведения журнала.