[jboss-jira] [JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed

[Paul Ferraro (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13595845#comment-13595845 ] 

Paul Ferraro edited comment on WFLY-10280 at 6/23/18 8:32 AM:
--------------------------------------------------------------

{quote}This suplier/capability provider, funcitonal service, some sort of composite dependency and factories makes it harder to follow.{quote}
I still don't understand to which code you are referring - or why you find it inherently confusing. Do you have an example?

{quote}Not to mention capability org.wildfly.clustering.cache.registry-entry.ejb.client-mappings being reigstered in ejb=remote tree.{quote}
There is no capability named "org.wildfly.clustering.cache.registry-entry.ejb.client-mappings".  The /subsystem=ejb3/service=remote resource only registers 1 capability, named "org.wildfly.ejb.remote".
See: https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3RemoteResourceDefinition.java#L119

{quote}Should remote stay as a required dep or can for instance clustering provide stub service that can run in place of remoting?( just got up, so I have no idea how it works ){quote}
Remoting only uses org.wildfly.clustering.ejb.AffinitySupport, which org.jboss.as.ejb3.cache.Cache (used for SFSB passivation) currently extends.  This is the root of the problem.  We need to decouple these interfaces and their implementations.


was (Author: pferraro):
{quote}This suplier/capability provider, funcitonal service, some sort of composite dependency and factories makes it harder to follow.{quote}
I still don't understand to which code you are referring - or why you find it inherently confusing. Do you have an example?

{quote}Not to mention capability org.wildfly.clustering.cache.registry-entry.ejb.client-mappings being reigstered in ejb=remote tree{quote}.
There is no capability named "org.wildfly.clustering.cache.registry-entry.ejb.client-mappings".  The /subsystem=ejb3/service=remote resource only registers 1 capability, named "org.wildfly.ejb.remote".
See: https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3RemoteResourceDefinition.java#L119

{quote}Should remote stay as a required dep or can for instance clustering provide stub service that can run in place of remoting?( just got up, so I have no idea how it works ){quote}
Remoting only uses org.wildfly.clustering.ejb.AffinitySupport, which org.jboss.as.ejb3.cache.Cache (used for SFSB passivation) currently extends.  This is the root of the problem.  We need to decouple these interfaces and their implementations.

> Can't enable stateful EJB passivation when EJB remote service is removed
> ------------------------------------------------------------------------
>
>                 Key: WFLY-10280
>                 URL: https://issues.jboss.org/browse/WFLY-10280
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB
>    Affects Versions: 12.0.0.Final
>            Reporter: Ladislav Thon
>            Assignee: Bartosz Baranowski
>         Attachments: tinyEjbPassivation.war
>
>
> In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug.
> What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default).
> When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry:
> {code}
> 17:16:37,216 INFO  [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184:    New missing/unsatisfied dependencies:
>       service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache] 
>       service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService] 
>       service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START] 
>       service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService] 
>       service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager] 
>       service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings] 
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)