Kotlin EJB con interfaz Java arroja UndeclanetworkingThrowableException

Interfaz de Java:

public interface IUserSettingManager { UserSettingApi updateSetting(Long userId, UserSetting userSettingNew) throws FailUpdateUserSettingException; } 

Kotlin ejb:

 @Stateless @Local(IUserSettingManager::class) open class UserSettingManager : DataManager(), IUserSettingManager { private companion object { private val LOG = LoggerFactory.getLogger(UserSettingManager::class.java) } @Throws(FailUpdateUserSettingException::class) private fun validate(userSetting: UserSetting) { if (userSetting.avatar?.length ?: 0 > DBConstant.UUID_VARCHAR_SIZE) { throw FailUpdateUserSettingException("avatar length") } } @Throws(FailUpdateUserSettingException::class) override fun updateSetting(userId: Long, userSettingNew: UserSetting): UserSettingApi { val logger = LOG.silentEnter("updateSetting") try { validate(userSettingNew) ..... } catch (ex: Exception) { val msg = "userId:$userId, user setting:$userSettingNew" when (ex) { is FailUpdateUserSettingException -> { logger.debug("$msg, ex:$ex") throw ex } else -> { logger.error(msg, ex) throw FailUpdateUserSettingException(ex.toString()) } } } } } 

Clase Java con exception:

la class pública FailUpdateUserSettingException extends Exception {

  public FailUpdateUserSettingException() { this(error); } 

}

Cuando intente invocar ejb con datos incorrectos, obtenga la exception UndeclanetworkingThrowableException, y como resultado la transacción se lance

 Caused by: java.lang.reflect.UndeclanetworkingThrowableException at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:34) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] ... 137 more Caused by: com.pay.utils.shanetworking.exception.user.FailUpdateUserSettingException: Fail update user setting. avatar length at com.pay.manager.UserSettingManager.validate(UserSettingManager.kt:xx) at com.pay.manager.UserSettingManager.updateSetting(UserSettingManager.kt:xx) at com.pay.manager.UserSettingManager.updateSetting(UserSettingManager.kt:xx) ..... 

resultado

javax.ejb.EJBTransactionRolledbackException

No veo ninguna invocación remota de methods ni serialization, que son causas comunes de este tipo de problema, pero ¿podría ser un problema de carga de classs? ¿Que la class cuando se crea una instancia mediante el código de Kotlin se carga desde un cargador de classs diferente, que la class que comtesting JBoss, y que, por lo tanto, se considera un throwable no reconocido?

No estoy seguro de cómo verificarlo. La política del cargador de classs en el contenedor EJB quizás: ¿padre primero frente padre primero?

¿Cuál es el comportamiento si reemplaza el código de Kotlin con una versión de Java que siempre arrojará esa exception desde el método privado validate (), solo para ver si eso hace la diferencia?

¿Qué versión de JDK, qué versión de Kotlin y qué versión de JBoss usa?