[JBoss JIRA] (ELY-1944) The org.wildfly.security:wildfly-elytron artefact incorrectly contains the Elytron CDI extension
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1944?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated ELY-1944:
----------------------------------
Fix Version/s: (was: 1.12.0.CR1)
> The org.wildfly.security:wildfly-elytron artefact incorrectly contains the Elytron CDI extension
> ------------------------------------------------------------------------------------------------
>
> Key: ELY-1944
> URL: https://issues.redhat.com/browse/ELY-1944
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.10.6.CR1, 1.11.3.CR1
>
>
> This means if the artefact is included in a deployment the JWT activation is incorrectly triggered but with some dependencies missing leading to an error such as the following.
> {code}
> 09:46:44,391 WARN [org.jboss.modules.define] (MSC service thread 1-1) Failed to define class org.wildfly.security.mp.jwt.JWTCDIExtension in Module "deployment.XXXX.ear" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link org/wildfly/security/mp/jwt/JWTCDIExtension (Module "deployment.XXXX.ear" from Service Module Loader): io/smallrye/jwt/auth/cdi/SmallRyeJWTAuthCDIExtension
> at java.lang.ClassLoader.defineClass1(ClassLoader.java)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13009) moduleAvailability message is sent before module has started
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFLY-13009?page=com.atlassian.jira.plugi... ]
Ingo Weiss updated WFLY-13009:
------------------------------
Fix Version/s: 19.0.0.Final
> moduleAvailability message is sent before module has started
> ------------------------------------------------------------
>
> Key: WFLY-13009
> URL: https://issues.redhat.com/browse/WFLY-13009
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 19.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 19.0.0.Final
>
>
> When EJBs are deployed in a clustered server environment, moduleAvailability messages are sent from the server to all connected EJB client applications in order to inform the client that the module is available on that node.
> The sending of moduleAvailability messages involves the DeploymentRepository, which records which modules are deployed, and the ModuleAvailabilityListener, which is a DeploymentRepositoryListener which gets called at various stages of module deployment (adding, starting, stopping).
> It looks as though moduleAvailability message are being sent earlier than they should be; in other words, sent when the module is added to the repository and not when the module is later started. This can cause client invocations on the module to return a NoSuchEJBException even after the moduleAvailability message has been sent to the client, causing what is seen in EJBCLIENT-362.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13009) moduleAvailability message is sent before module has started
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13009?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz commented on WFLY-13009:
--------------------------------------------
Hi Ingo
It was merged on 29 January (see
https://github.com/wildfly/wildfly/pull/12941 ) and is in Wildfly 19.
Richard
> moduleAvailability message is sent before module has started
> ------------------------------------------------------------
>
> Key: WFLY-13009
> URL: https://issues.redhat.com/browse/WFLY-13009
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 19.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
>
> When EJBs are deployed in a clustered server environment, moduleAvailability messages are sent from the server to all connected EJB client applications in order to inform the client that the module is available on that node.
> The sending of moduleAvailability messages involves the DeploymentRepository, which records which modules are deployed, and the ModuleAvailabilityListener, which is a DeploymentRepositoryListener which gets called at various stages of module deployment (adding, starting, stopping).
> It looks as though moduleAvailability message are being sent earlier than they should be; in other words, sent when the module is added to the repository and not when the module is later started. This can cause client invocations on the module to return a NoSuchEJBException even after the moduleAvailability message has been sent to the client, causing what is seen in EJBCLIENT-362.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13009) moduleAvailability message is sent before module has started
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFLY-13009?page=com.atlassian.jira.plugi... ]
Ingo Weiss commented on WFLY-13009:
-----------------------------------
Hi [~rachmato], does WildFly 19 have this fix?
> moduleAvailability message is sent before module has started
> ------------------------------------------------------------
>
> Key: WFLY-13009
> URL: https://issues.redhat.com/browse/WFLY-13009
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 19.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
>
> When EJBs are deployed in a clustered server environment, moduleAvailability messages are sent from the server to all connected EJB client applications in order to inform the client that the module is available on that node.
> The sending of moduleAvailability messages involves the DeploymentRepository, which records which modules are deployed, and the ModuleAvailabilityListener, which is a DeploymentRepositoryListener which gets called at various stages of module deployment (adding, starting, stopping).
> It looks as though moduleAvailability message are being sent earlier than they should be; in other words, sent when the module is added to the repository and not when the module is later started. This can cause client invocations on the module to return a NoSuchEJBException even after the moduleAvailability message has been sent to the client, causing what is seen in EJBCLIENT-362.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-10137) EJB lookup over HTTP fails if object is used in the signiture
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-10137?page=com.atlassian.jira.plugi... ]
Parul Sharma commented on WFLY-10137:
-------------------------------------
[~crazycradd] is this particularly failed for swing client with Integer[] in input parameter?
> EJB lookup over HTTP fails if object is used in the signiture
> -------------------------------------------------------------
>
> Key: WFLY-10137
> URL: https://issues.redhat.com/browse/WFLY-10137
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 11.0.0.Final
> Reporter: peter craddock
> Assignee: Parul Sharma
> Priority: Major
>
> I have a swing client that makes calls to the EJB tier via RMI the majority of the calls work fine using the workaround from WFLY-9636.
> The following calls was failing when connected over HTTP but was fine when using the original TCP connection
> public EntityList getAllWorkingSetsForCube( ModelRef modelRef, FinanceCubeRef financeCubeRef, int userId, Integer[] allowedStates )
> I worked round this and found that creating a method without the Integer[] as part of the signature works.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5193) Implement Listener mechanism to trace execution
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-5193:
----------------------------------------
Summary: Implement Listener mechanism to trace execution
Key: DROOLS-5193
URL: https://issues.redhat.com/browse/DROOLS-5193
Project: Drools
Issue Type: Task
Reporter: Gabriele Cardosi
Assignee: Gabriele Cardosi
Implement Listener architecture so that model-implementation may "publish" execution step detail to be read by "listening" code.
Implementation should not be mandatory, i.e. model should not be forced to implement it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13277) Reduce latency of synchronous remote cache operations
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-13277:
-----------------------------------
Summary: Reduce latency of synchronous remote cache operations
Key: WFLY-13277
URL: https://issues.redhat.com/browse/WFLY-13277
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 19.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Switching the default JGroups bundler_type to no-bundler appears to reduce the latency for synchronous cache operations, in particular, during a topology change. This should have the effect of stabilizing many intermittent clustering testsuite failures, especially the singleton service/deployment tests.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month