November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1104) Add an api to make a (standalone) server join a cluster

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1104?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1104: ------------------------------------------ I've been tempted to resolve this several times as "Won't Do" as we have a mechanism to do this: launch a Host Controller and use the management API to spin up a server using the desired profile. It's possible in theory that someday we would write logic to let a standalone server contact another server and pull config and deployments from it, but it's pretty unlikely. > Add an api to make a (standalone) server join a cluster > -------------------------------------------------------- > > Key: WFCORE-1104 > URL: https://issues.jboss.org/browse/WFCORE-1104 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Heiko Rupp > Labels: rhq > > It should be possible to have an api call that syncs a new server into a cluster > This could perhaps get the username/password to reach an existing cluster member and then slurp the relevant data (+ deployments) over. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4840) Deprecated element cluster-passivation-store from ejb subsystem does not work

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4840?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-4840: ----------------------------------- Component/s: (was: Domain Management) > Deprecated element cluster-passivation-store from ejb subsystem does not work > ----------------------------------------------------------------------------- > > Key: WFLY-4840 > URL: https://issues.jboss.org/browse/WFLY-4840 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Ondřej Chaloupka > Assignee: Paul Ferraro > > There is a mismatch in behaviour of deprecated element {{cluster-passivation-store}} under {{ejb}} subsystem. > When element is deprecated still it should work and only prints warning that it's deprecated. > {code} > [standalone@localhost:9990 /] /subsystem=ejb3/cluster-passivation-store=infinispan:read-resource() > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0216: Management resource '[ > (\"subsystem\" => \"ejb3\"), > (\"cluster-passivation-store\" => \"infinispan\") > ]' not found", > "rolled-back" => true > } > {code} > but > {code} > [standalone@localhost:9990 /] /subsystem=ejb3/cluster-passivation-store=infinispan:add() > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb.cache.factory.distributable.infinispan is already registered", > "rolled-back" => true > } > {code} > _A note:_ the element {{cluster-passivation-store}} was replaced by {{passivation-store}} which works fine -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1104) Add an api to make a (standalone) server join a cluster

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1104?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-1062 to WFCORE-1104: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-1104 (was: WFLY-1062) Component/s: Domain Management (was: Domain Management) > Add an api to make a (standalone) server join a cluster > -------------------------------------------------------- > > Key: WFCORE-1104 > URL: https://issues.jboss.org/browse/WFCORE-1104 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Heiko Rupp > Priority: Critical > Labels: rhq > > It should be possible to have an api call that syncs a new server into a cluster > This could perhaps get the username/password to reach an existing cluster member and then slurp the relevant data (+ deployments) over. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1104) Add an api to make a (standalone) server join a cluster

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1104?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1104: ------------------------------------- Priority: Major (was: Critical) > Add an api to make a (standalone) server join a cluster > -------------------------------------------------------- > > Key: WFCORE-1104 > URL: https://issues.jboss.org/browse/WFCORE-1104 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Heiko Rupp > Labels: rhq > > It should be possible to have an api call that syncs a new server into a cluster > This could perhaps get the username/password to reach an existing cluster member and then slurp the relevant data (+ deployments) over. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1103) Security realms does not validate JAAS references to security domains

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1103?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1103: ------------------------------------------ I moved this to WFCORE because anything on this, whether the major changes Darran mentioned or anything else, in the end would involve a change to core. I'm trying to get Domain Management issues out of WFLY as they largely don't belong there. > Security realms does not validate JAAS references to security domains > --------------------------------------------------------------------- > > Key: WFCORE-1103 > URL: https://issues.jboss.org/browse/WFCORE-1103 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Environment: Development Mac > Test Linux (Debian) > Reporter: Nicky Mølholm > Labels: jaas, logging, security, trace > > *Problem* > In the server configuration file (standalone.xml) it is possible to define a security realm that points to a security domain that does not exist - and there is no error reporting of this at all. There is no trace information of this at all, either. > *Example* > * Download a stock Wildfly 8.1.0.Final > * Replace standalone.xml with this gist: https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw... > Run it and you will see now errors at all. Despite the fact that the _FlawedRealm_ points to a bogus security domain called _ThisDomainDoesntExistAtAll_ . I have captured my logoutput too. Find it here: https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw... > *What is wrong with this behavior?* > The bootstrapping process must validate that the configuration is valid indeed. It really doesn't - not semantically that is. Only XSD compliance / XML syntax wise. And if, for some weird reason, that silence is "security" - then at least let us know of the errors on loglevel = TRACE. > *Why is this issue created?* > The silent behavior makes security configuration in Wildfly an _extremely expensive operation_ in terms of time spent by the average Java EE developer / administrator. I have created this issue because I want wildfly to help developers/administrators become better at spotting our errors - because, in the end, that is a tangible productivity booster. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1103) Security realms does not validate JAAS references to security domains

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1103?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-3761 to WFCORE-1103: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-1103 (was: WFLY-3761) Component/s: Domain Management Security (was: Domain Management) (was: Security) Affects Version/s: (was: 8.1.0.Final) Fix Version/s: (was: Awaiting Volunteers) > Security realms does not validate JAAS references to security domains > --------------------------------------------------------------------- > > Key: WFCORE-1103 > URL: https://issues.jboss.org/browse/WFCORE-1103 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Environment: Development Mac > Test Linux (Debian) > Reporter: Nicky Mølholm > Labels: jaas, logging, security, trace > > *Problem* > In the server configuration file (standalone.xml) it is possible to define a security realm that points to a security domain that does not exist - and there is no error reporting of this at all. There is no trace information of this at all, either. > *Example* > * Download a stock Wildfly 8.1.0.Final > * Replace standalone.xml with this gist: https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw... > Run it and you will see now errors at all. Despite the fact that the _FlawedRealm_ points to a bogus security domain called _ThisDomainDoesntExistAtAll_ . I have captured my logoutput too. Find it here: https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw... > *What is wrong with this behavior?* > The bootstrapping process must validate that the configuration is valid indeed. It really doesn't - not semantically that is. Only XSD compliance / XML syntax wise. And if, for some weird reason, that silence is "security" - then at least let us know of the errors on loglevel = TRACE. > *Why is this issue created?* > The silent behavior makes security configuration in Wildfly an _extremely expensive operation_ in terms of time spent by the average Java EE developer / administrator. I have created this issue because I want wildfly to help developers/administrators become better at spotting our errors - because, in the end, that is a tangible productivity booster. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-819) Invalid minimal value of datasource background-validation-millis parameter

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-819?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated WFLY-819: ---------------------------------- Component/s: (was: Domain Management) > Invalid minimal value of datasource background-validation-millis parameter > -------------------------------------------------------------------------- > > Key: WFLY-819 > URL: https://issues.jboss.org/browse/WFLY-819 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Pavel Slegr > Assignee: Jesper Pedersen > Priority: Minor > > Regarding .../docs/schema/ jboss-as-datasources_1_0.xsd > the background-validation-millis type is defined like "nonNegativeInteger" > <xs:element name="background-validation-millis" type="xs:nonNegativeInteger" minOccurs="0"> > and nonNegativeInteger is: "An integer containing only non-negative values (0,1,2,..)" > thus zero is valid value to add... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-722) Cannot change WAR file's context URL when deploying via console

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-722?page=com.atlassian.jira.plugin.s... ] Brian Stansberry resolved WFLY-722. ----------------------------------- Release Notes Text: A deployment overlay can be used to override the war's jboss-web.xml with whatever content is desired. Given that that is a generic mechanism, I don't see us adding bespoke subsystem-specific configuration overrides to the deployment resources themselves. Fix Version/s: (was: Awaiting Volunteers) Resolution: Won't Do > Cannot change WAR file's context URL when deploying via console > --------------------------------------------------------------- > > Key: WFLY-722 > URL: https://issues.jboss.org/browse/WFLY-722 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Reporter: Lukáš Petrovický > Labels: eap6-ux > > I'm trying to deploy Guvnor 5.3 WAR file using the console. I can change the name of the deployment, but not the context URL. > The console properly tells me that it isn't possible and doesn't allow the form to submit. However, I think it *should* be possible - we don't want the users to edit XML files, do we? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1102) Increase Test Coverage of Domain Management Security Options

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1102?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-752 to WFCORE-1102: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-1102 (was: WFLY-752) Component/s: Domain Management Security Test Suite (was: Domain Management) (was: Security) (was: Test Suite) Fix Version/s: (was: Awaiting Volunteers) > Increase Test Coverage of Domain Management Security Options > ------------------------------------------------------------ > > Key: WFCORE-1102 > URL: https://issues.jboss.org/browse/WFCORE-1102 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security, Test Suite > Reporter: Darran Lofthouse > Labels: testsuite > > Presently there is plenty of testing relating to the default security options but now we need coverage of the non default options especially SSL. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-738) Add clear cache operation on cache container and cache (accessible via admin console)

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-738?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated WFLY-738: ---------------------------------- Component/s: (was: Domain Management) > Add clear cache operation on cache container and cache (accessible via admin console) > ------------------------------------------------------------------------------------- > > Key: WFLY-738 > URL: https://issues.jboss.org/browse/WFLY-738 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Reporter: Guillaume Grossetie > Assignee: Paul Ferraro > Fix For: Awaiting Volunteers > > > Add operation on infinispan subsystem to clear cache at cache container level (ie. clear all caches for the container) and at cache level. > The implementation of the clear operation just calls the method #clear() on the org.infinispan.Cache interface. If needed we can clear the associated CacheStore (make it optional ?) and handle more complex cases. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2015