[
https://issues.jboss.org/browse/WFLY-9592?page=com.atlassian.jira.plugin....
]
Marcus Handte commented on WFLY-9592:
-------------------------------------
Ok, I have done some more testing with Wildfly-11.0.0.Final and again with
Wildfly-10.1.0.Final just to double check that I am not making this up. You were right,
Wildfly-11.0.0.Final does not have the problem with arrays anymore. On
Wildfly-10.1.0.Final I am certain that the problem is solely caused by having an array in
the parameter list of an accessible (and @PermitAll) session bean method:
java.lang.AssertionError: Should not receive exception. expected null, but
was:<javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public
com.maptology.api.user.User
com.maptology.service.session.UserSessionBean.registerUser(com.maptology.api.user.UserRegistration,com.maptology.api.access.Roles[],long)
throws com.maptology.service.entity.EntityConflictException of bean: UserSessionBean is
not allowed>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotNull(Assert.java:755)
at org.junit.Assert.assertNull(Assert.java:737)
at
com.maptology.service.test.session.UserSessionTest.testRegisterAndEmailVerify(UserSessionTest.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
If I change Roles[] to List<Roles>, everything works as expected (meaning that I do
not get an EJBAccessException anymore9.
Arrays in Method Parameters are causing EJBAccessException for
@PermitAll Methods
---------------------------------------------------------------------------------
Key: WFLY-9592
URL:
https://issues.jboss.org/browse/WFLY-9592
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.1.0.Final
Environment: Wildfly 10.1.0.Final in an Arquillian Managed Container Test
Reporter: Marcus Handte
Priority: Minor
EJB methods with array parameters are causing EJBAccessExceptions when they are annotated
with @PermitAll. This bug seemed to be present in 8.0.0.Alpha2 and was fixed (see
WFLY-1658). But it seems to be present again in 10.1.0.Final.
For my own use case, this is not a problem since I can simply change the method
signatures to use lists instead of arrays. However, I can imagine that this could be a
more significant problem for people trying to run existing code that they do not want to
(or cannot) touch.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)