Re: [hibernate-dev] Removing dom4j?

2018-02-16 Thread Jordan Gigov 
The woodstox dependency is incompatible with the rest of the XML API due to
a bug in the JDK that is otherwise hidden in all cases in the default
implementation.

Specifically it's implementation of EndElement brings that bug to the
forefront, when
com.sun.org.apache.xalan.internal.xsltc.trax.StAXEvent2SAX.handleElementEnd
tries to typecast a Namespace to String.

In the default implementation, that Namespace iterator is always empty, so
it never reaches that line.

Though that does make me wonder why the Document after being read is
scanned again as a DOMSource and then converted back to a Document object.
Might be a better way to pass it on altogether. Makes me wish I had noticed
the deprecation note on org.hibernate.boot.MetadataSources.addDocument(
Document)

On 16 February 2018 at 23:33, Sanne Grinovero  wrote:

> Hi Jordan,
>
> I think it would be great to remove it. Especially recently we've
> started exploring what it would take to convert all jars into proper
> Jigsaw modules, and a requirement is that all dependencies need to be
> converted as well; this is obviously more problematic for such old
> libraries so it would be best to remove it or find a good replacement.
>
> I'd suggest to work on the master branch though, we wouldn't want to
> apply this on the 5.2 branch which is now in maintenance mode.
>
> What do you mean with "shiv-libraries" ?
>
> Thanks,
> Sanne
>
>
> On 16 February 2018 at 21:11, Jordan Gigov  wrote:
> > So, the library has not seen a bugfix in over 10 years, and it lists the
> > wrong version for it's xml-apis dependency.
> > There are some notes in comments about eventually removing it, and I
> > thought I'd give it a try on the 5.2 branch.
> > I had to remove two shiv-libraries you had added to work around problems
> > you probably encountered prior to JDK6.
> >
> > I've narrowed it down to 11 failing tests (5 distinct exceptions) when
> > using the default XML APIs provided with JDK8.
> >
> > Is there any interest in this?
> > ___
> > 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

Re: [hibernate-dev] Removing dom4j?

2018-02-16 Thread Sanne Grinovero 
Hi Jordan,

I think it would be great to remove it. Especially recently we've
started exploring what it would take to convert all jars into proper
Jigsaw modules, and a requirement is that all dependencies need to be
converted as well; this is obviously more problematic for such old
libraries so it would be best to remove it or find a good replacement.

I'd suggest to work on the master branch though, we wouldn't want to
apply this on the 5.2 branch which is now in maintenance mode.

What do you mean with "shiv-libraries" ?

Thanks,
Sanne


On 16 February 2018 at 21:11, Jordan Gigov  wrote:
> So, the library has not seen a bugfix in over 10 years, and it lists the
> wrong version for it's xml-apis dependency.
> There are some notes in comments about eventually removing it, and I
> thought I'd give it a try on the 5.2 branch.
> I had to remove two shiv-libraries you had added to work around problems
> you probably encountered prior to JDK6.
>
> I've narrowed it down to 11 failing tests (5 distinct exceptions) when
> using the default XML APIs provided with JDK8.
>
> Is there any interest in this?
> ___
> 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

Re: [hibernate-dev] API incompatibilities between Hibernate ORM 5.3 and 6.0

2018-02-16 Thread Steve Ebersole 
I talked with Andrea and we both think this is getting important to do.  So
Monday we will start the process of integrating master (5.3) on to 6.0.
Then you'll be able to have a better idea.

This figures to be a huge undertaking, so not sure when it will be done.

On Thu, Feb 15, 2018 at 10:05 PM Steve Ebersole  wrote:

