[JBoss JIRA] (ELY-802) Elytron ExternalSaslServer/Client should throw IllegalStateException for wrap/unwrap methods
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/ELY-802?page=com.atlassian.jira.plugin.sy... ]
Josef Cacek updated ELY-802:
----------------------------
Description:
Calling {{wrap/unwrap}} methods on {{ExternalSaslServer/Client}} should throw {{IllegalStateException}} as defines [the contract|http://docs.oracle.com/javase/8/docs/api/javax/security/sasl/Sas...]. Currently it throws a {{SaslException}}.
We could be inspired by OpenJDK implementation of CRAM-MD5 and do the following in both methods:
{code:java}
if (completed) {
throw new IllegalStateException(
"EXTERNAL supports neither integrity nor privacy");
} else {
throw new IllegalStateException(
"Authentication not completed");
}
{code}
was:
Calling {{wrap/unwrap}} methods on {{ExternalSaslServer}} should throw {{IllegalStateException}} as defines [SaslServer contract|http://docs.oracle.com/javase/8/docs/api/javax/security/sasl/Sas...]. Currently it throws a {{SaslException}}.
We could be inspired by OpenJDK implementation of CRAM-MD5 and do the following in both methods:
{code:java}
if (completed) {
throw new IllegalStateException(
"EXTERNAL supports neither integrity nor privacy");
} else {
throw new IllegalStateException(
"Authentication not completed");
}
{code}
Summary: Elytron ExternalSaslServer/Client should throw IllegalStateException for wrap/unwrap methods (was: Elytron ExternalSaslServer should throw IllegalStateException for wrap/unwrap methods)
> Elytron ExternalSaslServer/Client should throw IllegalStateException for wrap/unwrap methods
> --------------------------------------------------------------------------------------------
>
> Key: ELY-802
> URL: https://issues.jboss.org/browse/ELY-802
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
>
> Calling {{wrap/unwrap}} methods on {{ExternalSaslServer/Client}} should throw {{IllegalStateException}} as defines [the contract|http://docs.oracle.com/javase/8/docs/api/javax/security/sasl/Sas...]. Currently it throws a {{SaslException}}.
> We could be inspired by OpenJDK implementation of CRAM-MD5 and do the following in both methods:
> {code:java}
> if (completed) {
> throw new IllegalStateException(
> "EXTERNAL supports neither integrity nor privacy");
> } else {
> throw new IllegalStateException(
> "Authentication not completed");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2066) Kill and destroy operations on the server-group
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2066:
----------------------------------------
Summary: Kill and destroy operations on the server-group
Key: WFCORE-2066
URL: https://issues.jboss.org/browse/WFCORE-2066
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
The server-config resources expose kill and destroy operations; it would be useful to have these on the server-group as well. If some problem (e.g. a bad deployment) is causing all servers in the group to hang it is nice to be able to kill/destroy them in one op versus having to identify all members and kill them individually.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2065) Domain server 'kill' and 'destroy' operations need to ensure the server is dead
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2065:
----------------------------------------
Summary: Domain server 'kill' and 'destroy' operations need to ensure the server is dead
Key: WFCORE-2065
URL: https://issues.jboss.org/browse/WFCORE-2065
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The 'kill' and 'destroy' operations end up triggering invocation of the ManagedProcess kill() and destroy() methods. But those methods don't ensure the server process ends up dead. Their primary code path is to call 'stop()' and return. But if there is a problem doing the normal stop (which is fairly likely given the user invoked 'kill' or 'destroy' then the server process is left hanging around as a zombie.
A second invocation of kill or destroy will end up doing the real kill/destroy by realizing the stop() hasn't worked, but that is unintuitive and inconvenient.
Worse, with the EAP 6 web console at least, the console reports the process as being down, which is highly misleading, and it means the console doesn't provide the UI elements to allow the user to try again. The user is forced to use the CLI to do the second kill/destroy.
I think these methods should try the stop() but then after 5-10 seconds if the process isn't down, go on and invoke the hard kill/destroy logic. Assume that the user chose kill/destroy over stop for a reason and that a normal stop not succeeding quickly means stronger action is needed. The only downside to this is some server that could stop normally but happens to take a bit too long is hard killed, but that to me is a real edge case.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2061) JMX access unauthorized after RBAC enabled
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2061?page=com.atlassian.jira.plugi... ]
Darran Lofthouse edited comment on WFCORE-2061 at 11/30/16 11:43 AM:
---------------------------------------------------------------------
Sorry we just do not support RBAC at all for applications accessing JMX directly. Your workaround may work for now but will certainly be broken by WildFly 11 where we switch to WildFly Elytron.
A separate feature request could be justified though.
In our upstream work we are also having to preserve this apps get full access behaviour but I would really like to make sure at some point at least we can switch to identity based authorization for in-vm calls as well.
was (Author: dlofthouse):
Sorry we just do not support RBAC at all for applications accessing JMX directly. Your workaround may fork for now but will certainly be broken by WildFly 11 where we switch to WildFly Elytron.
A separate feature request could be justified though.
In our upstream work we are also having to preserve this apps get full access behaviour but I would really like to make sure at some point at least we can switch to identity based authorization for in-vm calls as well.
> JMX access unauthorized after RBAC enabled
> ------------------------------------------
>
> Key: WFCORE-2061
> URL: https://issues.jboss.org/browse/WFCORE-2061
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Security
> Affects Versions: 2.2.0.Final
> Reporter: Tadayoshi Sato
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha14
>
> Attachments: standalone.xml, wildfly-jmx-auth.zip
>
>
> After RBAC is enabled, even a user ({{"admin"}}) with {{SuperUser}} role fails to get authorized access to JMX with the following code:
> {code:java}
> MBeanServer mBeanServer = ...
> Subject subject = new Subject();
> // Login
> new LoginContext("test-domain", subject, callbacks -> { ... }).login();
> // Access to JMX
> Subject.doAs(subject, (PrivilegedAction<Object>) () -> {
> mBeanServer.getAttribute(new ObjectName("java.lang:type=Memory"), "HeapMemoryUsage"));
> return null;
> });
> {code}
> RBAC and role-mapping are enabled in {{standalone.xml}} like this:
> {code:xml}
> <access-control provider="rbac">
> <role-mapping>
> <role name="SuperUser">
> <include>
> <user name="$local"/>
> <user name="admin"/>
> </include>
> </role>
> </role-mapping>
> </access-control>
> [...]
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> [...]
> <security-domain name="test-domain" cache-type="default">
> <authentication>
> <login-module code="RealmDirect" flag="required">
> <module-option name="realm" value="ManagementRealm"/>
> </login-module>
> </authentication>
> </security-domain>
> {code}
> The code gets this error in the server log:
> {code}
> javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1203)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1190)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:387)
> at com.redhat.issues.wildfly.JmxServlet.readMBeanAttribute(JmxServlet.java:87)
> at com.redhat.issues.wildfly.JmxServlet.lambda$process$0(JmxServlet.java:53)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at com.redhat.issues.wildfly.JmxServlet.process(JmxServlet.java:52)
> at com.redhat.issues.wildfly.JmxServlet.doGet(JmxServlet.java:44)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2061) JMX access unauthorized after RBAC enabled
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2061?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-2061:
------------------------------------------
Sorry we just do not support RBAC at all for applications accessing JMX directly. Your workaround may fork for now but will certainly be broken by WildFly 11 where we switch to WildFly Elytron.
A separate feature request could be justified though.
In our upstream work we are also having to preserve this apps get full access behaviour but I would really like to make sure at some point at least we can switch to identity based authorization for in-vm calls as well.
> JMX access unauthorized after RBAC enabled
> ------------------------------------------
>
> Key: WFCORE-2061
> URL: https://issues.jboss.org/browse/WFCORE-2061
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Security
> Affects Versions: 2.2.0.Final
> Reporter: Tadayoshi Sato
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha14
>
> Attachments: standalone.xml, wildfly-jmx-auth.zip
>
>
> After RBAC is enabled, even a user ({{"admin"}}) with {{SuperUser}} role fails to get authorized access to JMX with the following code:
> {code:java}
> MBeanServer mBeanServer = ...
> Subject subject = new Subject();
> // Login
> new LoginContext("test-domain", subject, callbacks -> { ... }).login();
> // Access to JMX
> Subject.doAs(subject, (PrivilegedAction<Object>) () -> {
> mBeanServer.getAttribute(new ObjectName("java.lang:type=Memory"), "HeapMemoryUsage"));
> return null;
> });
> {code}
> RBAC and role-mapping are enabled in {{standalone.xml}} like this:
> {code:xml}
> <access-control provider="rbac">
> <role-mapping>
> <role name="SuperUser">
> <include>
> <user name="$local"/>
> <user name="admin"/>
> </include>
> </role>
> </role-mapping>
> </access-control>
> [...]
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> [...]
> <security-domain name="test-domain" cache-type="default">
> <authentication>
> <login-module code="RealmDirect" flag="required">
> <module-option name="realm" value="ManagementRealm"/>
> </login-module>
> </authentication>
> </security-domain>
> {code}
> The code gets this error in the server log:
> {code}
> javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1203)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1190)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:387)
> at com.redhat.issues.wildfly.JmxServlet.readMBeanAttribute(JmxServlet.java:87)
> at com.redhat.issues.wildfly.JmxServlet.lambda$process$0(JmxServlet.java:53)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at com.redhat.issues.wildfly.JmxServlet.process(JmxServlet.java:52)
> at com.redhat.issues.wildfly.JmxServlet.doGet(JmxServlet.java:44)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7586) Wrong options for auto-completion in realms of Elytron security-domain in CLI
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7586?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7586:
--------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Wrong options for auto-completion in realms of Elytron security-domain in CLI
> -----------------------------------------------------------------------------
>
> Key: WFLY-7586
> URL: https://issues.jboss.org/browse/WFLY-7586
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Labels: user_experience
>
> Auto-completion for realm in realms of security-domain provides wrong options. In case when ldap-realm with name ldapName is defined in configuration then also option {{rity-realm.ldapName}} occurs in auto-completion options. I am not able to reproduce this issue with properties-realm. Take a look at Steps to Reproduce for more details.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7695) Unexpected error while replicating: NPE
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7695?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-7695:
-------------------------------
Labels: (was: infinispan_clean_shutdown)
> Unexpected error while replicating: NPE
> ---------------------------------------
>
> Key: WFLY-7695
> URL: https://issues.jboss.org/browse/WFLY-7695
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Occured on server during scenario eap-7x-failover-ejb-ejbservlet-shutdown-dist-async.
> Server log stacktrace:
> {code}
> 11:07:31,390 WARN [org.infinispan.transaction.impl.TransactionTable] (ServerService Thread Pool -- 87) ISPN000100: Stopping, but there are 1 local transactions and 4 remote transactions that did not finish in time.
> [JBossINF] [11:07:31,391 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0003: Stopped clusterbench-ee7.ear.clusterbench-ee7-web-default.war cache from web container
> [JBossINF] [11:07:31,393 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel web
> [JBossINF] [11:07:31,393 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel web
> [JBossINF] [11:07:31,394 ERROR [org.infinispan.remoting.rpc.RpcManagerImpl] (default task-65) ISPN000073: Unexpected error while replicating: java.lang.NullPointerException
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotelyAsync(JGroupsTransport.java:611)
> [JBossINF] at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotelyAsync(RpcManagerImpl.java:144)
> [JBossINF] at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:185)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.releaseLocksOnFailureBeforePrepare(PessimisticLockingInterceptor.java:268)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:79)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:80)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:346)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:331)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:177)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:154)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> [JBossINF] at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:74)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:64)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:36)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:60)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:38)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:228)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:142)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:772)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:802)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:806)
> [JBossINF] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:572)
> [JBossINF] at io.undertow.servlet.spec.HttpServletResponseImpl.doErrorDispatch(HttpServletResponseImpl.java:171)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:327)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [JBossINF] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [JBossINF] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF]
> [JBossINF] [11:07:31,394 ERROR [org.infinispan.remoting.rpc.RpcManagerImpl] (default task-65) ISPN000073: Unexpected error while replicating: java.lang.NullPointerException
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotelyAsync(JGroupsTransport.java:611) ...
> {code}
> There were two occurences of this ERROR in a direct sequence when the server was shutting down.
> This ERROR occured afterwards on the server:
> {code}
> 07:31,397 ERROR [org.infinispan.transaction.impl.TransactionCoordinator] (default task-65) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.IllegalLifecycleStateException: ISPN000323: Cache 'routing' is in 'TERMINATED' state and so it does not accept new invocations. Either restart it or recreate the cache container.
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:101) ...
> {code}
> JvmRoute changed occured on client at the same time:
> {code}
> 2016/10/05 11:07:31:452 EDT [INFO ][Runner - 874] HOST dev220.mw.lab.eng.bos.redhat.com:rootProcess:c - Failover detected, JvmRoute changed. dev213 -> dev212
> {code}
> Link to server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1374) Rename property version.wildfly.swarm to version.org.wildfly.swarm
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created DROOLS-1374:
----------------------------------------
Summary: Rename property version.wildfly.swarm to version.org.wildfly.swarm
Key: DROOLS-1374
URL: https://issues.jboss.org/browse/DROOLS-1374
Project: Drools
Issue Type: Task
Components: build
Reporter: Geoffrey De Smet
Assignee: Michael Biarnes Kiefer
in kie-parent it says
{code}
<version.wildfly.swarm>2016.9</version.wildfly.swarm>
{code}
that should be
{code}
<version.org.wildfly.swarm>2016.9</version.org.wildfly.swarm>
{code}
according to property guidelines.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7708) support specifying the runtime-name in the deployment descriptor
by Gregor Rosenauer (JIRA)
[ https://issues.jboss.org/browse/WFLY-7708?page=com.atlassian.jira.plugin.... ]
Gregor Rosenauer updated WFLY-7708:
-----------------------------------
Description:
There is often a need to change the name of a deployment, e.g. the EAR, from the default name to a stable name.
The problem is that common Maven practice mandates a version suffix, generating a fully versioned EAR. Wildfly by default (which is only changable from CLI/management console) takes the full name without the extension.
This leads to clunky and brittle code, e.g. JNDI lookups *have* to use the full name including version, which is most often undesirable.
Sadly, Wildfly completely ignores the <earName> (was it?) attribute in the application.xml.
Generally, there should be an option to strip versions of deployments so e.g. JNDI lookup is stable and not version dependent.
I know there can be a scenario where this would make sense, but it's a 0.0001% use case imho.
As suggested in https://developer.jboss.org/thread/213914 I am creating this issue now,-)
In the meantime, the best way for me was to configure the maven-ear-plugin to change the module names like suggested in http://stackoverflow.com/a/27442584/160799 and to override the finalName of the modules in the module POMs.
was:
There is often a need to change the name of a deployment, e.g. the EAR, from the default name to a stable name.
The problem is that common Maven practice mandates a version suffix, generating a fully versioned EAR. Wildfly by default (which is only changable from CLI/management console) takes the full name without the extension.
This leads to clunky and brittle code, e.g. JNDI lookups *have* to use the full name including version, which is most often undesirable.
As suggested in https://developer.jboss.org/thread/213914 I am creating this issue now,-)
> support specifying the runtime-name in the deployment descriptor
> ----------------------------------------------------------------
>
> Key: WFLY-7708
> URL: https://issues.jboss.org/browse/WFLY-7708
> Project: WildFly
> Issue Type: Enhancement
> Components: EE
> Affects Versions: 9.0.2.Final
> Environment: Java EE 7
> Reporter: Gregor Rosenauer
> Priority: Minor
> Labels: EE, deployment, descriptor
>
> There is often a need to change the name of a deployment, e.g. the EAR, from the default name to a stable name.
> The problem is that common Maven practice mandates a version suffix, generating a fully versioned EAR. Wildfly by default (which is only changable from CLI/management console) takes the full name without the extension.
> This leads to clunky and brittle code, e.g. JNDI lookups *have* to use the full name including version, which is most often undesirable.
> Sadly, Wildfly completely ignores the <earName> (was it?) attribute in the application.xml.
> Generally, there should be an option to strip versions of deployments so e.g. JNDI lookup is stable and not version dependent.
> I know there can be a scenario where this would make sense, but it's a 0.0001% use case imho.
> As suggested in https://developer.jboss.org/thread/213914 I am creating this issue now,-)
> In the meantime, the best way for me was to configure the maven-ear-plugin to change the module names like suggested in http://stackoverflow.com/a/27442584/160799 and to override the finalName of the modules in the module POMs.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months