[
https://issues.apache.org/jira/browse/TAP5-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002655#comment-16002655
]
Thomas Mayer edited comment on TAP5-2582 at 5/9/17 1:51 PM:
------------------------------------------------------------
I looked up the sources of Hibernate's Session interface:
{code:java}
public interface Session extends SharedSessionContract, EntityManager,
HibernateEntityManager, AutoCloseable {
{code}
There is to say that
- SharedSessionContract defines a void close() function.
- EntityManager defines a void close() function
- HibernateEntityManager extends EntityManager (which has a void close()
function)
- AutoCloseable defines a void close() function
That said, there's three resulting void close() functions which are
defined independently from each other in the interfaces which the
Session interface extends.
I could imagine that this somehow confuses Tapestry-IoC upon service
creation.
However, we deal with function signatures of _interfaces_. Now that
these interfaces only _require_ the existence of a function in the later
created object, I guess it does not matter which interfaces' close()
function "wins" the race.
_If_ the origin of the whole issue really is because of these close()
functions from multiple interfaces, then there's a limitation in
Tapestry: It's a normal use case which Tapestry should cover.
was (Author: thomas303):
I looked up the sources of Hibernate's Session interface:
{code:java}
public interface Session extends SharedSessionContract, EntityManager,
HibernateEntityManager, AutoCloseable {
{code}
There is to say that
- SharedSessionContract defines a void close() function.
- EntityManager defines a void close() function
- HibernateEntityManager
- extends EntityManager (which has a void close() function)
- AutoCloseable defines a void close() function
That said, there's three resulting void close() functions which are
defined independently from each other in the interfaces which the
Session interface extends.
I could imagine that this somehow confuses Tapestry-IoC upon service
creation.
However, we deal with function signatures of _interfaces_. Now that
these interfaces only _require_ the existence of a function in the later
created object, I guess it does not matter which interfaces' close()
function "wins" the race.
_If_ the origin of the whole issue really is because of these close()
functions from multiple interfaces, then there's a limitation in
Tapestry: It's a normal use case which Tapestry should cover.
> Service creation for Hibernate Session results in ClassFormatError: Duplicate
> method name&signature
> ---------------------------------------------------------------------------------------------------
>
> Key: TAP5-2582
> URL: https://issues.apache.org/jira/browse/TAP5-2582
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-ioc
> Affects Versions: 5.4.3
> Reporter: Thomas Mayer
> Labels: duplicate,method, hibernate, interface, ioc
>
> Hi, this report is for
> tapestry-ioc 5.4.3
> hibernate-core 5.2.10.Final
> openjdk version "1.8.0_121"
> OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-0ubuntu1.16.04.2-b13)
> OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)
> I'm trying to have a Service for a hibernate Session:
> {code:java}
> public static Session buildHibernateSession(
> ObjectLocator objectLocator
> ) {
> return new Configuration()
> .configure("hibernate.cfg.xml")
> .buildSessionFactory()
> .openSession();
> }
> {code}
> As soon as the Hibernate Session is invoked by Tapestry-IOC, I get an
> error: java.lang.ClassFormatError: Duplicate method name&signature in
> class file $Session_350f95bde0b5
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
