[hibernate-dev] on broken usage of logger

2011-11-23 Thread Sanne Grinovero 
Hi all,
I'm having a chat with Hardy about how we used the Logger in some
cases, and it turns out there's some confusion about

  log.debugf   vs   log.debug
  log.tracef vs   log.trace

So the "F" variant is needed when we want to format a message, in this
case we should make sure the number of parameters matches exactly.

Also when the string is generated, like in the case of:

https://github.com/Sanne/hibernate-core/commit/3c5f8a568de99c7a6532647ab7b08c12738762ec#L36L485

it's very important that we do NOT use the formatting method, but just
a plain "log.debug( string )", otherwise it might happen at runtime
that the dynamically generated string contains some characters which
the String formatter might want interpret as placeholders, which are
missing. (HHH-6817)

In practice, it seems like a bad idea to allow a dynamically generated
formatting string at all; formatting strings as defined on the Logger
interface are safer;

In case a dynamically generated message is to be generated, we should
all make sure to pick the correct method signature; we're wondering if
there could be a reasonable proposal to make the checks of the
annotation processor stricter and validate for this, but there are
some (rare) valid use cases so just throwing compilation errors would
be nasty.

Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] on broken usage of logger

2011-11-23 Thread Christian Bauer 

On Nov 23, 2011, at 11:34 , Sanne Grinovero wrote:

>  log.debugf   vs   log.debug
>  log.tracef vs   log.trace

This also seems to be the difference between these messages with JUL:

[main] TRACE  - 11:27:51,428 - org.hibernate.loader.Loader: 
org.hibernate.internal.CoreMessageLogger_$logger
[main] TRACE  - 11:27:51,429 - org.hibernate.loader.Loader: 
Processing result set
[main] DEBUG  - 11:27:51,429 - org.hibernate.loader.Loader: 
org.hibernate.internal.CoreMessageLogger_$logger
[main] DEBUG  - 11:27:51,429 - org.hibernate.loader.Loader: 
org.hibernate.internal.CoreMessageLogger_$logger
[main] DEBUG  - 11:27:51,429 - org.hibernate.loader.Loader: 
org.hibernate.internal.CoreMessageLogger_$logger


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] on broken usage of logger

2011-11-23 Thread Hardy Ferentschik 
Hi,

this revives my email from Friday  
(http://lists.jboss.org/pipermail/hibernate-dev/2011-November/007307.html)
where I noticed this problem as well.

Generally speaking Sanne is of course right and the right logging method  
should be used,
but does the logging framework really have to propagate the exception  
thrown by String.format?

I don't think it has to. I don't think that logging should cause an  
application to die.
Couldn't the Logger just catch the exception and write out the unformatted  
message optionally
followed by an additional warning?

--Hardy



On Wed, 23 Nov 2011 11:34:29 +0100, Sanne Grinovero   
wrote:

> Hi all,
> I'm having a chat with Hardy about how we used the Logger in some
> cases, and it turns out there's some confusion about
>
>   log.debugf   vs   log.debug
>   log.tracef vs   log.trace
>
> So the "F" variant is needed when we want to format a message, in this
> case we should make sure the number of parameters matches exactly.
>
> Also when the string is generated, like in the case of:
>
> https://github.com/Sanne/hibernate-core/commit/3c5f8a568de99c7a6532647ab7b08c12738762ec#L36L485
>
> it's very important that we do NOT use the formatting method, but just
> a plain "log.debug( string )", otherwise it might happen at runtime
> that the dynamically generated string contains some characters which
> the String formatter might want interpret as placeholders, which are
> missing. (HHH-6817)
>
> In practice, it seems like a bad idea to allow a dynamically generated
> formatting string at all; formatting strings as defined on the Logger
> interface are safer;
>
> In case a dynamically generated message is to be generated, we should
> all make sure to pick the correct method signature; we're wondering if
> there could be a reasonable proposal to make the checks of the
> annotation processor stricter and validate for this, but there are
> some (rare) valid use cases so just throwing compilation errors would
> be nasty.
>
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] CR7 release

2011-11-23 Thread Steve Ebersole 
I am going to put releasing 4.0.0.CR7 until after the Thanksgiving 
holiday.  So rather than 11/23, it will be done 11/30.

Sorry for any difficulties.

-- 
st...@hibernate.org
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] on broken usage of logger

2011-11-23 Thread David M. Lloyd 
The solution is really easy guys:

log.debugf("The thing I want to log is %s", thing);
or
log.debug(thing)

In addition, as you have noticed, it is better to not use the formatting 
variants if you aren't actually formatting any strings (it doesn't make 
a difference if the message isn't logged, but if it is there is a slight 
performance boost).

As for error handling, yes, I think we should be doing somewhat better 
at that.  Normally this is handled by the internal logging layer but 
with the variations on they types of backends and the ways they are 
invoked, we should probably put this protection in at the front end as 
well.  I would accept a JBLOGGING JIRA to this effect.

