IRC meeting
by Steve Ebersole
I may not be able to make todays meeting either. The warranty folks are
coming to look at my laptop this morning, so depending on how that goes...
12 years, 10 months
ORM 4.1.10.Final tomorrow?
by Brett Meyer
We're planning on releasing ORM 4.1.10.Final tomorrow. We were waiting for Javassist regression fixes before upgrading its version and releasing, but it's taking much longer than anticipated. This release will continue to use Javassist 3.15.
Any issues or concerns?
Brett Meyer
Red Hat Software Engineer, Hibernate
12 years, 10 months
Re: [hibernate-dev] Backward compatibility with hibernate 4.1.9
by Steve Ebersole
Exactly. You are relying, externally, on an internal detail of
Hibernate. These are connections controlled by Hibernate. Plus, as
Sanne already mentioned, you are talking about behavior across
different major versions.
pass it Connection.class. Or, yes, you can also pass it a more
concrete Connection class. But the Hibernate Connection proxy
understands:
unwrap ( Connection.class )
as a request to "unwrap" itself by returning the underlying JDBC
connection
On Fri 15 Feb 2013 07:41:49 AM CST, amit shah wrote:
> I didn't understand the reason why you say that it is not a backward
> compatibility problem. Isn't creating proxies a internal logic of
> hibernate?
>
> Also I didn't get the unwrap() solution? What parameter should the
> client code pass to the unwrap() method ? The driver class name?
>
> As a workaround - Is there a hibernate configuration property to
> inform hibernate to not proxy jdbc classes?
>
> Thank you for the quick responses.
>
>
> On Fri, Feb 15, 2013 at 6:44 PM, Steve Ebersole <steve(a)hibernate.org
> <mailto:steve@hibernate.org>> wrote:
>
> If you want the un-proxied version of the JBDC Connection, then
> unwrap() it. That is the standard pattern for dealing with JDBC
> objects.
>
> And no, this is not a backwards compatibility problem.
>
>
> On Fri 15 Feb 2013 06:52:33 AM CST, amit shah wrote:
>
> I think the defect description was not clear probably. The
> issue is
> not related to backward compatibility of hibernate with other
> frameworks (spring in this case). It is with hibernate 4.1.9
> vs 3.6.0.
>
> Hibernate 3.6.0 threw checked exceptions (SQLException) while
> 4.1.9
> throws an unchecked exception (SQLGrammerException).
>
>
> On Fri, Feb 15, 2013 at 5:28 PM, Sanne Grinovero
> <sanne(a)hibernate.org <mailto:sanne@hibernate.org>
> <mailto:sanne@hibernate.org <mailto:sanne@hibernate.org>>> wrote:
>
> Hi Amit,
> please use the developer list for such concerns, which
> I've added
> in CC.
>
> Personally I don't think your issue is valid, but I'll
> leave that to
> the other team members to decide.
> We never promised backwards compatibility with other
> frameworks when
> upgrading from Hibernate 3 to 4, it is likely that you
> will need to
> make some adjustments in configurations; also I'm not a
> Spring expert
> but from what you describe it looks to me it's not a good
> idea to use
> the "spring jdbc template" as JDBC and Hibernate are two
> different
> things.
>
> Sanne
>
> On 15 February 2013 11:41, amit shah <amits.84(a)gmail.com
> <mailto:amits.84@gmail.com>
> <mailto:amits.84@gmail.com <mailto:amits.84@gmail.com>>>
> wrote:
> > Hello Steve/Sanne,
> > While upgrading to hibernate 4.1.9 from
> 3.6.0 I
> am facing an
> > blocking issue for which I would appreciate if you can
> provide
> your inputs.
> > The issue was logged on jira forum but it didn't get much
> attention. I will
> > paste it here once. Kindly let me know your thoughts.
> >
> >
> > Description
> >
> > I upgraded my project with hibernate 4.1.9 and spring
> 3.2.1 and
> noticed that
> > hibernate throws RuntimeExceptions instead of checked
> exception
> in the
> > earlier version (3.6.0 final was the one we used
> earlier). The
> code use case
> > is as below.
> >
> > We use spring jdbc template for executing jdbc queries
> and the
> application
> > is configured to use JPA (JPATransactionManager and
> JPADialect)
> for mapped
> > entities. When executing a query which could throw a
> exception
> for e.g. a
> > select query on a table that does not exist, hibernate now
> proxies the jdbc
> > statements and throws a SQLGrammerException (extends
> RuntimeException)
> > instead of a checked exception - SQLException.
> >
> > Since spring catch's SQLException, the code no longer
> executes
> the catch
> > block and fails with an exception.
> >
> > Attached a sample java program to reproduce the issue.
> Please
> execute the
> > main method of the ExceptionHandlingTask class. It
> starts a spring
> > transaction and executes a query on a non existing table.
> >
> > Spring and hibernate jars must be included in the classpath.
> >
> > Thank you,
> > Amit.
>
>
>
12 years, 10 months
Re: [hibernate-dev] Backward compatibility with hibernate 4.1.9
by Sanne Grinovero
Since it it's a different mayor release, such changes are expected.
We always work hard to maintain backwards compatibility, but occasionally
we need to make significant improvements which will break compatibility:
Hibernate 4.x is significantly different than Hibernate 3.x and such
changes are by design: it is expected that you might have to make
significant changes to your application.
In your specific case I think you should consider removing the usage of
Spring templates, or fork the Spring templates to catch the exceptions you
need, or keep using Hibernate 3.x.
Il giorno 15/feb/2013 12:52, "amit shah" <amits.84(a)gmail.com> ha scritto:
>
> I think the defect description was not clear probably. The issue is not
related to backward compatibility of hibernate with other frameworks
(spring in this case). It is with hibernate 4.1.9 vs 3.6.0.
>
> Hibernate 3.6.0 threw checked exceptions (SQLException) while 4.1.9
throws an unchecked exception (SQLGrammerException).
>
>
> On Fri, Feb 15, 2013 at 5:28 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
>>
>> Hi Amit,
>> please use the developer list for such concerns, which I've added in CC.
>>
>> Personally I don't think your issue is valid, but I'll leave that to
>> the other team members to decide.
>> We never promised backwards compatibility with other frameworks when
>> upgrading from Hibernate 3 to 4, it is likely that you will need to
>> make some adjustments in configurations; also I'm not a Spring expert
>> but from what you describe it looks to me it's not a good idea to use
>> the "spring jdbc template" as JDBC and Hibernate are two different
>> things.
>>
>> Sanne
>>
>> On 15 February 2013 11:41, amit shah <amits.84(a)gmail.com> wrote:
>> > Hello Steve/Sanne,
>> > While upgrading to hibernate 4.1.9 from 3.6.0 I am
facing an
>> > blocking issue for which I would appreciate if you can provide your
inputs.
>> > The issue was logged on jira forum but it didn't get much attention. I
will
>> > paste it here once. Kindly let me know your thoughts.
>> >
>> >
>> > Description
>> >
>> > I upgraded my project with hibernate 4.1.9 and spring 3.2.1 and
noticed that
>> > hibernate throws RuntimeExceptions instead of checked exception in the
>> > earlier version (3.6.0 final was the one we used earlier). The code
use case
>> > is as below.
>> >
>> > We use spring jdbc template for executing jdbc queries and the
application
>> > is configured to use JPA (JPATransactionManager and JPADialect) for
mapped
>> > entities. When executing a query which could throw a exception for
e.g. a
>> > select query on a table that does not exist, hibernate now proxies the
jdbc
>> > statements and throws a SQLGrammerException (extends RuntimeException)
>> > instead of a checked exception - SQLException.
>> >
>> > Since spring catch's SQLException, the code no longer executes the
catch
>> > block and fails with an exception.
>> >
>> > Attached a sample java program to reproduce the issue. Please execute
the
>> > main method of the ExceptionHandlingTask class. It starts a spring
>> > transaction and executes a query on a non existing table.
>> >
>> > Spring and hibernate jars must be included in the classpath.
>> >
>> > Thank you,
>> > Amit.
>
>
12 years, 10 months
Re: [hibernate-dev] Backward compatibility with hibernate 4.1.9
by Steve Ebersole
If you want the un-proxied version of the JBDC Connection, then
unwrap() it. That is the standard pattern for dealing with JDBC
objects.
And no, this is not a backwards compatibility problem.
On Fri 15 Feb 2013 06:52:33 AM CST, amit shah wrote:
> I think the defect description was not clear probably. The issue is
> not related to backward compatibility of hibernate with other
> frameworks (spring in this case). It is with hibernate 4.1.9 vs 3.6.0.
>
> Hibernate 3.6.0 threw checked exceptions (SQLException) while 4.1.9
> throws an unchecked exception (SQLGrammerException).
>
>
> On Fri, Feb 15, 2013 at 5:28 PM, Sanne Grinovero <sanne(a)hibernate.org
> <mailto:sanne@hibernate.org>> wrote:
>
> Hi Amit,
> please use the developer list for such concerns, which I've added
> in CC.
>
> Personally I don't think your issue is valid, but I'll leave that to
> the other team members to decide.
> We never promised backwards compatibility with other frameworks when
> upgrading from Hibernate 3 to 4, it is likely that you will need to
> make some adjustments in configurations; also I'm not a Spring expert
> but from what you describe it looks to me it's not a good idea to use
> the "spring jdbc template" as JDBC and Hibernate are two different
> things.
>
> Sanne
>
> On 15 February 2013 11:41, amit shah <amits.84(a)gmail.com
> <mailto:amits.84@gmail.com>> wrote:
> > Hello Steve/Sanne,
> > While upgrading to hibernate 4.1.9 from 3.6.0 I
> am facing an
> > blocking issue for which I would appreciate if you can provide
> your inputs.
> > The issue was logged on jira forum but it didn't get much
> attention. I will
> > paste it here once. Kindly let me know your thoughts.
> >
> >
> > Description
> >
> > I upgraded my project with hibernate 4.1.9 and spring 3.2.1 and
> noticed that
> > hibernate throws RuntimeExceptions instead of checked exception
> in the
> > earlier version (3.6.0 final was the one we used earlier). The
> code use case
> > is as below.
> >
> > We use spring jdbc template for executing jdbc queries and the
> application
> > is configured to use JPA (JPATransactionManager and JPADialect)
> for mapped
> > entities. When executing a query which could throw a exception
> for e.g. a
> > select query on a table that does not exist, hibernate now
> proxies the jdbc
> > statements and throws a SQLGrammerException (extends
> RuntimeException)
> > instead of a checked exception - SQLException.
> >
> > Since spring catch's SQLException, the code no longer executes
> the catch
> > block and fails with an exception.
> >
> > Attached a sample java program to reproduce the issue. Please
> execute the
> > main method of the ExceptionHandlingTask class. It starts a spring
> > transaction and executes a query on a non existing table.
> >
> > Spring and hibernate jars must be included in the classpath.
> >
> > Thank you,
> > Amit.
>
>
12 years, 10 months
Re: [hibernate-dev] Backward compatibility with hibernate 4.1.9
by Sanne Grinovero
Hi Amit,
please use the developer list for such concerns, which I've added in CC.
Personally I don't think your issue is valid, but I'll leave that to
the other team members to decide.
We never promised backwards compatibility with other frameworks when
upgrading from Hibernate 3 to 4, it is likely that you will need to
make some adjustments in configurations; also I'm not a Spring expert
but from what you describe it looks to me it's not a good idea to use
the "spring jdbc template" as JDBC and Hibernate are two different
things.
Sanne
On 15 February 2013 11:41, amit shah <amits.84(a)gmail.com> wrote:
> Hello Steve/Sanne,
> While upgrading to hibernate 4.1.9 from 3.6.0 I am facing an
> blocking issue for which I would appreciate if you can provide your inputs.
> The issue was logged on jira forum but it didn't get much attention. I will
> paste it here once. Kindly let me know your thoughts.
>
>
> Description
>
> I upgraded my project with hibernate 4.1.9 and spring 3.2.1 and noticed that
> hibernate throws RuntimeExceptions instead of checked exception in the
> earlier version (3.6.0 final was the one we used earlier). The code use case
> is as below.
>
> We use spring jdbc template for executing jdbc queries and the application
> is configured to use JPA (JPATransactionManager and JPADialect) for mapped
> entities. When executing a query which could throw a exception for e.g. a
> select query on a table that does not exist, hibernate now proxies the jdbc
> statements and throws a SQLGrammerException (extends RuntimeException)
> instead of a checked exception - SQLException.
>
> Since spring catch's SQLException, the code no longer executes the catch
> block and fails with an exception.
>
> Attached a sample java program to reproduce the issue. Please execute the
> main method of the ExceptionHandlingTask class. It starts a spring
> transaction and executes a query on a non existing table.
>
> Spring and hibernate jars must be included in the classpath.
>
> Thank you,
> Amit.
12 years, 10 months
