[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)
9 years, 5 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)
9 years, 5 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)
9 years, 5 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)
9 years, 5 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)
9 years, 5 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)
9 years, 5 months
[JBoss JIRA] (WFLY-7709) standalone-minimalistic.xml config got left behind
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-7709?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky updated WFLY-7709:
------------------------------------
Description:
Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations.
These operations are executed when the minimalistic config is loaded:
{code}
/core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default
/socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990")
/socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}")
/core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http")
/core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE
/socket-binding-group=standard-sockets:add(default-interface="public")
{code}
These operations are executed as part of the default core config:
{code}
/core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false")
/socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop
/socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native
/core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default
/socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop
{code}
was:
Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations.
These operations are executed when the minimalistic config is loaded:
/core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default
/socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990")
/socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}")
/core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http")
/core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE
/socket-binding-group=standard-sockets:add(default-interface="public")
These operations are executed as part of the default core config:
/core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false")
/socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop
/socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native
/core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default
/socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop
> standalone-minimalistic.xml config got left behind
> --------------------------------------------------
>
> Key: WFLY-7709
> URL: https://issues.jboss.org/browse/WFLY-7709
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 10.1.0.Final
> Reporter: Alexey Loubyansky
> Assignee: Brian Stansberry
>
> Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations.
> These operations are executed when the minimalistic config is loaded:
> {code}
> /core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default
> /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990")
> /socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}")
> /core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http")
> /core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE
> /socket-binding-group=standard-sockets:add(default-interface="public")
> {code}
> These operations are executed as part of the default core config:
> {code}
> /core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false")
> /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop
> /socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native
> /core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default
> /socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7709) standalone-minimalistic.xml config got left behind
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFLY-7709:
---------------------------------------
Summary: standalone-minimalistic.xml config got left behind
Key: WFLY-7709
URL: https://issues.jboss.org/browse/WFLY-7709
Project: WildFly
Issue Type: Bug
Components: Domain Management
Affects Versions: 10.1.0.Final
Reporter: Alexey Loubyansky
Assignee: Brian Stansberry
Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations.
These operations are executed when the minimalistic config is loaded:
/core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default
/socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990")
/socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}")
/core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http")
/core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE
/socket-binding-group=standard-sockets:add(default-interface="public")
These operations are executed as part of the default core config:
/core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false")
/socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop
/socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native
/core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default
/socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 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:
-----------------------------------
Priority: Minor (was: Major)
> 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.
> As suggested in https://developer.jboss.org/thread/213914 I am creating this issue now,-)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7708) support specifying the runtime-name in the deployment descriptor
by Gregor Rosenauer (JIRA)
Gregor Rosenauer created WFLY-7708:
--------------------------------------
Summary: 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
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,-)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months