On 11/23/2011 04:49 AM, Hardy Ferentschik wrote:
> Hi,
>
> this revives my email from Friday
> (http://lists.jboss.org/pipermail/hibernate-dev/2011-November/007307.html)
> where I noticed this problem as well.
>
> Generally speaking Sanne is of course right and the right logging method
> should be used,
> but does the logging framework really have to propagate the exception
> thrown by String.format?
>
> I don't think it has to. I don't think that logging should cause an
> application to die.
> Couldn't the Logger just catch the exception and write out the
> unformatted message optionally
> followed by an additional warning?
>
> --Hardy
>
>
>
> On Wed, 23 Nov 2011 11:34:29 +0100, Sanne Grinovero
>  wrote:
>
>> Hi all,
>> I'm having a chat with Hardy about how we used the Logger in some
>> cases, and it turns out there's some confusion about
>>
>> log.debugf vs log.debug
>> log.tracef vs log.trace
>>
>> So the "F" variant is needed when we want to format a message, in this
>> case we should make sure the number of parameters matches exactly.
>>
>> Also when the string is generated, like in the case of:
>>
>> https://github.com/Sanne/hibernate-core/commit/3c5f8a568de99c7a6532647ab7b08c12738762ec#L36L485
>>
>>
>> it's very important that we do NOT use the formatting method, but just
>> a plain "log.debug( string )", otherwise it might happen at runtime
>> that the dynamically generated string contains some characters which
>> the String formatter might want interpret as placeholders, which are
>> missing. (HHH-6817)
>>
>> In practice, it seems like a bad idea to allow a dynamically generated
>> formatting string at all; formatting strings as defined on the Logger
>> interface are safer;
>>
>> In case a dynamically generated message is to be generated, we should
>> all make sure to pick the correct method signature; we're wondering if
>> there could be a reasonable proposal to make the checks of the
>> annotation processor stricter and validate for this, but there are
>> some (rare) valid use cases so just throwing compilation errors would
>> be nasty.
>>
>> Sanne
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
- DML
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Added UpgradeLockTest for HHH-5222 and changed LockMode.OPTIMISTIC + LockMode.OPTIMISTIC_FORCE_INCREMENT

2011-11-23 Thread Scott Marlow 
As part of a fix for HHH-5222, I changed LockMode.OPTIMISTIC  + 
LockMode.OPTIMISTIC_FORCE_INCREMENT to be higher values than 
LockMode.READ.  This helps the case where the user starts with a READ 
lock and later upgrades to LockMode.OPTIMISTIC_FORCE_INCREMENT.

Previously, we would of only handled an upgrade from LockMode.OPTIMISTIC 
to LockMode.OPTIMISTIC_FORCE_INCREMENT.

This test passes with mysql51 and postgresql84 matrix profiles.  If it 
fails for other databases, we either need more locking primitives in 
that databases dialect or the database needs more features (we should 
exclude that dialect from the test).

Scott
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hbm mapping with hibernate 4

2011-11-23 Thread Dmitry Geraskov 

Hey, guys,

I created the simplest hbm mapping and try to build session factory(full 
project attached, Hibernate-core4.0.0.CR6):


/new MetadataSources(
 new ServiceRegistryBuilder().configure()

 .buildServiceRegistry()).buildMetadata().buildSessionFactory();/



And I get this exception(full log attached):

Caused by: org.xml.sax.SAXParseException; lineNumber: 5; columnNumber: 
26; cvc-elt.1: Cannot find the declaration of element 
'hibernate-configuration'.
at 
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)

   ...


When I build session factory using old syntax

/new Configuration().configure().buildSessionFactory();/

it works only with DTD schema(not 100% sure I found a correct header to 
use xsd for hibernate.cfg.xml):


http://www.hibernate.org/xsd/hibernate-configuration";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.hibernate.org/xsd/hibernate-configuration 
https://raw.github.com/hibernate/hibernate-core/master/hibernate-core/src/main/resources/org/hibernate/hibernate-configuration-4.0.xsd";>


.

This seems like a bug, or I do something wrong?

Dmitry Geraskov


Exception in thread "main" 
org.hibernate.internal.util.config.ConfigurationException: Unable to perform 
unmarshalling at line number 5 and column 26 in RESOURCE hibernate.cfg.xml. 
Message: cvc-elt.1: Cannot find the declaration of element 
'hibernate-configuration'.
at 
org.hibernate.service.internal.JaxbProcessor.unmarshal(JaxbProcessor.java:120)
at 
org.hibernate.service.internal.JaxbProcessor.unmarshal(JaxbProcessor.java:69)
at 
org.hibernate.service.ServiceRegistryBuilder.configure(ServiceRegistryBuilder.java:162)
at 
org.hibernate.service.ServiceRegistryBuilder.configure(ServiceRegistryBuilder.java:147)
at r.RunWithConfig.main(RunWithConfig.java:13)
Caused by: javax.xml.bind.UnmarshalException
 - with linked exception:
[org.xml.sax.SAXParseException; lineNumber: 5; columnNumber: 26; cvc-elt.1: 
Cannot find the declaration of element 'hibernate-configuration'.]
at 
com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:414)
at 
com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:351)
at 
com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:321)
at 
org.hibernate.service.internal.JaxbProcessor.unmarshal(JaxbProcessor.java:108)
... 4 more
Caused by: org.xml.sax.SAXParseException; lineNumber: 5; columnNumber: 26; 
cvc-elt.1: Cannot find the declaration of element 'hibernate-configuration'.
at 
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)
at 
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)
at 
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:387)
at 
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:321)
at 
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1919)
at 
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:709)
at 
com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorHandlerImpl.startElement(ValidatorHandlerImpl.java:565)
at 
com.sun.xml.internal.bind.v2.runtime.unmarshaller.ValidatingUnmarshaller.startElement(ValidatingUnmarshaller.java:78)
at 
com.sun.xml.internal.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:60)
at 
com.sun.xml.internal.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleStartElement(StAXStreamConnector.java:231)
at 
com.sun.xml.internal.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:165)
at 
com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:349)
... 6 more

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev