[JBoss JIRA] (WFLY-5018) Undertow mod_cluster CLI: Control Node: Enable Contexts, Disable Contexts, Stop Contexts
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5018?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5018.
----------------------------
> Undertow mod_cluster CLI: Control Node: Enable Contexts, Disable Contexts, Stop Contexts
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-5018
> URL: https://issues.jboss.org/browse/WFLY-5018
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: mod_cluster
> Fix For: 10.0.0.Beta1
>
>
> As a follow up to JBEAP-215, this bug report is a member of a series addressing crucial CLI management capabilities.
> h3. Control Nodes
> For any Undertow mod_cluster proxy environment, it is essential to be able to Enable Contexts, Disable Contexts and Stop Contexts on a selected worker Node.
> It is an equivalent of sending this MCMP message attributes ({{worker-2}} is an arbitrary worker node's JVMRoute):
> * Enable Contexts {{Cmd=ENABLE-APP&Range=NODE&JVMRoute=worker-2}}
> * Disable Contexts {{Cmd=DISABLE-APP&Range=NODE&JVMRoute=worker-2}}
> * Stop Contexts {{Cmd=STOP-APP&Range=NODE&JVMRoute=worker-2}}
> h3. Call to action
> Enable user to carry out these actions via WildFly CLI.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-5241) Update messaging subsystem descriptions to properly report path cardinality
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5241?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5241.
----------------------------
> Update messaging subsystem descriptions to properly report path cardinality
> ---------------------------------------------------------------------------
>
> Key: WFLY-5241
> URL: https://issues.jboss.org/browse/WFLY-5241
> Project: WildFly
> Issue Type: Task
> Components: JMS
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 10.0.0.CR1
>
>
> https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen... has been updated to more intelligently report cardinality information about resource registrations, with each reg reporting its own cardinality instead of having the parent report data about the "key" portion of potentially unrelated children.
> The two messaging subsystems are actually trying to use the old way for "path" children, so this JIRA is to move to the new way.
> Instead of the parent resource reporting there must be 4 and no more than 4 children with key "path", now each of the 4 valid path children types will report that the min-occurs of that type is 1. (The max-occurs is also 1, but that will not be reported as that, per the spec, is the default for a 'singleton' type, and each of the 4 path types is a singleton.)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-4676) Unify help message in wsprovide.bat and wsprovide.sh
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4676?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4676.
----------------------------
> Unify help message in wsprovide.bat and wsprovide.sh
> ----------------------------------------------------
>
> Key: WFLY-4676
> URL: https://issues.jboss.org/browse/WFLY-4676
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 10.0.0.Alpha1
> Reporter: Marek Kopecký
> Assignee: Alessio Soldano
> Priority: Minor
> Fix For: 10.0.0.Alpha3
>
>
> Description of problem:
> Unify help message in wsprovide.bat and wsprovide.sh
> Steps to Reproduce:
> 1. On windows: wsconsume.bat -h
> 2. On linux: wsconsume.sh -h
> Actual results:
> On windows:
> ...
> usage: WSProvide [options] <endpoint class name>
> ...
> On linux:
> ...
> usage: wsprovide.sh [options] <endpoint class name>
> ...
> Expected results on Windows:
> ...
> usage: wsprovide.bat [options] <endpoint class name>
> ...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-4587) Provide a migration management operation for HornetQ to ActiveMQ Artemis
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4587?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4587.
----------------------------
> Provide a migration management operation for HornetQ to ActiveMQ Artemis
> ------------------------------------------------------------------------
>
> Key: WFLY-4587
> URL: https://issues.jboss.org/browse/WFLY-4587
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.Alpha6
>
>
> WildFly 10 has a new messaging-activemq subsystem using ActiveMQ Artemis as its messaging broker.
> WildFly 10 needs to provide a :migrate management operation so that user upgrading from WildFly 9 to 10 can start WildFly 10 with their old configuration (which used HornetQ) and migrate to the new subsystem (which used ActiveMQ Artemis).
> This migrate operation deals only with the management resource and does *not* migrate data from HornetQ to Artemis. This will done in a separate step (using either a JMS bridge or data export tool)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-3518) JASPIAuthenticationMechanism#authenticate doesn't check if AuthenticatedSession is null
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3518?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-3518.
----------------------------
> JASPIAuthenticationMechanism#authenticate doesn't check if AuthenticatedSession is null
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3518
> URL: https://issues.jboss.org/browse/WFLY-3518
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Reporter: arjan tijms
> Assignee: Stuart Douglas
> Labels: jaspic
> Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> In {{org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism#authenticate}} the variable {{authSession}} in the fragment below is frequently null, leading to null pointer exceptions:
> {code}
> if (sessionManager != null) {
> AuthenticatedSessionManager.AuthenticatedSession authSession = sessionManager.lookupSession(exchange);
> cachedAccount = authSession.getAccount(); // NPE HAPPENS HERE
> // if there is a cached account we set it in the security context so that the principal is available to
> // SAM modules via request.getUserPrincipal().
> if (cachedAccount != null) {
> jaspicSecurityContext.setCachedAuthenticatedAccount(cachedAccount);
> }
> }
> {code}
> At another place in Undertow where {{AuthenticatedSession}} is used, there's an extra null check (See {{io.undertow.security.impl.CachedAuthenticatedSessionMechanism#runCached}}).
> I patched the code locally to add an extra null check:
> {code}
> if (sessionManager != null) {
> AuthenticatedSessionManager.AuthenticatedSession authSession = sessionManager.lookupSession(exchange);
> cachedAccount = authSession == null? null : authSession.getAccount();
> // if there is a cached account we set it in the security context so that the principal is available to
> // SAM modules via request.getUserPrincipal().
> if (cachedAccount != null) {
> jaspicSecurityContext.setCachedAuthenticatedAccount(cachedAccount);
> }
> }
> {code}
> After a short amount of testing everything seems to be okay with that extra check.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month