On Thu, Aug 22, 2013 at 6:32 PM, Nick Williams <
nicho...@nicholaswilliams.net> wrote:
> Well we don't need what's currently provided with those legacy classes,
> because a different approach was taken with this JDBCAppender to handle ID
> columns.
>
> I have several problems with this approach:
>
That definitely took care of it. Thank you for pointing me in the right
direction.
On Thu, Aug 22, 2013 at 4:04 PM, Nick Williams <
nicho...@nicholaswilliams.net> wrote:
> Tomcat 7 introduced a feature to skip the scanning of certain JARs to
> improve JSP engine initialization. This feature inc
Well we don't need what's currently provided with those legacy classes, because
a different approach was taken with this JDBCAppender to handle ID columns.
I have several problems with this approach:
1) The implementation would be far more complicated, because the dialects would
have to be used
That doesn't look like much work. Particularly since you could lift
what's provided and just extend it to support the one-off we're
talking about here, yes?
On 8/22/13, Nick Williams wrote:
> Yes, I mean like that. I want to avoid something like that.
>
> N
>
> On Aug 22, 2013, at 4:59 PM, Scott
Tomcat 7 introduced a feature to skip the scanning of certain JARs to improve
JSP engine initialization. This feature including a default setting to skip
many popular JARs that were known not to contain TLDs or SCIs. Unfortunately,
this included a log4j*.jar default exclusion, meaning the Log4j
Yes, I mean like that. I want to avoid something like that.
N
On Aug 22, 2013, at 4:59 PM, Scott Deboy wrote:
> You mean like:
> http://logging.apache.org/log4j/companions/receivers/apidocs/org/apache/log4j/db/dialect/package-summary.html
>
> Scott
>
> On 8/22/13, Nick Williams wrote:
>> IMO,
You mean like:
http://logging.apache.org/log4j/companions/receivers/apidocs/org/apache/log4j/db/dialect/package-summary.html
Scott
On 8/22/13, Nick Williams wrote:
> IMO, this is a bug in the PGSQL JDBC driver and not something that Log4j can
> easily (or should) address. For a detailed discussi
Pls unsubscribe me from this.
Thanks.
On Thu, Aug 22, 2013 at 2:48 PM, Jason B wrote:
> All,
>
> I'm running into a bit of weirdness when using Tomcat 7 and Log4j2's Tag
> Library. I have a JSP set up with the following property:
>
> <%@ taglib uri="http://logging.apache.org/log4j/tld/log";
All,
I'm running into a bit of weirdness when using Tomcat 7 and Log4j2's Tag
Library. I have a JSP set up with the following property:
<%@ taglib uri="http://logging.apache.org/log4j/tld/log"; prefix="log" %>
...which works just fine with Tomcat 6, whenever I hit an error condition.
However,
IMO, this is a bug in the PGSQL JDBC driver and not something that Log4j can
easily (or should) address. For a detailed discussion, see the PGSQL thread
about casting text to PGSQL enums [1].
The problem lies in PGSQL's type handling. With PGSQL, MySQL, and any other
database type that supports
Hello,
I'm wondering if it is at all possible to cast columns to a certain type (a
custom enum) with the JDBCAppender. I have an existing PostgreSQL database
that I send all warnings and errors to and the log level is currently being
stored as an enum. When I try and log to the database I get
11 matches
Mail list logo
