[JBoss JIRA] (WFLY-6863) Excluded contexts which are not specific to a host should be excluded on all hosts
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6863?page=com.atlassian.jira.plugin.... ]
Radoslav Husar resolved WFLY-6863.
----------------------------------
Fix Version/s: 11.0.0.Alpha1
Resolution: Done
> Excluded contexts which are not specific to a host should be excluded on all hosts
> ----------------------------------------------------------------------------------
>
> Key: WFLY-6863
> URL: https://issues.jboss.org/browse/WFLY-6863
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Tomcat8 (haven't tried elsewhere yet); mod_cluster version 2.0.0.Alpha1-SNAPSHOT
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> With the following configuration:
> {code}
> <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener"
> loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric"
> loadMetricCapacity="1"
> loadHistory="9"
> loadDecayFactor="2"
> stickySession="true"
> stickySessionForce="false"
> stickySessionRemove="true"
> advertise="true"
> advertiseGroupAddress="224.0.1.105"
> advertisePort="23364"
> advertiseInterface="10.40.4.50"
> excludedContexts="ROOT,docs,manager,host-manager,examples"
> />
> {code}
> And these contexts in webapps:
> {code}
> clusterbench docs examples host-manager manager ROOT
> {code}
> One expects this output on Mod_cluster manger console:
> {code}
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> It works, unless you configure additional VirtualHosts:
> {code}
> <Host name="LOCALHOST" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>LOCALHOST</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="localhost_access_log" suffix=".txt"
> pattern="%h %l %u %t "%r" %s %b" />
> </Host>
> <Host name="KARM.BRQ.REDHAT.COM" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>KARM.BRQ.REDHAT.COM</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="localhost_access_log" suffix=".txt"
> pattern="%h %l %u %t "%r" %s %b" />
> </Host>
> {code}
> result:
> {code}
> Node worker1 (ajp://10.40.4.50:8009):
> Enable Contexts Disable Contexts Stop Contexts
> Balancer: mycluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 100
> Virtual Host 2:
> Contexts:
> /docs, Status: ENABLED Request: 0 Disable Stop
> /manager, Status: ENABLED Request: 0 Disable Stop
> /host-manager, Status: ENABLED Request: 0 Disable Stop
> /examples, Status: ENABLED Request: 0 Disable Stop
> /, Status: ENABLED Request: 0 Disable Stop
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> karm.brq.redhat.com
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> I find this bug being of Critical priority, because it could coax users into believing they excluded certain context while in fact they didn't.
> WDYT? Is it possible to tweak with the Listener's configuration somehow?
> THX.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1227) Drools cannot be configured to expire Events properly
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1227?page=com.atlassian.jira.plugi... ]
Mario Fusco reopened DROOLS-1227:
---------------------------------
Documentation is indeed correct and it seems that the current implementation is no longer following it. I'll further check this issue. Thanks for having clarified it.
> Drools cannot be configured to expire Events properly
> -----------------------------------------------------
>
> Key: DROOLS-1227
> URL: https://issues.jboss.org/browse/DROOLS-1227
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.2.0.Final
> Environment: Windows, Java SE 1.8
> Reporter: Cristobal Arellano
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: expire_without_temporal_constraint.drl
>
>
> Hello,
> I want to configure Drools (CEP) to expire events when no longer needed. There are two scenarios:
> ==SCENARIO A==
> I configured Event with no explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is automatically calculated based on the constrains. If there is a rule with no temporal constraints, the expiration is INFINITE. The following example shows the scenario:
> dialect "mvel"
> declare Event
> @role(event)
> end
> rule "ExampleRule1"
> when
> ( $a : Event(name == "event a")
> then
> System.out.println("ExampleRule1Triggered");
> end
> rule "ExampleRule2"
> when
> ( $a : Event(name == "event a") ) and
> ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
> then
> System.out.println("ExampleRule2Triggered");
> end
> With the previous Event definition:
> * If only ExampleRule1 loaded, expires INFINITE. Expected expires 0. ERROR?
> * If ExampleRule1 loaded and ExampleRule2 loaded, expires 15s. Expected expires 15. OK!
> To solve this situation a tried the following scenario:
> == SCENARIO B==
> I configured Event with explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is not taken into account because it is overriden by the explicit expires. The following example shows the scenario:
> dialect "mvel"
> declare Event
> @role(event)
> @expires(0s)
> end
> rule "ExampleRule1"
> when
> ( $a : Event(name == "event a")
> then
> System.out.println("ExampleRule1Triggered");
> end
> rule "ExampleRule2"
> when
> ( $a : Event(name == "event a") ) and
> ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
> then
> System.out.println("ExampleRule2Triggered");
> end
> With the previous Event definition:
> * ExampleRule1 is triggered and event removed. OK!
> * ExampleRule2 is not triggered inserting two events because the first one expires. ERROR?
> I suppose that SCENARIO B is not factible because explicit expires overrides implicit expires (according to issue DROOLS-586).
> Could you please help me to solve this situation? Should Drools set inferred expiration time to 1ms when there are rules with no temporal constraints?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-411) Syntax error when applying patch and exiting jboss-cli
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-411?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise closed WFCORE-411.
---------------------------------------
Resolution: Duplicate Issue
> Syntax error when applying patch and exiting jboss-cli
> ------------------------------------------------------
>
> Key: WFCORE-411
> URL: https://issues.jboss.org/browse/WFCORE-411
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Patching
> Reporter: Arun Gupta
> Assignee: Alexey Loubyansky
>
> [disconnected /] patch apply
> ../wildfly-8.1.0.Final-update/wildfly-8.1.0.Final.patch
> {
> "outcome" : "success",
> "result" : {}
> }
> [disconnected /]
> [disconnected /]
> [disconnected /]
> [disconnected /] exit
> logging.configuration already set in JAVA_OPTS
> ./bin/jboss-cli.sh: line 81: syntax error near unexpected token `fi'
> ./bin/jboss-cli.sh: line 81: `fi'
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-411) Syntax error when applying patch and exiting jboss-cli
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-411?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise commented on WFCORE-411:
---------------------------------------------
The linked issue address all platforms.
> Syntax error when applying patch and exiting jboss-cli
> ------------------------------------------------------
>
> Key: WFCORE-411
> URL: https://issues.jboss.org/browse/WFCORE-411
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Patching
> Reporter: Arun Gupta
> Assignee: Alexey Loubyansky
>
> [disconnected /] patch apply
> ../wildfly-8.1.0.Final-update/wildfly-8.1.0.Final.patch
> {
> "outcome" : "success",
> "result" : {}
> }
> [disconnected /]
> [disconnected /]
> [disconnected /]
> [disconnected /] exit
> logging.configuration already set in JAVA_OPTS
> ./bin/jboss-cli.sh: line 81: syntax error near unexpected token `fi'
> ./bin/jboss-cli.sh: line 81: `fi'
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8313) Using own CustomRealm, CustomModificationRealm and CustomRealmMapper implementation leads to AbstractMethodError.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-8313?page=com.atlassian.jira.plugin.... ]
Hynek Švábek updated WFLY-8313:
-------------------------------
Steps to Reproduce:
*Add user and group*
./bin/add-user.sh -u duke -p password1 -g JBossAdmin -a
*Add new modules with custom implementation*
./bin/jboss-cli.sh
{code}
embed-server
module add --name=org.jboss.custommodifiablerealmimpl --dependencies=org.wildfly.extension.elytron,org.wildfly.security.elytron --resources=/tmp/custommodifiablerealmimpl.jar
module add --name=org.jboss.customrealmimpl --dependencies=org.wildfly.extension.elytron,org.wildfly.security.elytron --resources=/tmp/customrealmimpl.jar
module add --name=org.jboss.customrealmmapperimpl --dependencies=org.wildfly.extension.elytron,org.wildfly.security.elytron --resources=/tmp/customrealmmapperimpl.jar
stop-embedded-server
{code}
*Deploy test application*
Copy attached war file print-roles.war to JBOSS_HOME/standalone/deployments
*Copy configuration files from attachment to your server*
standalone-full.custommodifiablerealmimpl.xml, standalone-full.customrealmimpl.xml, standalone-full.customrealmmapperimpl.xml
*Run server with given configuration - Elytron is set*
{code}
./bin/standalone.sh -c=standalone-full.custommodifiablerealmimpl.xml
{code}
{code}
./bin/standalone.sh -c=standalone-full.customrealmimpl.xml
{code}
{code}
./bin/standalone.sh -c=standalone-full.customrealmmapperimpl.xml
{code}
*Invoke test app (if necessary)*
http://127.0.0.1:8080/print-roles/protected/printRoles?role=JBossAdmin
Now you can see error message about AbstractMethodError.
For example:
{code}
java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomModifiableRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract
{code}
Whole stack trace
{code:collapse=true}
2017-03-07 15:19:58,926 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 68) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:84)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract
at org.wildfly.extras.creaper.commands.elytron.realm.AddCustomRealmImpl.getEvidenceVerifySupport(AddCustomRealmImpl.java)
at org.wildfly.security.auth.server.SecurityDomain.lambda$getEvidenceVerifySupport$12(SecurityDomain.java:457)
at org.wildfly.security.auth.server.SecurityDomain.getSupportLevel(SecurityDomain.java:484)
at org.wildfly.security.auth.server.SecurityDomain.getEvidenceVerifySupport(SecurityDomain.java:455)
at org.wildfly.security.auth.server.SecurityDomain.getEvidenceVerifySupport(SecurityDomain.java:473)
at org.wildfly.security.auth.server.AbstractMechanismAuthenticationFactory.getMechanismNames(AbstractMechanismAuthenticationFactory.java:96)
at org.wildfly.security.auth.server.HttpAuthenticationFactory.getMechanismNames(HttpAuthenticationFactory.java:50)
at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:461)
at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$2(ApplicationSecurityDomainDefinition.java:425)
at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:415)
at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:211)
at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
... 6 more
2017-03-07 15:19:58,931 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "print-roles.war")]) - failure description: {
"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./print-roles" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract
Caused by: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract"},
"WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"]
}
{code}
was:
*Add user and group*
./bin/add-user.sh -u duke -p password1 -g JBossAdmin -a
*Add new modules with custom implementation*
./bin/jboss-cli.sh
{code}
embed-server
module add --name=org.jboss.custommodifiablerealmimpl --dependencies=org.wildfly.extension.elytron,org.wildfly.security.elytron --resources=/tmp/custommodifiablerealmimpl.jar
module add --name=org.jboss.customrealmimpl --dependencies=org.wildfly.extension.elytron,org.wildfly.security.elytron --resources=/tmp/customrealmimpl.jar
module add --name=org.jboss.customrealmmapperimpl --dependencies=org.wildfly.extension.elytron,org.wildfly.security.elytron --resources=/tmp/customrealmmapperimpl.jar
stop-embedded-server
{code}
*Deploy test application*
Copy attached war file print-roles.war to JBOSS_HOME/standalone/deployments
*Run server with given configuration - Elytron is set*
{code}
./bin/standalone.sh -c=standalone-full.custommodifiablerealmimpl.xml
{code}
{code}
./bin/standalone.sh -c=standalone-full.customrealmimpl.xml
{code}
{code}
./bin/standalone.sh -c=standalone-full.customrealmmapperimpl.xml
{code}
*Invoke test app (if necessary)*
http://127.0.0.1:8080/print-roles/protected/printRoles?role=JBossAdmin
Now you can see error message about AbstractMethodError.
For example:
{code}
java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomModifiableRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract
{code}
Whole stack trace
{code:collapse=true}
2017-03-07 15:19:58,926 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 68) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:84)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract
at org.wildfly.extras.creaper.commands.elytron.realm.AddCustomRealmImpl.getEvidenceVerifySupport(AddCustomRealmImpl.java)
at org.wildfly.security.auth.server.SecurityDomain.lambda$getEvidenceVerifySupport$12(SecurityDomain.java:457)
at org.wildfly.security.auth.server.SecurityDomain.getSupportLevel(SecurityDomain.java:484)
at org.wildfly.security.auth.server.SecurityDomain.getEvidenceVerifySupport(SecurityDomain.java:455)
at org.wildfly.security.auth.server.SecurityDomain.getEvidenceVerifySupport(SecurityDomain.java:473)
at org.wildfly.security.auth.server.AbstractMechanismAuthenticationFactory.getMechanismNames(AbstractMechanismAuthenticationFactory.java:96)
at org.wildfly.security.auth.server.HttpAuthenticationFactory.getMechanismNames(HttpAuthenticationFactory.java:50)
at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:461)
at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$2(ApplicationSecurityDomainDefinition.java:425)
at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:415)
at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:211)
at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
... 6 more
2017-03-07 15:19:58,931 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "print-roles.war")]) - failure description: {
"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./print-roles" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract
Caused by: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract"},
"WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"]
}
{code}
> Using own CustomRealm, CustomModificationRealm and CustomRealmMapper implementation leads to AbstractMethodError.
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8313
> URL: https://issues.jboss.org/browse/WFLY-8313
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Using own CustomRealm, CustomModifiableRealm and CustomRealmMapper implementation leads to AbstractMethodError.
> I tried create my own implementation, set up server to use it but I get error message about AbstractMethodError.
> You can see bellow how to reproduce this problem. I attached jar files with implementation where are located .java files too.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8313) Using own CustomRealm, CustomModificationRealm and CustomRealmMapper implementation leads to AbstractMethodError.
by Hynek Švábek (JIRA)
Hynek Švábek created WFLY-8313:
----------------------------------
Summary: Using own CustomRealm, CustomModificationRealm and CustomRealmMapper implementation leads to AbstractMethodError.
Key: WFLY-8313
URL: https://issues.jboss.org/browse/WFLY-8313
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Priority: Critical
Using own CustomRealm, CustomModifiableRealm and CustomRealmMapper implementation leads to AbstractMethodError.
I tried create my own implementation, set up server to use it but I get error message about AbstractMethodError.
You can see bellow how to reproduce this problem. I attached jar files with implementation where are located .java files too.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8311) ClassNotFoundException when ActiveMQRegistry is loaded by a JMS Bridge
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8311?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-9359 to WFLY-8311:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8311 (was: JBEAP-9359)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: JMS)
Affects Version/s: (was: 7.1.0.DR13)
> ClassNotFoundException when ActiveMQRegistry is loaded by a JMS Bridge
> ----------------------------------------------------------------------
>
> Key: WFLY-8311
> URL: https://issues.jboss.org/browse/WFLY-8311
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> When a JMS bridge is started with debug log, it shows the exception:
> {code}
> 2017-03-01 13:18:45,894 DEBUG [org.apache.activemq.artemis.jms.bridge] (ServerService Thread Pool -- 70) unable to load recovery registry org.jboss.as.messaging.jms.AS7RecoveryRegistry: java.lang.NoClassDefFoundError: org/apache/activemq/artemis/service/extensions/xa/recovery/ActiveMQRegistry
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.locateRecoveryRegistry(JMSBridgeImpl.java:1885)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.start(JMSBridgeImpl.java:333)
> at org.wildfly.extension.messaging.activemq.jms.bridge.JMSBridgeService.startBridge(JMSBridgeService.java:105)
> at org.wildfly.extension.messaging.activemq.jms.bridge.JMSBridgeService$1.run(JMSBridgeService.java:76)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.ClassNotFoundException: org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQRegistry from [Module "org.apache.activemq.artemis:main" from local module loader @7bfcd12c (finder: local module finder @42f30e0a (roots: /home/bershath/apps/jboss/7/jboss-eap-7.0/modules,/home/bershath/apps/jboss/7/jboss-eap-7.0/modules/system/layers/base/.overlays/layer-base-jboss-eap-7.0.4.CP,/home/bershath/apps/jboss/7/jboss-eap-7.0/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
> ... 8 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months