Also I wanted to clarify that, as I told you on IRC, I am fine to change
this expectation if that is the general consensus as long as it is all done
by next Wednesday. I know that sounds short notice, but in reality I have
been trying to ping you about that for weeks.
However, even given that the Pull Request is only partial:
1) it moves exposing some internal types to an API/SPI method. IMO the
Pull Request should be complete and fix that as well.
2) there is code in ORM that casts to EntityManagerFactoryImpl in order to
access these methods, no?. unless I missed it, you did not fix those
usages to now refer to HibernateEntityManagerFactory.
On Fri, Apr 24, 2015 at 1:53 PM, Hardy Ferentschik <hardy(a)hibernate.org>
wrote:
Hi there,
Steve and I are having a discussion around the intended behavior of
EntityManagerFactory#unwrap.
See also HHH-9665[1] and the corresponding pull request [2].
At the moment the implementation in EntityManagerFactoryImpl allows to
unwrap into the implementation
class itself. This way the user gets a reference to an internal class. IMO
there should be instead a
public interface which the user can unwrap to, eg
HibernateEntityManagerFactory. This interface hosts
additional methods we want to expose on top of the
HibernateEntityManagerFactory. The unwrapping to
should be disallowed (by expception) in this case. IMO this is just a
continuation of the whole
idea of splitting packages between public, spi and internal. Of course
this cannot stop a user from
doing an explicit cast, but that's a different story imo.
Steve and I have different take on this issue, so we where wondering what
others think?
--Hardy
[1]
https://hibernate.atlassian.net/browse/HHH-9665
[2]
https://github.com/hibernate/hibernate-orm/pull/911
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev