[JBoss JIRA] (WFLY-3058) Expose data on actively executing management ops, with an op to cancel
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-3058:
--------------------------------------
Summary: Expose data on actively executing management ops, with an op to cancel
Key: WFLY-3058
URL: https://issues.jboss.org/browse/WFLY-3058
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 9.0.0.CR1
Track the management ops actively being executed by the ModelController and expose them as management resources. Include a 'cancel' op to let admins terminate a non-progressing op.
A ModelControllerClient already allows cancelling an op by using its async API and canceling the returned Future. But that's not a particularly user-friendly way of dealing with the issue -- not helpful for HTTP users, requires some sort of CLI changes and unintuitive workflows to make it accessible to CLI users, etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (WFLY-3033) Better SSO configuration
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-3033:
--------------------------------------
Makes sense to me.
> Better SSO configuration
> ------------------------
>
> Key: WFLY-3033
> URL: https://issues.jboss.org/browse/WFLY-3033
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Tin Tvrtkovic
> Assignee: Tomaz Cerar
> Priority: Critical
> Labels: single-sign-on, undertow
> Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (WFLY-3033) Better SSO configuration
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-3033:
------------------------------------
Would it make sense to default the cookie path to the web application context path?
> Better SSO configuration
> ------------------------
>
> Key: WFLY-3033
> URL: https://issues.jboss.org/browse/WFLY-3033
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Tin Tvrtkovic
> Assignee: Tomaz Cerar
> Priority: Critical
> Labels: single-sign-on, undertow
> Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (WFLY-3057) Add proper ResourceDefinition hooks for setting runtime only, adding aliases
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-3057:
--------------------------------------
Summary: Add proper ResourceDefinition hooks for setting runtime only, adding aliases
Key: WFLY-3057
URL: https://issues.jboss.org/browse/WFLY-3057
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 9.0.0.CR1
If a resource is runtime only or has alias registrations, there's no proper API for configuring these. ResourceDefinition impls are forced to hack this in via the registerAttributes/Operations/Children callbacks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (WFLY-781) urn:jboss:pojo:7.0 is a subset of *-jboss-beans.xml, application-policy is not available
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-781?page=com.atlassian.jira.plugin.s... ]
David Lloyd resolved WFLY-781.
------------------------------
Resolution: Rejected
It is extremely unlikely that this functionality will be forward ported unfortunately.
> urn:jboss:pojo:7.0 is a subset of *-jboss-beans.xml, application-policy is not available
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-781
> URL: https://issues.jboss.org/browse/WFLY-781
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: POJO
> Environment: AS 7.1.0-Alpha1-SNAPSHOT - commit 335c262c7449e4f6667b5339838bfdf0a65f5263
> Reporter: Karel Piwko
> Assignee: Ales Justin
>
> I'm migrating an application which has security domain defined in *-jboss-beans.xml from AS 5 to AS 7.
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <deployment xmlns="urn:jboss:pojo:7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:jboss:pojo:7.0 jboss-pojo_7_0.xsd">
> <application-policy name="security-preauth">
> <authentication>
> <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
> <module-option name="usersProperties" value="security-preauth-users.properties" />
> <module-option name="rolesProperties" value="security-preauth-roles.properties" />
> </login-module>
> </authentication>
> </application-policy>
> </deployment>
> {code}
> This security domain is specified in jboss-web.xml, as:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>security-preauth</security-domain>
> <context-root>spring-preauth</context-root>
> </jboss-web>
> {code}
> Here's corresponding configuration in web.xml
> {code:xml}
> <login-config>
> <auth-method>BASIC</auth-method>
> <realm-name>security-preauth</realm-name>
> </login-config>
> <security-role>
> <role-name>ROLE_USER</role-name>
> </security-role>
> <security-role>
> <role-name>ROLE_SUPERVISOR</role-name>
> </security-role>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>All areas</web-resource-name>
> <url-pattern>/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>ROLE_USER</role-name>
> </auth-constraint>
> </security-constraint>
> {code}
> This is not correctly loaded by JBoss AS, failing with (after TRACE logging is enabled):
> {code}
> 16:46:44,287 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.unit."spring-preauth.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."spring-preauth.war".PARSE: Failed to process phase PARSE of deployment "spring-preauth.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
> at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to parse POJO xml ["/content/spring-preauth.war/META-INF/security-preauth-jboss-beans.xml"]
> at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptor(KernelDeploymentParsingProcessor.java:130)
> at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptors(KernelDeploymentParsingProcessor.java:104)
> at org.jboss.as.pojo.KernelDeploymentParsingProcessor.deploy(KernelDeploymentParsingProcessor.java:73)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> ... 5 more
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[5,5]
> Message: Unexpected element '{urn:jboss:pojo:7.0}application-policy' encountered
> at org.jboss.as.controller.parsing.ParseUtils.unexpectedElement(ParseUtils.java:65)
> at org.jboss.as.pojo.descriptor.KernelDeploymentXmlDescriptorParser.readElement(KernelDeploymentXmlDescriptorParser.java:174)
> at org.jboss.as.pojo.descriptor.KernelDeploymentXmlDescriptorParser.readElement(KernelDeploymentXmlDescriptorParser.java:50)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59)
> at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptor(KernelDeploymentParsingProcessor.java:123)
> ... 8 more
> {code}
> Note: With AS 7.0.1 this is not working at all, *-jboss-beans.xml is ignored.
> Workaround is modify standalone.xml and add the security domain there, but it's not a feasible solution as it makes automated testing much more difficult.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (WFLY-3055) Ability to configure a prefix to the domain server launch command
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3055?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-3055:
-----------------------------------
* Locking a process to a core or cores: {{taskset 0x0030 ...}}
* Managing process priority: {{nice -n -5 ...}}
It would be nice if we could do it close to the way I originally suggested back 3-4 years ago or whatever it was, and have knowledge of how to control various JVMs and various OSes to accomplish common tasks in a platform-independent way, but at least having a generic capability is something.
> Ability to configure a prefix to the domain server launch command
> -----------------------------------------------------------------
>
> Key: WFLY-3055
> URL: https://issues.jboss.org/browse/WFLY-3055
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: John O'Hara
> Fix For: 9.0.0.CR1
>
>
> Ability to configure a prefix to the 'java' command used to launch a domain server. This would be a general purpose feature but some intended uses we'd want to make sure work include:
> 1) NUMA settings, e.g.
> numactl --membind 0 --cpubind 0
> 2) Having the server process run under a different user, e.g.
> sudo joe
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (WFLY-3055) Ability to configure a prefix to the domain server launch command
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-3055:
--------------------------------------
Summary: Ability to configure a prefix to the domain server launch command
Key: WFLY-3055
URL: https://issues.jboss.org/browse/WFLY-3055
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Assignee: John O'Hara
Fix For: 9.0.0.CR1
Ability to configure a prefix to the 'java' command used to launch a domain server. This would be a general purpose feature but some intended uses we'd want to make sure work include:
1) NUMA settings, e.g.
numactl --membind 0 --cpubind 0
2) Having the server process run under a different user, e.g.
sudo joe
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (WFLY-3054) getPlatformMBeanServer behaves badly when called from premain class such as jmxetric
by dpocock (JIRA)
dpocock created WFLY-3054:
-----------------------------
Summary: getPlatformMBeanServer behaves badly when called from premain class such as jmxetric
Key: WFLY-3054
URL: https://issues.jboss.org/browse/WFLY-3054
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMX
Affects Versions: JBoss AS7 7.1.1.Final
Reporter: dpocock
Assignee: Kabir Khan
JMXetric is a management agent JAR loaded using the JVM argument
java -javaagent:$JARLIBS/jmxetric-1.0.2.jar .....
In the premain method (executed before JBoss main() is invoked), jmxetric calls the static method:
ManagementFactory.getPlatformMBeanServer()
This puts JMX into a bad state and the jboss.as tree is completely missing when browsed with jconsole
As a workaround, jmxetric will defer the call to ManagementFactory.getPlatformMBeanServer() using the "initialdelay" parameter set to a value such as 20 seconds.
However, it would be good if JBoss could act more cleanly in this situation, for example, throwing an exception if ManagementFactory.getPlatformMBeanServer() is called too early, or finding a way to add the "jboss.as" stuff later.
The 1.0.6 release of jmxetric will include the workaround by default. The bug can be reproduced by setting initialdelay="0" in the sample jmxetric.xml or using jmxetric 1.0.5
jmxetric versions before 1.0.5 suffer from issues with the jboss logger as discussed in WFLY-895, so this issue was only discovered after removing the logging statements from jmxetric.
Also covered in jmxetric github:
https://github.com/ganglia/jmxetric/issues/9
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months