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

[Bartosz Baranowski (JIRA)]

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

Bartosz Baranowski commented on WFLY-10280:
-------------------------------------------

{quote}
What exactly do you find confusing?
{quote}
This suplier/capability provider, funcitonal service, some sort of composite dependency and factories makes it harder to follow. Instead of clear deps its a bit obfuscated picture that is being drawn in code. Not to mention capability org.wildfly.clustering.cache.registry-entry.ejb.client-mappings being reigstered in ejb=remote tree. I get it can be done like this, but as is I fail to see why, possibly Im missing something.


Ok [~pferraro] so what is the angle on this. 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 )




> 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)