[
https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin...
]
Paul Ferraro commented on WFLY-10280:
-------------------------------------
{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/jbo...
{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)