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 <coladict(a)gmail.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

Would we be interested? Heck yeah. We have just not put in the effort because it is used for such a small subset of features *and* we plan to not use DOM/SAX directly moving forward (we are transitioning to JAXB). All that said though, I am surprised you ran into so few problems. Envers e.g. makes extensive use of DOM4J. On Fri, Feb 16, 2018 at 4:29 PM Jordan Gigov <coladict(a)gmail.com&gt; wrote: > 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 <sanne(a)hibernate.org&gt; > 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 <coladict(a)gmail.com&gt; 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(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

On Sun, Feb 18, 2018 at 4:52 AM Jordan Gigov <coladict(a)gmail.com&gt; wrote: > I think transitioning to automatic bindings via JAXB will result in error > messages on wrong configurations becoming far too vague to be useful to the > users. > I'm not understanding... we've used jaxb since 4.0 I am just talking about envers and how it integrates with hibernate-core. At the moment it directly uses dom4j - we'd like to eventualy have it use the jaxb model instead

Well, it took longer than expected as the source of the failures became more obscure, but here it is, done on the master (5.3) branch. https://github.com/coladict/hibernate-orm/tree/dom4j-removal It's in the dom4j-removal branch. The tests for entity-mode dom4j have been removed, but it might be a better idea to write new ones that expect an error. Also the hibernate-mapping-4.0.xsd schema hasn't been valid since dom4j entity-mode was removed in 2011 (4a4f636caf9ecc62fe0d230f422ad3eab2517db0) but I haven't touched it. You could wait for 6.0, but there is time to review this for 5.3.

I have only passed a `clean build` using JDK8 and the default H2 database. Maybe other databases could expose errors, but it's highly unlikely. JDK9 is a bit more likely to expose an incompatibility. On 19 February 2018 at 17:03, Chris Cranford <chris(a)hibernate.org <mailto:chris@hibernate.org>> wrote: See below On 02/18/2018 11:38 AM, Steve Ebersole wrote: > On Sun, Feb 18, 2018 at 4:52 AM Jordan Gigov <coladict(a)gmail.com <mailto:coladict@gmail.com>> wrote: > >> I think transitioning to automatic bindings via JAXB will result in error >> messages on wrong configurations becoming far too vague to be useful to the >> users. >> > I'm not understanding... we've used jaxb since 4.0 > > I am just talking about envers and how it integrates with hibernate-core. > At the moment it directly uses dom4j - we'd like to eventualy have it use > the jaxb model instead There is a JIRA [1] that specifically targets this work from an Envers perspective.  I have a working implementation based on Hibernate 5.x but this is planned to be integrated in Hibernate 6.  I'd expect to see this get integrated once we get a bit more development finalized around Hibernate Core in 6. [1]: https://hibernate.atlassian.net/browse/HHH-11483 <https://hibernate.atlassian.net/browse/HHH-11483> Thanks, Chris