11:40 a.m.
Thomas Woelfle created AS7-5260:
-----------------------------------
Summary: Synthetic method passed in InvocationContext
Key: AS7-5260
URL: https://issues.jboss.org/browse/AS7-5260
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.2.0.Alpha1
Reporter: Thomas Woelfle
We have a JEE interceptor that validates method calls using the MethodValidator from the
hibernate-validator package. We are running into problems when generic methods on
stateless session beans are called that have been overwritten in a subclass. The problem
is that the InvocationContext passed into our interceptor references the synthetic bridge
method generated by the compiler instead of the correct overwritten method. Synthetic
methods are ignored by hibernate-validator (see BeanMetaDataImpl.initMethodConstraints).
This results in a NullPointerException when hibernate-validator tries to validate the
given synthetic bridge method.
Code example:
public interface CrudService<D extends PersistentElement> {
D elementById(long id);
}
@Local
public interface AccountService extends CrudService<Account> {
... some additional methods
}
public class AbstractCrudServiceImpl<D extends PersistentElement> implements
CrudService<D> {
public D elementById(long id) {
... do something
}
}
@Stateless
public class AccountServiceImpl extends AbstractCrudServiceImpl<Account> implements
AccountService {
@Override
public Account elementById(long id) {
... a specialized implementation
}
}
public class SomeOtherSessionBean {
@Inject
private AccountService accountService;
public void doSomething() {
accountService.elementById(1);
}
}
In the example code above 'SomeOtherSessionBean.doSomething()' calls the method
'elementById'. In that case the InvocationContext passed into our interceptor
references the synthetic bridge method with the signature 'PersistentElement
AccountServiceImpl.elementById(long)' instead of the concrete method 'Account
AccountServiceImpl.elementById(long)'.
This seems to be a bug, isn't it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:46 a.m.
[
https://issues.jboss.org/browse/AS7-5260?page=com.atlassian.jira.plugin.s...
]
jaikiran pai updated AS7-5260:
------------------------------
Assignee: David Lloyd
Affects Version/s: 7.1.2.Final (EAP)
7.1.1.Final
(was: 7.2.0.Alpha1)
Component/s: EE
Forum Reference: https://community.jboss.org/thread/203153 (was:
https://community.jboss.org/thread/203153)
Synthetic method passed in InvocationContext
--------------------------------------------
Key: AS7-5260
URL: https://issues.jboss.org/browse/AS7-5260
Project: Application Server 7
Issue Type: Bug
Components: EE
Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP)
Reporter: Thomas Woelfle
Assignee: David Lloyd
Labels: as7, hibernate_validation, interceptor
We have a JEE interceptor that validates method calls using the MethodValidator from the
hibernate-validator package. We are running into problems when generic methods on
stateless session beans are called that have been overwritten in a subclass. The problem
is that the InvocationContext passed into our interceptor references the synthetic bridge
method generated by the compiler instead of the correct overwritten method. Synthetic
methods are ignored by hibernate-validator (see BeanMetaDataImpl.initMethodConstraints).
This results in a NullPointerException when hibernate-validator tries to validate the
given synthetic bridge method.
Code example:
public interface CrudService<D extends PersistentElement> {
D elementById(long id);
}
@Local
public interface AccountService extends CrudService<Account> {
... some additional methods
}
public class AbstractCrudServiceImpl<D extends PersistentElement> implements
CrudService<D> {
public D elementById(long id) {
... do something
}
}
@Stateless
public class AccountServiceImpl extends AbstractCrudServiceImpl<Account> implements
AccountService {
@Override
public Account elementById(long id) {
... a specialized implementation
}
}
public class SomeOtherSessionBean {
@Inject
private AccountService accountService;
public void doSomething() {
accountService.elementById(1);
}
}
In the example code above 'SomeOtherSessionBean.doSomething()' calls the method
'elementById'. In that case the InvocationContext passed into our interceptor
references the synthetic bridge method with the signature 'PersistentElement
AccountServiceImpl.elementById(long)' instead of the concrete method 'Account
AccountServiceImpl.elementById(long)'.
This seems to be a bug, isn't it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:35 p.m.
[
https://issues.jboss.org/browse/AS7-5260?page=com.atlassian.jira.plugin.s...
]
David Lloyd commented on AS7-5260:
----------------------------------
Synthetic methods are part of Java - I agree that the "real" resolved method
should be the one that is validated, but users can invoke on any method, including
synthetic ones, thus I believe that hibernate-validator has to account for this
possibility. The EJB spec does not say anything which contradicts my conclusion, though
perhaps CDI does?
Synthetic method passed in InvocationContext
--------------------------------------------
Key: AS7-5260
URL: https://issues.jboss.org/browse/AS7-5260
Project: Application Server 7
Issue Type: Bug
Components: EE
Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP)
Reporter: Thomas Woelfle
Assignee: David Lloyd
Labels: as7, hibernate_validation, interceptor
We have a JEE interceptor that validates method calls using the MethodValidator from the
hibernate-validator package. We are running into problems when generic methods on
stateless session beans are called that have been overwritten in a subclass. The problem
is that the InvocationContext passed into our interceptor references the synthetic bridge
method generated by the compiler instead of the correct overwritten method. Synthetic
methods are ignored by hibernate-validator (see BeanMetaDataImpl.initMethodConstraints).
This results in a NullPointerException when hibernate-validator tries to validate the
given synthetic bridge method.
Code example:
public interface CrudService<D extends PersistentElement> {
D elementById(long id);
}
@Local
public interface AccountService extends CrudService<Account> {
... some additional methods
}
public class AbstractCrudServiceImpl<D extends PersistentElement> implements
CrudService<D> {
public D elementById(long id) {
... do something
}
}
@Stateless
public class AccountServiceImpl extends AbstractCrudServiceImpl<Account> implements
AccountService {
@Override
public Account elementById(long id) {
... a specialized implementation
}
}
public class SomeOtherSessionBean {
@Inject
private AccountService accountService;
public void doSomething() {
accountService.elementById(1);
}
}
In the example code above 'SomeOtherSessionBean.doSomething()' calls the method
'elementById'. In that case the InvocationContext passed into our interceptor
references the synthetic bridge method with the signature 'PersistentElement
AccountServiceImpl.elementById(long)' instead of the concrete method 'Account
AccountServiceImpl.elementById(long)'.
This seems to be a bug, isn't it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:51 p.m.
[
https://issues.jboss.org/browse/AS7-5260?page=com.atlassian.jira.plugin.s...
]
David Lloyd commented on AS7-5260:
----------------------------------
We've discussed a two-pronged solution to this problem.
# If the proxy extends a base class, for each bridge method, instead of creating a proxy
method for it, the bridge method bytecode should be copied or inherited, as appropriate
# If the proxy implements interfaces with covariantly overridden methods (due to generics
or whatever), the proxy should generate a bridge method for the overridden method that
calls the most specific method
I believe this would cover all the cases.
Synthetic method passed in InvocationContext
--------------------------------------------
Key: AS7-5260
URL: https://issues.jboss.org/browse/AS7-5260
Project: Application Server 7
Issue Type: Bug
Components: EE
Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP)
Reporter: Thomas Woelfle
Assignee: David Lloyd
Labels: as7, hibernate_validation, interceptor
We have a JEE interceptor that validates method calls using the MethodValidator from the
hibernate-validator package. We are running into problems when generic methods on
stateless session beans are called that have been overwritten in a subclass. The problem
is that the InvocationContext passed into our interceptor references the synthetic bridge
method generated by the compiler instead of the correct overwritten method. Synthetic
methods are ignored by hibernate-validator (see BeanMetaDataImpl.initMethodConstraints).
This results in a NullPointerException when hibernate-validator tries to validate the
given synthetic bridge method.
Code example:
public interface CrudService<D extends PersistentElement> {
D elementById(long id);
}
@Local
public interface AccountService extends CrudService<Account> {
... some additional methods
}
public class AbstractCrudServiceImpl<D extends PersistentElement> implements
CrudService<D> {
public D elementById(long id) {
... do something
}
}
@Stateless
public class AccountServiceImpl extends AbstractCrudServiceImpl<Account> implements
AccountService {
@Override
public Account elementById(long id) {
... a specialized implementation
}
}
public class SomeOtherSessionBean {
@Inject
private AccountService accountService;
public void doSomething() {
accountService.elementById(1);
}
}
In the example code above 'SomeOtherSessionBean.doSomething()' calls the method
'elementById'. In that case the InvocationContext passed into our interceptor
references the synthetic bridge method with the signature 'PersistentElement
AccountServiceImpl.elementById(long)' instead of the concrete method 'Account
AccountServiceImpl.elementById(long)'.
This seems to be a bug, isn't it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:51 p.m.
[
https://issues.jboss.org/browse/AS7-5260?page=com.atlassian.jira.plugin.s...
]
David Lloyd updated AS7-5260:
-----------------------------
Description:
We have a JEE interceptor that validates method calls using the MethodValidator from the
hibernate-validator package. We are running into problems when generic methods on
stateless session beans are called that have been overwritten in a subclass. The problem
is that the InvocationContext passed into our interceptor references the synthetic bridge
method generated by the compiler instead of the correct overwritten method. Synthetic
methods are ignored by hibernate-validator (see BeanMetaDataImpl.initMethodConstraints).
This results in a NullPointerException when hibernate-validator tries to validate the
given synthetic bridge method.
Code example:
{code}
public interface CrudService<D extends PersistentElement> {
D elementById(long id);
}
@Local
public interface AccountService extends CrudService<Account> {
... some additional methods
}
public class AbstractCrudServiceImpl<D extends PersistentElement> implements
CrudService<D> {
public D elementById(long id) {
... do something
}
}
@Stateless
public class AccountServiceImpl extends AbstractCrudServiceImpl<Account> implements
AccountService {
@Override
public Account elementById(long id) {
... a specialized implementation
}
}
public class SomeOtherSessionBean {
@Inject
private AccountService accountService;
public void doSomething() {
accountService.elementById(1);
}
}
{code}
In the example code above 'SomeOtherSessionBean.doSomething()' calls the method
'elementById'. In that case the InvocationContext passed into our interceptor
references the synthetic bridge method with the signature 'PersistentElement
AccountServiceImpl.elementById(long)' instead of the concrete method 'Account
AccountServiceImpl.elementById(long)'.
This seems to be a bug, isn't it?
was:
We have a JEE interceptor that validates method calls using the MethodValidator from the
hibernate-validator package. We are running into problems when generic methods on
stateless session beans are called that have been overwritten in a subclass. The problem
is that the InvocationContext passed into our interceptor references the synthetic bridge
method generated by the compiler instead of the correct overwritten method. Synthetic
methods are ignored by hibernate-validator (see BeanMetaDataImpl.initMethodConstraints).
This results in a NullPointerException when hibernate-validator tries to validate the
given synthetic bridge method.
Code example:
public interface CrudService<D extends PersistentElement> {
D elementById(long id);
}
@Local
public interface AccountService extends CrudService<Account> {
... some additional methods
}
public class AbstractCrudServiceImpl<D extends PersistentElement> implements
CrudService<D> {
public D elementById(long id) {
... do something
}
}
@Stateless
public class AccountServiceImpl extends AbstractCrudServiceImpl<Account> implements
AccountService {
@Override
public Account elementById(long id) {
... a specialized implementation
}
}
public class SomeOtherSessionBean {
@Inject
private AccountService accountService;
public void doSomething() {
accountService.elementById(1);
}
}
In the example code above 'SomeOtherSessionBean.doSomething()' calls the method
'elementById'. In that case the InvocationContext passed into our interceptor
references the synthetic bridge method with the signature 'PersistentElement
AccountServiceImpl.elementById(long)' instead of the concrete method 'Account
AccountServiceImpl.elementById(long)'.
This seems to be a bug, isn't it?
Forum Reference: https://community.jboss.org/thread/203153 (was:
https://community.jboss.org/thread/203153)
Synthetic method passed in InvocationContext
--------------------------------------------
Key: AS7-5260
URL: https://issues.jboss.org/browse/AS7-5260
Project: Application Server 7
Issue Type: Bug
Components: EE
Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP)
Reporter: Thomas Woelfle
Assignee: David Lloyd
Labels: as7, hibernate_validation, interceptor
We have a JEE interceptor that validates method calls using the MethodValidator from the
hibernate-validator package. We are running into problems when generic methods on
stateless session beans are called that have been overwritten in a subclass. The problem
is that the InvocationContext passed into our interceptor references the synthetic bridge
method generated by the compiler instead of the correct overwritten method. Synthetic
methods are ignored by hibernate-validator (see BeanMetaDataImpl.initMethodConstraints).
This results in a NullPointerException when hibernate-validator tries to validate the
given synthetic bridge method.
Code example:
{code}
public interface CrudService<D extends PersistentElement> {
D elementById(long id);
}
@Local
public interface AccountService extends CrudService<Account> {
... some additional methods
}
public class AbstractCrudServiceImpl<D extends PersistentElement> implements
CrudService<D> {
public D elementById(long id) {
... do something
}
}
@Stateless
public class AccountServiceImpl extends AbstractCrudServiceImpl<Account> implements
AccountService {
@Override
public Account elementById(long id) {
... a specialized implementation
}
}
public class SomeOtherSessionBean {
@Inject
private AccountService accountService;
public void doSomething() {
accountService.elementById(1);
}
}
{code}
In the example code above 'SomeOtherSessionBean.doSomething()' calls the method
'elementById'. In that case the InvocationContext passed into our interceptor
references the synthetic bridge method with the signature 'PersistentElement
AccountServiceImpl.elementById(long)' instead of the concrete method 'Account
AccountServiceImpl.elementById(long)'.
This seems to be a bug, isn't it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:37 a.m.
[
https://issues.jboss.org/browse/AS7-5260?page=com.atlassian.jira.plugin.s...
]
Stuart Douglas reassigned AS7-5260:
-----------------------------------
Assignee: Stuart Douglas (was: David Lloyd)
Synthetic method passed in InvocationContext
--------------------------------------------
Key: AS7-5260
URL: https://issues.jboss.org/browse/AS7-5260
Project: Application Server 7
Issue Type: Bug
Components: EE
Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP)
Reporter: Thomas Woelfle
Assignee: Stuart Douglas
Labels: as7, hibernate_validation, interceptor
We have a JEE interceptor that validates method calls using the MethodValidator from the
hibernate-validator package. We are running into problems when generic methods on
stateless session beans are called that have been overwritten in a subclass. The problem
is that the InvocationContext passed into our interceptor references the synthetic bridge
method generated by the compiler instead of the correct overwritten method. Synthetic
methods are ignored by hibernate-validator (see BeanMetaDataImpl.initMethodConstraints).
This results in a NullPointerException when hibernate-validator tries to validate the
given synthetic bridge method.
Code example:
{code}
public interface CrudService<D extends PersistentElement> {
D elementById(long id);
}
@Local
public interface AccountService extends CrudService<Account> {
... some additional methods
}
public class AbstractCrudServiceImpl<D extends PersistentElement> implements
CrudService<D> {
public D elementById(long id) {
... do something
}
}
@Stateless
public class AccountServiceImpl extends AbstractCrudServiceImpl<Account> implements
AccountService {
@Override
public Account elementById(long id) {
... a specialized implementation
}
}
public class SomeOtherSessionBean {
@Inject
private AccountService accountService;
public void doSomething() {
accountService.elementById(1);
}
}
{code}
In the example code above 'SomeOtherSessionBean.doSomething()' calls the method
'elementById'. In that case the InvocationContext passed into our interceptor
references the synthetic bridge method with the signature 'PersistentElement
AccountServiceImpl.elementById(long)' instead of the concrete method 'Account
AccountServiceImpl.elementById(long)'.
This seems to be a bug, isn't it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:26 a.m.
[
https://issues.jboss.org/browse/AS7-5260?page=com.atlassian.jira.plugin.s...
]
Stuart Douglas commented on AS7-5260:
-------------------------------------
This also had some other nasty side effects, such as method level interceptor invocations
could be skipped when a bridge method was invoked.
Synthetic method passed in InvocationContext
--------------------------------------------
Key: AS7-5260
URL: https://issues.jboss.org/browse/AS7-5260
Project: Application Server 7
Issue Type: Bug
Components: EE
Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP)
Reporter: Thomas Woelfle
Assignee: Stuart Douglas
Labels: as7, hibernate_validation, interceptor
We have a JEE interceptor that validates method calls using the MethodValidator from the
hibernate-validator package. We are running into problems when generic methods on
stateless session beans are called that have been overwritten in a subclass. The problem
is that the InvocationContext passed into our interceptor references the synthetic bridge
method generated by the compiler instead of the correct overwritten method. Synthetic
methods are ignored by hibernate-validator (see BeanMetaDataImpl.initMethodConstraints).
This results in a NullPointerException when hibernate-validator tries to validate the
given synthetic bridge method.
Code example:
{code}
public interface CrudService<D extends PersistentElement> {
D elementById(long id);
}
@Local
public interface AccountService extends CrudService<Account> {
... some additional methods
}
public class AbstractCrudServiceImpl<D extends PersistentElement> implements
CrudService<D> {
public D elementById(long id) {
... do something
}
}
@Stateless
public class AccountServiceImpl extends AbstractCrudServiceImpl<Account> implements
AccountService {
@Override
public Account elementById(long id) {
... a specialized implementation
}
}
public class SomeOtherSessionBean {
@Inject
private AccountService accountService;
public void doSomething() {
accountService.elementById(1);
}
}
{code}
In the example code above 'SomeOtherSessionBean.doSomething()' calls the method
'elementById'. In that case the InvocationContext passed into our interceptor
references the synthetic bridge method with the signature 'PersistentElement
AccountServiceImpl.elementById(long)' instead of the concrete method 'Account
AccountServiceImpl.elementById(long)'.
This seems to be a bug, isn't it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4341
days inactive
4352
days old
6 comments
4 participants
participants (4)
-
David Lloyd (JIRA) -
jaikiran pai (JIRA)
-
Stuart Douglas (JIRA)
-
Thomas Woelfle (JIRA)