> I'm not sure what else to tell you.  Sure some things have been removed.
>
> I'm not going to go through all of these right now.  If there are some in
> particular you are interested please bring those of specifically.
>
>
> On Thu, Feb 15, 2018 at 6:48 PM Gail Badner  wrote:
>
>> Hi Steve,
>>
>> The list I provided contains removals from your fork in wip/6.0 branch.
>>
>> IIUC, integrating changes from master will not restore what was deleted
>> or moved to a different package.  After integrating from master and
>> resolving conflicts, we'll have the same incompatibilities.
>>
>> Am I missing something? Is there some other branch I should be comparing?
>>
>> Regards,
>> Gail
>>
>> On Thu, Feb 15, 2018 at 9:13 AM, Steve Ebersole 
>> wrote:
>>
>>> We have not integrated changes from master into 6.0 for a long time.
>>> And we probably won't for some time yet either.  So comparisons between 5.2
>>> or 5.3 and 6.0 right now are pointless
>>>
>>> On Wed, Feb 14, 2018 at 12:09 PM Gail Badner  wrote:
>>>
 I sent this last night with a huge report file, and it seems that it
 didn't
 get out.

 I'm re-sending without the report file...

 I ran japi-compliance-checker to compare differences in APIs
 between hibernate-core-5.3.0-SNAPSHOT.jar and hibernate-core-6.0.0-
 SNAPSHOT.jar.

 I ran it last week, so it may not include updates made since that time.

 Differences in Envers shown in the report should be disregarded because
 it
 only reflects that hibernate-envers was merged into hibernate-core. A
 separate comparison between hibernate-envers-5.3.0-SNAPSHOT.jar and
 hibernate-core-6.0.0-SNAPSHOT.jar needs to be done to see Envers
 changes.

 Chris will provide details about Envers differences in a separate email.

 The report is huge; it took me 3 to 4 hours to scan it. AFAICT, what
 I've
 documented are the only non-Envers API changes that could affect
 applications. They all involve removed classes/methods.

 My intention here is just to get this information out, so we have some
 solid examples to discuss.

 Regards,
 Gail

 
 --

 Custom types: I am not familiar with how this will work in 6.0. Steve,
 please fill in details about any incompatibilities.

 org.hibernate.Criteria and org.hibernate.criterion.DetachedCriteria:

 In 5.0/5.1/5.2:
 * user guides say, "This appendix covers the legacy Hibernate
 org.hibernate.Criteria API, which should be considered deprecated. New
 development should focus on the JPA
 javax.persistence.criteria.CriteriaQuery
 API. Eventually, Hibernate-specific criteria features will be ported as
 extensions to the JPA javax.persistence.criteria.CriteriaQuery. For
 details
 on the JPA APIs, see Criteria."

 In 5.2/5.3:
 * Criteria and DetachedCriteria are not deprecated;
 * all SharedSessionContract#createCriteria methods are deprecated;
 * public static methods in DetachedCriteria are not deprecated;

 In 6.0:
 * Criteria and DetachedCriteria are removed along with other classes in
 org.hibernate.criterion.

 Incompatibilities migrating from 5.3 -> 6.0:
 1) Existing applications using legacy org.hibernate.Criteria will need
 to
 be updated to use javax.persistence.criteria.CriteriaQuery;
 2) If Hibernate's implementation of
 javax.persistence.criteria.CriteriaQuery
 does not include the Hibernate-specific extensions that were available
 using org.hibernate.Criteria, applications may not have a
 straightforward
 way to change their applications to work.

 org.hibernate.Query

 In 5.1:
 * SharedSessionContract#createQuery returns org.hibernate.Query
 (org.hibernate.Session extends SharedSessionContract);

 In 5.2/5.3:
 * org.hibernate.Query was deprecated; org.hibernate.query.Query should
 be
 used instead; org.hibernate.query.Query extends org.hibernate.Query;
 * SharedSessionContract#createQuery moved to
 org.hibernate.query.QueryProducer#createQuery,
 returning  org.hibernate.query.Query (which extends
 org.hibernate.Query);
 (org.hibernate.Session extends QueryProducer);

 In 6.0:
 * org.hibernate.Query was removed.

 Incompatibilities migrating from 5.3 -> 6.0:
 1) Existing applications that

Re: [hibernate-dev] Empty IN list support

2018-02-16 Thread Sanne Grinovero 
Thanks for reminding the JIRA, I see there's quite some people interested in it.

I've added a comment explaining our plans, I guess many are not aware
of our bigger picture.

On 16 February 2018 at 10:57, Bregler, Jonathan
 wrote:
> Ok, thanks. For some reason I missed the Jira issue.
>
> - Jonathan
>
> From: Guillaume Smet [mailto:guillaume.s...@gmail.com]
> Sent: Friday, February 16, 2018 11:39 AM
> To: Vlad Mihalcea 
> Cc: Bregler, Jonathan ; 
> hibernate-dev@lists.jboss.org
> Subject: Re: [hibernate-dev] Empty IN list support
>
> See this related issue: https://hibernate.atlassian.net/browse/HHH-8091
>
> On Fri, Feb 16, 2018 at 11:23 AM, Vlad Mihalcea 
> > wrote:
> I see that we are only using it for testing so that we can skip the:
>
> testEmptyInListQuery
>
> query on certain Dialects.
>
> We could use this info when rendering the JPQL/HQL queries to throw an
> exception before executing the query.
> Nevertheless, an exception will be thrown anyway even if we don't do it.
>
> Vlad
>
> On Fri, Feb 16, 2018 at 11:21 AM, Bregler, Jonathan <
> jonathan.breg...@sap.com> wrote:
>
>> Hi,
>>
>> HANA doesn't support empty IN lists, so executing an HQL query that gets
>> transformed into a SQL query with an empty IN list results in a SQL parser
>> error on the database side. I noticed that the Dialect class already
>> defines a method called "supportsEmptyInList()" which according to the
>> Javadoc returns "True if empty in lists are supported; false otherwise".
>> However, this method doesn't seem to be used anywhere in the Hibernate
>> code. Is there a reason for that?
>>
>> Thanks,
>> Jonathan
>> ___
>> 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 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

