[JBoss JIRA] (WFCORE-386) Ability to configure a custom RBAC implementation
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-386?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-386:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Ability to configure a custom RBAC implementation
> -------------------------------------------------
>
> Key: WFCORE-386
> URL: https://issues.jboss.org/browse/WFCORE-386
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Optional
> Labels: RBAC-WF-only
> Fix For: 1.0.0.CR1
>
>
> Allow configuration of a module name and set of key/value properties to allow users to plug in a custom implementation of the CustomAuthorizer interface. The impl would be loadable via the ServiceLoader mechanism.
> The hooks to integrate such a custom impl into the server are already done, so this is should be just a matter of adding the config capability.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-384) Server does wrongly reference a list of socket binding groups
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-384?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-384:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Server does wrongly reference a list of socket binding groups
> -------------------------------------------------------------
>
> Key: WFCORE-384
> URL: https://issues.jboss.org/browse/WFCORE-384
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Braun
> Fix For: 1.0.0.CR1
>
>
> hbraun: i see that a server (host=foo/server=bar) can have a list of socket-binding-groups
> [10:59am] hbraun: shouldn't that be a a single socket binding instead?
> [11:00am] emuckenhuber: oh... yeah
> [11:00am] hbraun: maybe it's just the description that's wrong
> [11:00am] emuckenhuber: that sounds similar to the jvm thing we had
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-390) Add reference description information to resource metadata
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-390?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-390:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Add reference description information to resource metadata
> ----------------------------------------------------------
>
> Key: WFCORE-390
> URL: https://issues.jboss.org/browse/WFCORE-390
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 1.0.0.CR1
>
>
> The AS's configuration model frequently includes attributes that are references to the name of some other resource in the model. The metadata describing such attributes must include information to help users and tooling to understand that reference.
> A simple approach would be to include a metadata attribute whose value is an absolute or relative path to the target resource.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-388) Overall 'server-state' flag on the Host Controller
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-388?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-388:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Overall 'server-state' flag on the Host Controller
> --------------------------------------------------
>
> Key: WFCORE-388
> URL: https://issues.jboss.org/browse/WFCORE-388
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 1.0.0.CR1
>
>
> This is for consideration; we need to see if it makes sense.
> Request is for an attribute on the HC that indicates aggregate 'server-state'. The desire is to know when all servers are available, and thus it is safe to invoke management ops knowing all servers will receive them.
> The only reason a server wouldn't receive an op is if it is started in a non-blocking mode, so the server gets its config but then hasn't connected with the HC and therefore won't get update operations. Starting the server in blocking mode will avoid this situation (as could changes to how we start servers, to make it more like how a slave HC registers with the master HC). So, before doing this let's first look at how to reduce/eliminate the use case for it.
> Also to consider when looking at this is how to represent servers in things like "restart-required" state in this overall aggregate 'server-state'.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-392) Stack trace improvements, summarize the things that broke to make them not so intimidating
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-392?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-392:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Stack trace improvements, summarize the things that broke to make them not so intimidating
> ------------------------------------------------------------------------------------------
>
> Key: WFCORE-392
> URL: https://issues.jboss.org/browse/WFCORE-392
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Jim Tyrrell
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: eap6-ux
> Fix For: 1.0.0.CR1
>
> Attachments: log.txt
>
>
> See the typical attached stack dump:
> It would be nice if the stack dump could include all of the information above as a summary as shown below, basically just the first lines of the errors w/o the whole stack dump:
> 11:51:45,391 INFO [org.jboss.as.server.controller] (HttpManagementService-threads - 5) Deployment of "SpringWAR.war" was rolled back with failure message {"Failed services" => {"jboss.web.deployment.default-host./SpringWAR" => "org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./SpringWAR: failed to start context"}}
> 11:51:45,392 INFO [org.jboss.as.controller] (HttpManagementService-threads - 5) Service status report
> Services which failed to start:
> service jboss.web.deployment.default-host./SpringWAR: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./SpringWAR: failed to start context
> 11:51:45,417 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Stopped deployment SpringWAR.war in 26ms
> 11:51:45,417 Error Summary of Exceptions in deployment:
> - [org.springframework.web.context.ContextLoader] (MSC service thread 1-5) Context initialization failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
> - [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
> - [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Error listenerStart
> - ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Context [/SpringWAR] startup failed due to previous errors
> - [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Closing Spring root WebApplicationContext
> - [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.web.deployment.default-host./SpringWAR:
> ERROR Scroll up to see more info...
> Or
> 11:51:45,417 Error Summary of Exceptions in deployment:
> [1] [org.springframework.web.context.ContextLoader] (MSC service thread 1-5) Context initialization failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
> [2] [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
> [3] [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Error listenerStart
> [4] ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Context [/SpringWAR] startup failed due to previous errors
> [5] [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Closing Spring root WebApplicationContext
> [6] [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.web.deployment.default-host./SpringWAR:
> ERROR Scroll up to see more info...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-391) Add management API descriptions for alias resources and attributes
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-391?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-391:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Add management API descriptions for alias resources and attributes
> ------------------------------------------------------------------
>
> Key: WFCORE-391
> URL: https://issues.jboss.org/browse/WFCORE-391
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 1.0.0.CR1
>
>
> When a resource or an attribute is an alias for a different resource or attribute, the management API description data should include information describing that relationship.
> For an attribute, an alias relationship is different from an 'alternatives' relationship, as the latter is a mutually exclusive arrangement (one alternative must be undefined if the other isn't) while with an alias, both attributes will exist but will always have the same value, and attempting to set them to different values (e.g. using both as params with different values in an 'add' op) is invalid.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-393) Clone a profile
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-393?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-393:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Clone a profile
> ---------------
>
> Key: WFCORE-393
> URL: https://issues.jboss.org/browse/WFCORE-393
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 1.0.0.CR1
>
>
> Add the ability to clone a profile.
> This could be a new "clone" operation on the existing profile resource, or perhaps a "clone-from" parameter on the existing "add" operation. Probably the former, as that will be more transformation-friendly.
> Implementation will likely involve using the "describe" operation used for configuring managed domain servers and adding steps from the describe results directly on the HC instead of passing them to a server.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-401) Consider using a "describe" notion for providing the model to slaves on registration
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-401?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-401:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Consider using a "describe" notion for providing the model to slaves on registration
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-401
> URL: https://issues.jboss.org/browse/WFCORE-401
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Kabir Khan
> Fix For: 1.0.0.CR1
>
>
> When a slave HC registers, the master provides it a copy of the domain-wide model as a DMR tree. This has a weakness in that the Resource impl types that comprise that tree on the master side are not transmitted. If custom Resource impls are used, they may not be recreated on the slave.
> Consider instead sending a list of mgmt ops, a la what we do with servers when starting from an HC.
> This could potentially be limited to subsystems, with the core model sent as it is now. The core model is handled by core-AS code on the slave side, so we can reasonably ensure that code always uses the correct Resource type. There are places where we already do that. The bigger problem is subsystems.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months