Greetings, I'm using hibernate with Oracle and, try as I might, I'm unable to retrieve the actual primary key value of a record that's causing primary key violation. I've searched the forums and placed:

log4j.logger.org.hibernate.util.JDBCExceptionReporter=error

in my log4j properties but with no success. This is the only meaningful information I can retrieve:

insert into CHARGE (ACCOUNT_ID, BILL_PERIOD_END_DATE, BILL_PERIOD_START_DATE, BILLED_IND, CALCULATED_CHARGE, CALCULATED_DISCOUNT, CHARGE_CATEGORY, CHARGE_END_DATE, CHARGE_START_DATE, CLIN, CUSTOMER_ID, FINAL_CHARGE, GB_VOLUME, PRICING_STRUCTURE_CODE, PROCESS_DATE, PRODUCT_CODE, PRODUCT_TYPE, PRODUCT_VERSION_CODE, RATE, REQUEST_TITLE, REQUESTOR_NAME, SERVICE_CODE, SERVICE_REQUEST_ID, SUBSCRIPTION_ID, TIME_UNIT, TIME_VOLUME, CHARGE_ID) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
ORA-00001: unique constraint (CHARGE_ID_PK) violated

I've seen other posts whereby the users get something like this:
SEVERE: Duplicate entry 'blablabla' for key 'PRIMARY'

What do I need to do to get this in my log?

If I could at least figure out the ordinal number of the offending record in batch... anything to allow me to identify which record in batch is causing the problem.

If you're inserting a single entity, the offending PK is trivial to determine.
If you're inserting multiple entities, Oracle simply doesn't report the offending key value.
Unless somebody with way more Oracle knowledge than I have comes up with a better way, I'd suggest querying Oracle about all the PK values that were about to be written, and report that back. The lower in the software stack you do this (maybe in a subclass of Oracle10gDialect), the more direct the fix will be.
Personally, I have given up on that issue :-)

... oh, wait. I see this looks like a single-record insert already.
You can crank up the log level of org.hibernate.sql to see the SQL statements as they are submitted, and org.hibernate.type to see the bound parameters.
Be prepared for lots of output though :-)

Here's the full list:

Hibernate in general: org.hibernate

Transaction related activity: org.hibernate.transaction
begin, commit, rollback

Parsed HQL and SQL (ASTs): org.hibernate.hql.ast.AST
Good if the error messages about malformed HQL aren't informative (which is often the case)

Session entity dump on flush: org.hibernate.pretty
Limited to a handful of entities. Good for small snippets of test code, e.g. when testing Hibernate's behaviour.

SQL DML statements: org.hibernate.SQL
select, insert, update, delete

Bound parameters: org.hibernate.type
Values of bound parameters.

SQL DDL statements: org.hibernate.tool.hbm2ddl
Not sure whether this is even active outside Hibernate Tools.

Second-level cache activity: org.hibernate.cache
To see when stuff is pushed out or pulled in. Note that the second-level cache is not the session cache (the session cache is for dirty checking and may help with performance, the second-level cache is just for performance)

JDBC resource acquisition: org.hibernate.jdbc
Opening and closing JDBC connections/transactions/statements/resultsets etc.

JAAS authorization requests: org.hibernate.secure
I have no idea what that is. Probably some J2EE container stuff.

Thanks, actually that's exactly what I was afraid of: that it's a database driver limitation.
Kind of surprising though I've done some Oracle programming using java and C++ and I don't ever recall having this issue. But then maybe I never had to deal with batch multiple inserts until now... quite possible...

My knee-jerk reaction was: Hey, I don't see the offending key values even in Sqldeveloper, which is on the bare metal, so it's actually the database.
But then I realized that Sqldeveloper uses just the same JDBC driver, so we wouldn't be able to differentiate between driver and database issues.
And that led me to the question: maybe we're just not digging deep enough. There is a mostly-ignored "warnings" API in JDBC. It might be a good idea to check what Oracle JDBC reports through that channel (I know for sure that Sqldeveloper doesn't report everything that other tools do, maybe it's ignoring warnings, too?).

Keep us posted on whether you're getting warnings.
If you do, I'll want to upgrade my own error-reporting facilities as well :-)