Re: [hibernate-dev] Empty IN list support

2018-02-16 Thread Bregler, Jonathan 
Ok, thanks. For some reason I missed the Jira issue.

- Jonathan

From: Guillaume Smet [mailto:guillaume.s...@gmail.com]
Sent: Friday, February 16, 2018 11:39 AM
To: Vlad Mihalcea 
Cc: Bregler, Jonathan ; hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Empty IN list support

See this related issue: https://hibernate.atlassian.net/browse/HHH-8091

On Fri, Feb 16, 2018 at 11:23 AM, Vlad Mihalcea 
> wrote:
I see that we are only using it for testing so that we can skip the:

testEmptyInListQuery

query on certain Dialects.

We could use this info when rendering the JPQL/HQL queries to throw an
exception before executing the query.
Nevertheless, an exception will be thrown anyway even if we don't do it.

Vlad

On Fri, Feb 16, 2018 at 11:21 AM, Bregler, Jonathan <
jonathan.breg...@sap.com> wrote:

> Hi,
>
> HANA doesn't support empty IN lists, so executing an HQL query that gets
> transformed into a SQL query with an empty IN list results in a SQL parser
> error on the database side. I noticed that the Dialect class already
> defines a method called "supportsEmptyInList()" which according to the
> Javadoc returns "True if empty in lists are supported; false otherwise".
> However, this method doesn't seem to be used anywhere in the Hibernate
> code. Is there a reason for that?
>
> Thanks,
> Jonathan
> ___
> 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 mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Empty IN list support

2018-02-16 Thread Guillaume Smet 
See this related issue: https://hibernate.atlassian.net/browse/HHH-8091

On Fri, Feb 16, 2018 at 11:23 AM, Vlad Mihalcea 
wrote:

> I see that we are only using it for testing so that we can skip the:
>
> testEmptyInListQuery
>
> query on certain Dialects.
>
> We could use this info when rendering the JPQL/HQL queries to throw an
> exception before executing the query.
> Nevertheless, an exception will be thrown anyway even if we don't do it.
>
> Vlad
>
> On Fri, Feb 16, 2018 at 11:21 AM, Bregler, Jonathan <
> jonathan.breg...@sap.com> wrote:
>
> > Hi,
> >
> > HANA doesn't support empty IN lists, so executing an HQL query that gets
> > transformed into a SQL query with an empty IN list results in a SQL
> parser
> > error on the database side. I noticed that the Dialect class already
> > defines a method called "supportsEmptyInList()" which according to the
> > Javadoc returns "True if empty in lists are supported; false otherwise".
> > However, this method doesn't seem to be used anywhere in the Hibernate
> > code. Is there a reason for that?
> >
> > Thanks,
> > Jonathan
> > ___
> > 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 mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Empty IN list support

2018-02-16 Thread Vlad Mihalcea 
I see that we are only using it for testing so that we can skip the:

testEmptyInListQuery

query on certain Dialects.

We could use this info when rendering the JPQL/HQL queries to throw an
exception before executing the query.
Nevertheless, an exception will be thrown anyway even if we don't do it.

Vlad

On Fri, Feb 16, 2018 at 11:21 AM, Bregler, Jonathan <
jonathan.breg...@sap.com> wrote:

> Hi,
>
> HANA doesn't support empty IN lists, so executing an HQL query that gets
> transformed into a SQL query with an empty IN list results in a SQL parser
> error on the database side. I noticed that the Dialect class already
> defines a method called "supportsEmptyInList()" which according to the
> Javadoc returns "True if empty in lists are supported; false otherwise".
> However, this method doesn't seem to be used anywhere in the Hibernate
> code. Is there a reason for that?
>
> Thanks,
> Jonathan
> ___
> 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