On 13/09/2013 19:29, Nick Williams wrote:
On Sep 13, 2013, at 10:26 AM, Francesco Chicchiriccò wrote:
Hi all,
I am trying to configure a JDBCAppender in log4j 2.0-beta9-SNAPSHOT, with a
pre-existing DataSource managed via Spring; such DataSource is used by the rest
of Syncope.
I have tried, without success. to provide a custom ConnectionSource or a
ConnectionFactory: the point is that, when log4j2 initializes, the Spring
context is yet to be built, hence no beans (including the DataSource referenced
above) are available.
I have read from [1] that log4j2 features an "automatic configuration": is
there any way to disable it and invoke it manually later?
You don't want to do this, because you could miss important logging events.
What happens if there is some failure in Spring that doesn't get logged because
you delayed configuration? You always want Log4j to start before anything else
in your application; otherwise, you could miss important events.
Ok, got the point.
Could you tell me a little bit more exactly how your DataSource is
"spring-managed?" This isn't exactly clear to me. Are you actually using Spring
Framework to create the DataSource somehow? If so, what Spring Framework feature/classes
are you using? If Spring Framework has to start in order to create your DataSource, this
is going to be a problem because logging will start too late.
There is definitely a way to get this working, and I can help you, I just need
a little better understanding of exactly how you're creating and distributing
the DataSource.
We have a "dataSource" bean (check full definition [2]) empowering the
defaultObject feature of Spring's JndiObjectFactoryBean [3]: e.g., any
datasource access will first attempt to find the specified JNDI
resource, otherwise it will go with the fallback (inefficient,
not-for-production) DriverManagerDataSource.
Such datasource is used ubiquitously in Syncope core.
After your reply, I have developed a simple ConnectionFactory for use
with JDBCAppender that basically does the same job as
JndiObjectFactoryBean, reading the same configuration data and I am
quite satisfied of the result.
Anyway, if it could be of any interest, I've found the following
non-blocking issues when migrating logback configuration to log4j2 (with
reference to [4] and [5])
1. possibility to split the configuration in multiple files ([5] is
actually part of [4])
2. possibility to inject properties from external file(s) (see
beginning of [5])
3. possibility to declare a DataSource inside the JDBCAppender
4. possibility to provide a custom connection source
Regards.
Thanks for your support.
Regards.
[1]
http://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticConfiguration
[2]
http://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/persistenceContext.xml
[3]
http://docs.spring.io/spring/docs/3.2.x/javadoc-api/org/springframework/jndi/JndiObjectFactoryBean.html
[4]
https://svn.apache.org/repos/asf/syncope/branches/1_1_X/core/src/main/resources/logback.xml
[5]
https://svn.apache.org/repos/asf/syncope/branches/1_1_X/core/src/main/resources/audit.xml
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
