December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-216) Add ModelValidator to ensure resource model is correct

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-216?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-216: ------------------------------------------------ Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1023064|https://bugzilla.redhat.com/show_bug.cgi?id=1023064] from MODIFIED to ON_QA > Add ModelValidator to ensure resource model is correct > ------------------------------------------------------ > > Key: WFCORE-216 > URL: https://issues.jboss.org/browse/WFCORE-216 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Stefano Maestri > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha12 > > > Currently there is no validation of "requires" and "alternatives" that are specified in attribute metadata / AttributeDefinition > ModelValidator should be added as extra step handler that executes on end of MODEL phase to ensure resource model is correct. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-283) SASL_SERVER and SASL_PROTOCOL options not being passed all the way to Remoting

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-283?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-283: ------------------------------------------------ Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1168313|https://bugzilla.redhat.com/show_bug.cgi?id=1168313] from MODIFIED to ON_QA > SASL_SERVER and SASL_PROTOCOL options not being passed all the way to Remoting > ------------------------------------------------------------------------------ > > Key: WFCORE-283 > URL: https://issues.jboss.org/browse/WFCORE-283 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Remoting, Security > Affects Versions: 1.0.0.Alpha13 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-286) The SecurityRealmService should only perform a generic mapping to RealmUser if really required.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-286?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-286: ------------------------------------------------ Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1168595|https://bugzilla.redhat.com/show_bug.cgi?id=1168595] from MODIFIED to ON_QA > The SecurityRealmService should only perform a generic mapping to RealmUser if really required. > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-286 > URL: https://issues.jboss.org/browse/WFCORE-286 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > > If there is a more accurate way to calculate the RealmUser then use it. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-274) The CLI command "read-boot-errors" does not include the timestamp of the error event

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-274?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-274: ------------------------------------------------ Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1160898|https://bugzilla.redhat.com/show_bug.cgi?id=1160898] from MODIFIED to ON_QA > The CLI command "read-boot-errors" does not include the timestamp of the error event > ------------------------------------------------------------------------------------ > > Key: WFCORE-274 > URL: https://issues.jboss.org/browse/WFCORE-274 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > > The CLI command "read-boot-errors" does not include the timestamp of the error event. For anyone using this command for diagnostic purposes, the absence of an event's timestamp decreases the usefulness of the information. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-297) HC should remember the 'run' state of the server instances after crash or shutdown

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-297?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-297: --------------------------------------- Assignee: Emmanuel Hugonnet (was: Brian Stansberry) > HC should remember the 'run' state of the server instances after crash or shutdown > ---------------------------------------------------------------------------------- > > Key: WFCORE-297 > URL: https://issues.jboss.org/browse/WFCORE-297 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Wolf-Dieter Fink > Assignee: Emmanuel Hugonnet > Labels: EAP, todo > > The host controller should save which server is currently up and running. This would allow the host controller to bring up all previously running instances on a restart. > The idea is to support the same behavior that other application server (i.e WebLogic) supports. > If a server is started or stopped during the lifetime of the DC/HC it should be in the same state after shutdown the DC/HC or a system crash. > This can be achieved by an optional flag 'set-auto-start-on-start-stop' where the default is false which is the current behaviour. > If set to true, a start of the server instance will set auto-start=true and a stop auto-start=false. > If the server should not be started after a crash for any reason, this can be simple done by setting auto-start=false within the configuration, after starting the server the flag will be set b/c of the 'set-auto-start-on-start-stop' flag. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-232) Unclean shutdown of deployment scanner

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-232?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-232: --------------------------------------- Assignee: Emmanuel Hugonnet > Unclean shutdown of deployment scanner > -------------------------------------- > > Key: WFCORE-232 > URL: https://issues.jboss.org/browse/WFCORE-232 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > > I happened to see this in a testsuite log file: > {code} > 2014-11-07 02:59:41,808 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /opt/buildAgent/work/8feb0abb503148fe/testsuite/manualmode/target/deployment-test-bc636b67-df54-462d-9a13-3618a1755d3f threw Exception: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@146a4b2 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@e6cbcd[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 3] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) > at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325) > at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:530) > at java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:619) > at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:669) > at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:605) > at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.deploy(DefaultDeploymentOperations.java:61) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:449) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$UndeployScanRunnable.run(FileSystemDeploymentService.java:538) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > DeploymentScannerService is calling stopScanner() on the scanner and then is shutting down the executor. But stopScanner does not wait for in progress tasks to complete, nor do the in-progress tasks recognize that shutdown is occurring and handle any problems differently (e.g. don't toss the above in the log.) > Waiting for tasks to complete could be tricky, e.g. imagine this race: > 1) Admin submits op to shutdown/reload, which has the controller lock and is now stopping services. > 2) Scan job kicks off, finds changes and wants to modify the model, so the task is blocking waiting for the controller lock. > Deadlock. > Now, this may not be a problem, as server reload tells MSC to remove the root service on the way out (i.e. after the bit where it blocks for stability) and then MSC threads take over, allowing the op thread to continue and release the lock. The shutdown handler spawns a thread to call System.exit. > But ^^^ is just a quick look, so be cautious! -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-237) Use boot-completed notification to trigger deployment scanner "forced undeploy" scan

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-237?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-237: --------------------------------------- Assignee: Emmanuel Hugonnet > Use boot-completed notification to trigger deployment scanner "forced undeploy" scan > ------------------------------------------------------------------------------------ > > Key: WFCORE-237 > URL: https://issues.jboss.org/browse/WFCORE-237 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > > The FileSystemDeploymentService "forced-undeploy" scan is scheduled based on an arbitrary 200 ms delay. Instead inject ControlledProcessStateService, install a listener, and have the listener schedule an immediate scan when it's notified that ControlledProcessState.RUNNING has been reached. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4148) Deprecate <any-ipv4-address/> and <any-ipv6-address/>

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4148?page=com.atlassian.jira.plugin.... ] Brian Stansberry moved WFCORE-404 to WFLY-4148: ----------------------------------------------- Project: WildFly (was: WildFly Core) Key: WFLY-4148 (was: WFCORE-404) Component/s: Domain Management (was: Domain Management) Fix Version/s: 8.0.0.CR1 (was: 1.0.0.Beta1) > Deprecate <any-ipv4-address/> and <any-ipv6-address/> > ----------------------------------------------------- > > Key: WFLY-4148 > URL: https://issues.jboss.org/browse/WFLY-4148 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.0.CR1 > > > Deprecate in AS 8 to prepare for parent task in AS 9. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-404) Deprecate <any-ipv4-address/> and <any-ipv6-address/>

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-404?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-404: ------------------------------------ Parent: (was: WFCORE-400) Issue Type: Task (was: Sub-task) > Deprecate <any-ipv4-address/> and <any-ipv6-address/> > ----------------------------------------------------- > > Key: WFCORE-404 > URL: https://issues.jboss.org/browse/WFCORE-404 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > Deprecate in AS 8 to prepare for parent task in AS 9. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-402) Get core resources and operations out of the controller module

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-402?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-402: ------------------------------------ Fix Version/s: (was: 1.0.0.Beta1) > Get core resources and operations out of the controller module > -------------------------------------------------------------- > > Key: WFCORE-402 > URL: https://issues.jboss.org/browse/WFCORE-402 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > > The controller module has a lot of classes related to core resources (resource defs, op handlers, description providers for things like interfaces) that are only in there so they can be commonly accessible to both server and host-controller. This is unnecessary, since host-controller depends on server. > Either move these to server or create a separate module for this stuff; restrict the controller module to the true core ModelController stuff. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

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 December 2014