, but thanks to work done
in LOG4J2-1730 (amongst others), this feature was a bit easier to implement now
than it was back in 2.0.
The new feature has been added to master. This uses the new ColumnMapping
plugin which has been added to the manual. Please verify and close.
> JDBCAppender:
ing()}} to get JDBC
driver auto-conversion.
was (Author: jvz):
>From LOG4J2-1730, I added a ColumnMapping plugin for CassandraAppender. This
>plugin could probably be reused to implement this feature request.
> JDBCAppender: Add support for data type
Mapping plugin for CassandraAppender. This
>plugin could probably be reused to implement this feature request.
> JDBCAppender: Add support for data types other then String
> --
>
> Key: LOG4J2-424
>
[
https://issues.apache.org/jira/browse/LOG4J2-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker reassigned LOG4J2-424:
--
Assignee: Matt Sicker (was: Nick Williams)
> JDBCAppender: Add support for data types ot
[
https://issues.apache.org/jira/browse/LOG4J2-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15591003#comment-15591003
]
Badreddine BENAIDJA commented on LOG4J2-424:
I'll take a look
>
nder?
> JDBCAppender: Add support for data types other then String
> --
>
> Key: LOG4J2-424
> URL: https://issues.apache.org/jira/browse/LOG4J2-424
> Project: Log4j 2
>
d by
org.apache.logging.log4j.core.appender.db.jdbc.JdbcDatabaseManager by calling
PreparedStatement.setString()
> JDBCAppender: Add support for data types other then String
> --
>
> Key: LOG4J2-424
> URL: https://issues.apache.org/jir
y is generated by
org.apache.logging.log4j.core.appender.db.jdbc.JdbcDatabaseManager by calling
PreparedStatement.setString()
> JDBCAppender: Add support for data types other then String
> --
>
> Key: LOG4J2-424
>
in the object
*org.apache.logging.log4j.core.appender.db.jdbc.JdbcDatabaseManager.Column*
Switch on it and call the right method of java.sql.PreparedStatement
setString(...)
setInt(...)
setFloat(...)
... etc
> JDBCAppender: Add support for data types
better way, so
be aware that if you rely on ThreadContextAccess, your code may break with any
Log4j upgrade.
We need to think about how we can extend the ThreadContext facade or allow
custom facades or provide some other way for applications to access any
additional API that their ThreadContextMap im
cess any
additional API that their ThreadContextMap implementation provides.
> JDBCAppender: Add support for data types other then String
> --
>
> Key: LOG4J2-424
> URL: https://i
JDBC driver you are using is not smart
enough to do type conversion.
> JDBCAppender: Add support for data types other then String
> --
>
> Key: LOG4J2-424
> URL: https://issues.apache.org/jir
yped version of Thread Context.
> JDBCAppender: Add support for data types other then String
> --
>
> Key: LOG4J2-424
> URL: https://issues.apache.org/jira/browse/LOG4J2-424
>
you mean Thread Context ?
> JDBCAppender: Add support for data types other then String
> --
>
> Key: LOG4J2-424
> URL: https://issues.apache.org/jira/browse/LOG4J2-424
> Project: Lo
in the object
org.apache.logging.log4j.core.appender.db.jdbc.JdbcDatabaseManager.Column
Switch on it and call the right method of java.sql.PreparedStatement
setInt(...)
setFloat(...)
... etc
> JDBCAppender: Add support for data types other then String
> --
>
>
in the object
org.apache.logging.log4j.core.appender.db.jdbc.JdbcDatabaseManager.Column
Switch on it and call the right method of java.sql.PreparedStatement
setInt(...)
setFloat(...)
... etc
> JDBCAppender: Add support for data types other then String
> --
>
> Key: LOG4J2-424
&g
in the object
org.apache.logging.log4j.core.appender.db.jdbc.JdbcDatabaseManager.Column
Switch on it and call the right method of java.sql.PreparedStatement
setInt(...)
setFloat(...)
... etc
> JDBCAppender: Add support for data types other then String
> --
>
> Key: LOG4J2-424
&g
new ContextData for this?
> JDBCAppender: Add support for data types other then String
> --
>
> Key: LOG4J2-424
> URL: https://issues.apache.org/jira/browse/LOG4J2-424
> Project: Lo
)
... etc
> JDBCAppender: Add support for data types other then String
> --
>
> Key: LOG4J2-424
> URL: https://issues.apache.org/jira/browse/LOG4J2-424
> Project: Log4j 2
>
the PluginManager to locate and install a
"KeyProvider" for use in providing the secret key for encryption. I would
suggest that it would be possible to enhance the JdbcAppender in the same way
to provide the column handler you would really like, instead of just adding the
max length as a par
reat :-)
> Add maxLength parameter to Column element of JdbcAppender
> -
>
> Key: LOG4J2-977
> URL: https://issues.apache.org/jira/browse/LOG4J2-977
> Project: Log4j 2
>
[
https://issues.apache.org/jira/browse/LOG4J2-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-977:
Description:
For a Column element within the JdbcAppender, add a maxLength parameter to
truncate
[
https://issues.apache.org/jira/browse/LOG4J2-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-977:
Summary: Add maxLength parameter to Column element of JdbcAppender (was:
Add maxLength parameter
[
https://issues.apache.org/jira/browse/LOG4J2-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-977:
Description:
For a Column element within the JDBCAppender, add a maxLength parameter to
truncate
Jeff Snow created LOG4J2-977:
Summary: Add maxLength parameter to Column element of JDBCAppender
Key: LOG4J2-977
URL: https://issues.apache.org/jira/browse/LOG4J2-977
Project: Log4j 2
Issue Type
dn't work.
> JDBCAppender: Add support for data types other then String
> --
>
> Key: LOG4J2-424
> URL: https://issues.apache.org/jira/browse/LOG4J2-424
> Project: Log4j 2
&g
#x27;m doing it now :-)
> JDBCAppender: Add support for data types other then String
> --
>
> Key: LOG4J2-424
> URL: https://issues.apache.org/jira/browse/LOG4J2-424
> Project: Log4j
ver, a logical next step would be making the TypeConverters
properly extensible.
As a related addition, an SQLXML column type could allow for use of the
XmlLayout as well. This would most likely require additions to the Column
configuration element.
> JDBCAppender: Add support for d
l be able to validate this fix on my
end mid next week if someone else has not validated sooner.
Michael
> JDBCAppender cannot recover from loss of database connectivity
> --
>
> Key: LOG4J2-407
>
{{}} connection source plugin is no longer
available. It was removed because it was unsafe and didn't support connection
pooling. Please use the {{}} or {{}}
connection source plugins, instead.
> JDBCAppender does not release JDBC connections to the connection pool when
> WAR/EAR
{{}} connection source plugin is no longer
available. It was removed because it was unsafe and didn't support connection
pooling. Please use the {{}} or {{}}
connection source plugins, instead.
> JDBCAppender cannot recover from loss of database conn
[
https://issues.apache.org/jira/browse/LOG4J2-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams reassigned LOG4J2-457:
Assignee: Nick Williams
> JDBCAppender does not release JDBC connections to the connect
l have to look into that sometime.
> JDBCAppender does not release JDBC connections to the connection pool when
> WAR/EAR is stopped
> -
>
> Key: LOG4J2-457
>
FYI.
> JDBCAppender does not release JDBC connections to the connection pool when
> WAR/EAR is stopped
> -
>
> Key: LOG4J2-457
> URL: https://issues.apache.org/
is pretty low level.
> JDBCAppender does not release JDBC connections to the connection pool when
> WAR/EAR is stopped
> -
>
> Key: LOG4J2-457
> URL: https
for pooling Connection objects.
It's no good to keep closing connection objects from what I recall.
> JDBCAppender cannot recover from loss of database connectivity
> --
>
> Key: LOG4J2-407
>
ntract on the AbstractDatabaseAppender
that writeInternal() won't call connect() more than once. Then again, this
isn't using the super.connect() method, so that might be a better idea.
> JDBCAppender cannot recover from loss of
ment(this.sqlStatement);
...
Closer.closeSilent(connection);
{code}
Should work, I don't know the overhead of preparing the statement each time vs
one-time prepare...
> JDBCAppender cannot recover from loss of database
sort of connection pool considering
how it's normally implemented. An actual connection pool would be necessary for
the DriverManagerConnectionSource so that connections can be opened and closed
for each log event or batch update.
> JDBCAppender cannot recover from loss of database
use the JPAAppender? But I like
the idea of supporting some other column types.
> JDBCAppender: Add support for data types other then String
> --
>
> Key: LOG4J2-424
> URL: https://issues.apa
Hi everyone,
I've just created a new issues on the log4j JIRA:
https://issues.apache.org/jira/browse/LOG4J2-457
c/p:
We use log4j 2 for logging inside our J2EE app (packaged as EAR, log4j JARs
are bundled inside). The app is deployed on JBOSS EAP 6.1 app server. We
are using the JDBCApp
Tihomir Meščić created LOG4J2-457:
-
Summary: JDBCAppender does not release JDBC connections to the
connection pool when WAR/EAR is stopped
Key: LOG4J2-457
URL: https://issues.apache.org/jira/browse/LOG4J2-457
best solution imho, but make it flexible by
providing a data source to the JDBCAppender.
> JDBCAppender cannot recover from loss of database connectivity
> --
>
> Key: LOG4J2-407
>
ined by
Michael Kloster)
I'm more in favor of the second for a long term solution, but as a quickfix I
wrote some code doing the first. I was unable to test my code today, I hope to
be able to provide quickfix by friday (my application needs it bad),
> JDBCAppender cannot recover fr
vercome with a "isPooled" flag. Then the
appender could supply its own 'poor man's' version of a pool like it does now
if the connection is not marked as pooled.
> JDBCAppender cannot
alid(t) seems a bit overkill. I think (although
not tested) that this would decimate performance for both the application and
the DB server.
> JDBCAppender cannot recover from loss of database connectivity
> --
>
>
not work.
It was intentionally placed after the first check.
A complete fix would do it differently though:
* if an SQLException is caught -> check if the connection is still valid
* re-connect
* if re-connect was successful -> re-try writing the log entry
> JDBCAppender cannot recover
quot;Cannot write logging
event; JDBC manager not connected to the database.");
}
}
{code}
> JDBCAppender cannot recover from loss of database connectivity
> --
>
>
o re-establish connection to the database
if ( !this.connection.isValid( 1 )) {
disconnectInternal();
connectInternal();
}
{noformat}
> JDBCAppender cannot recover from loss of data
Log4J in
these scenario's as well.
> JDBCAppender cannot recover from loss of database connectivity
> --
>
> Key: LOG4J2-407
> URL: https://issues.apache.org/jira/browse/LOG4J2-407
&
[
https://issues.apache.org/jira/browse/LOG4J2-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams reassigned LOG4J2-424:
Assignee: Nick Williams
> JDBCAppender: Add support for data types other then Str
Tihomir Meščić created LOG4J2-424:
-
Summary: JDBCAppender: Add support for data types other then String
Key: LOG4J2-424
URL: https://issues.apache.org/jira/browse/LOG4J2-424
Project: Log4j 2
[
https://issues.apache.org/jira/browse/LOG4J2-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams updated LOG4J2-407:
-
Assignee: Nick Williams
> JDBCAppender cannot recover from loss of database connectiv
st way to approach this for several weeks now.
Want it to be elegant and simple but still robust like you say. I have a few
ideas that I'm playing with. I intend to make this happen before GA.
> JDBCAppender cannot recover from loss of data
Michael Kloster created LOG4J2-407:
--
Summary: JDBCAppender cannot recover from loss of database
connectivity
Key: LOG4J2-407
URL: https://issues.apache.org/jira/browse/LOG4J2-407
Project: Log4j 2
Hi,
I am using Log4j with JDBCAppender using XML configuration, to make the
logs in the database. The problem is that the password in log4j.xml file
is in plain text. How can I hide this password?
I have used
MDC.put("pass", "abc");
to place the password and it works
https://issues.apache.org/bugzilla/show_bug.cgi?id=53415
Priority: P2
Bug ID: 53415
Assignee: log4j-dev@logging.apache.org
Summary: JDBCAppender cannot reconnect after connection closed
Severity: critical
Classification: Unclassified
https://issues.apache.org/bugzilla/show_bug.cgi?id=51597
grobmeier changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://issues.apache.org/bugzilla/show_bug.cgi?id=51597
Anurag Agarwal changed:
What|Removed |Added
CC||anurag08agar...@gmail.com
--
Con
https://issues.apache.org/bugzilla/show_bug.cgi?id=51597
Bug #: 51597
Summary: JDBCAppender not closed due to SQL Exception while
executing an SQL
Product: Log4j
Version: unspecified
Platform: PC
OS/Version: All
https://issues.apache.org/bugzilla/show_bug.cgi?id=50817
Anurag Agarwal changed:
What|Removed |Added
CC||anurag08agar...@gmail.com
--
Con
邮件已收到，谢谢！
https://issues.apache.org/bugzilla/show_bug.cgi?id=50817
--- Comment #1 from haowei 2011-02-22 09:36:43 EST ---
Use the jars:
classes12.jar
apache-log4j-1.2.16.jar
commons-logging-1.1.1.jar
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receivi
邮件已收到，谢谢！
https://issues.apache.org/bugzilla/show_bug.cgi?id=50817
Summary: The JDBCAppender can't insert log info like
this:hello'world
Product: Log4j
Version: 1.2
Platform: PC
OS/Version: Windows XP
S
On Dec 10, 2010, at 3:32 AM, Peter Szanto wrote:
> Hi Jake and Ralph
>
> I submitted the updated version of JDBC Appender to bugzilla to here:
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50366
>
> Is there anything else I should do?
>
> Thanks
>
> P
>
There does not seem to be a
2010 5:48 AM, Peter Szanto wrote:
> > Hi All
> >
> > I plan to optimize the JDBCAppender to use batch updates and do the JDBC
> > part asynchronously. How is it possible to contribute it back to the
> > community? (i.e.: became a commiter)
> >
> > Thanks
&g
https://issues.apache.org/bugzilla/show_bug.cgi?id=50366
Peter Szanto <1.sz.pe...@gmail.com> changed:
What|Removed |Added
CC||1.sz.pe...@gma
https://issues.apache.org/bugzilla/show_bug.cgi?id=50366
Summary: JDBCAppender Enhancement
Product: Log4j
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
*Thank you for both replies. There is no similar issue in Bugzilla, but the
javadoc of JDBCAppender says*
*WARNING: This version of JDBCAppender is very likely to be completely
replaced in the future. Moreoever, it does not log exceptions*.
To me it seems the original developer wasn't sati
to donate the changes to the
Apache Foundation.
Note that any changes must be backward compatible with the existing code so
behavior does not change (for the worse) for existing users/extenders.
Jake
On 11/19/2010 5:48 AM, Peter Szanto wrote:
> Hi All
>
> I plan to optimize the JDBCAp
On Nov 19, 2010, at 3:48 AM, Peter Szanto wrote:
> Hi All
>
> I plan to optimize the JDBCAppender to use batch updates and do the JDBC part
> asynchronously. How is it possible to contribute it back to the community?
> (i.e.: became a commiter)
>
The normal method of
Hi All
I plan to optimize the JDBCAppender to use batch updates and do the JDBC
part asynchronously. How is it possible to contribute it back to the
community? (i.e.: became a commiter)
Thanks
https://issues.apache.org/bugzilla/show_bug.cgi?id=48820
Summary: JDBCAppender inserts the current MDC values for the
previous logging event after failure
Product: Log4j
Version: 1.2
Platform: PC
OS/Version: Windows XP
https://issues.apache.org/bugzilla/show_bug.cgi?id=45299
Curt Arnold <[EMAIL PROTECTED]> changed:
What|Removed |Added
Blocks|45527 |
--
Configur
https://issues.apache.org/bugzilla/show_bug.cgi?id=45299
Curt Arnold <[EMAIL PROTECTED]> changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.apache.org/bugzilla/show_bug.cgi?id=45299
--- Comment #2 from Thorbjørn Ravn Andersen <[EMAIL PROTECTED]> 2008-08-03
03:43:03 PST ---
Created an attachment (id=22350)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22350)
move description up above red warning
--
https://issues.apache.org/bugzilla/show_bug.cgi?id=45299
--- Comment #1 from Thorbjørn Ravn Andersen <[EMAIL PROTECTED]> 2008-08-03
03:41:33 PST ---
The URL for this is
http://logging.apache.org/log4j/1.2/apidocs/index-all.html#_J_
The problem is that JavaDoc uses the first sentence only,
https://issues.apache.org/bugzilla/show_bug.cgi?id=45299
Thorbjørn Ravn Andersen <[EMAIL PROTECTED]> changed:
What|Removed |Added
Blocks||45527
https://issues.apache.org/bugzilla/show_bug.cgi?id=45299
Summary: javadoc page for jdbcappender
Product: Log4j
Version: 1.2
Platform: PC
OS/Version: Windows 2000
Status: NEW
Severity: trivial
Priority: P2
Hello Danko,
Your generous offer to contribute your JDBCAppender to the log4j project is
well appreciated. As you have observed, Raymond DeCampo, has offered to
contribute his PreparedStatementAppender. I will take the next few hours to
study both code bases. I very much hope to engage both of
Hi,
I have been asked by Scott Deboy to contribute my JDBCAppender to the Log4J
project. It was initially developed by Thomas Fenner and is now maintained
by me. It is currently listed as a Third-party extension on the Log4J
download page.
My "project" home page is http://www.man
gzilla/show_bug.cgi?id=27505
JDBCAppender: allow to use JNDI datasource
--- Additional Comments From [EMAIL PROTECTED] 2004-04-01 22:48 ---
disregard my posting, it went to the wrong thread.
-
To unsubscribe, e-mail:
gzilla/show_bug.cgi?id=27505
JDBCAppender: allow to use JNDI datasource
--- Additional Comments From [EMAIL PROTECTED] 2004-04-01 22:46 ---
Hi Gino,
You're right that the JDBCAppender is not of production quality. This is the
second problem I discovered in this class. The first was w
gzilla/show_bug.cgi?id=27438
JDBCAppender doesn't release connection in case of failure
--- Additional Comments From [EMAIL PROTECTED] 2004-04-01 22:46 ---
Hi Gino,
You're right that the JDBCAppender is not of production quality. This is the
second problem I discovered in this
gzilla/show_bug.cgi?id=27438
JDBCAppender doesn't release connection in case of failure
--- Additional Comments From [EMAIL PROTECTED] 2004-03-31 08:52 ---
Hi Clement,
actually such an implementation is very likely to be completely replaced in the
future ... hence I don't know h
gzilla/show_bug.cgi?id=27438
JDBCAppender doesn't release connection in case of failure
--- Additional Comments From [EMAIL PROTECTED] 2004-03-31 03:36 ---
Before I forgot the closeConnection(con) method doesn't actually do anyth
gzilla/show_bug.cgi?id=27438
JDBCAppender doesn't release connection in case of failure
--- Additional Comments From [EMAIL PROTECTED] 2004-03-31 03:32 ---
Hi Gino,
The statements was there in the original version. I've left them untouched
stmt.close();
closeConnection(con);
gzilla/show_bug.cgi?id=27438
JDBCAppender doesn't release connection in case of failure
--- Additional Comments From [EMAIL PROTECTED] 2004-03-30 03:12 ---
Please try the PreparedStatementAppender in the log4j-sandbox (available via
Apache's CVS server). The PreparedStatementApp
gzilla/show_bug.cgi?id=27438
JDBCAppender doesn't release connection in case of failure
--- Additional Comments From [EMAIL PROTECTED] 2004-03-29 10:21 ---
Yes, it is.
There is the red label "WARNING: This version of JDBCAppender is very likely to
be completely replac
gzilla/show_bug.cgi?id=27438
JDBCAppender doesn't release connection in case of failure
--- Additional Comments From [EMAIL PROTECTED] 2004-03-29 09:36 ---
Hello,
Is this bug report relative to the JDBCAppender marked "buggy not for
production use" in red
gzilla/show_bug.cgi?id=27438
JDBCAppender doesn't release connection in case of failure
--- Additional Comments From [EMAIL PROTECTED] 2004-03-29 09:12 ---
Hi Clement,
your observations concerning firewall hold. Just one thing: if sql is bad
(e.g. "insert intoS ...") conn
gzilla/show_bug.cgi?id=27438
JDBCAppender doesn't release connection in case of failure
--- Additional Comments From [EMAIL PROTECTED] 2004-03-29 01:14 ---
Below is our implementation that allows a retry due to error errors executing
a piece of SQL statement. It assumes that this erro
gzilla/show_bug.cgi?id=27438
JDBCAppender doesn't release connection in case of failure
--- Additional Comments From [EMAIL PROTECTED] 2004-03-29 01:11 ---
In environments where corporate firewall exists between the deamon process
that uses JDBCAppender and the database, these
gzilla/show_bug.cgi?id=27505
JDBCAppender: allow to use JNDI datasource
--- Additional Comments From [EMAIL PROTECTED] 2004-03-13 23:24 ---
Note that the new JDBC-based appenders I have included in the log4j sandbox
allows the use of a JNDI data source. S
gzilla/show_bug.cgi?id=27505
JDBCAppender: allow to use JNDI datasource
Summary: JDBCAppender: allow to use JNDI datasource
Product: Log4j
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: Enhan
gzilla/show_bug.cgi?id=27438
JDBCAppender doesn't release connection in case of failure
Summary: JDBCAppender doesn't release connection in case of
failure
Product: Log4j
Version: 1.2
Platform: All
OS/Version: All
97 matches
Mail list logo
