December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-405) Filesystem deployment scanner for a managed domain

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-405?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1017 to WFCORE-405: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-405 (was: WFLY-1017) Component/s: Domain Management (was: Domain Management) > Filesystem deployment scanner for a managed domain > -------------------------------------------------- > > Key: WFCORE-405 > URL: https://issues.jboss.org/browse/WFCORE-405 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Environment: Ubuntu 12.04 Os , JBOSS As 7.1.0 final > Reporter: hitesh yadav > Original Estimate: 1 day, 4 hours > Remaining Estimate: 1 day, 4 hours > > Is there any folder or path at which if any .war is put, in such a way that when JBOSS AS 7.1.0 start in domain mode the .war file deploy in Master node and it's related slave Node. > For Example......... In standalone mode if we put .war file in /jboss-as-7.1.0.Final/standalone/deployments/ folder and start the JBOSS AS 7.1.0 in standalone mode ,the .war deploy properly.......i want same thing domain mode, in other-server-group ..... > Means the requirement is that the .war file should put in one folder and when JBOSS AS 7.1.0 start in domain mode the .war file should deploy in other-server-group ............. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-403) Evaluate making operation "composite" EntryType.PUBLIC

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-403?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1315 to WFCORE-403: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-403 (was: WFLY-1315) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Evaluate making operation "composite" EntryType.PUBLIC > ------------------------------------------------------ > > Key: WFCORE-403 > URL: https://issues.jboss.org/browse/WFCORE-403 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > When the composite operation handler is registered, it's marked as EntryType.PRIVATE. This operation really isn't private; any reasonable management client will need to invoke it. > Changing it may have some implications though; we need to evaluate those. The biggest is the operation metadata cannot be complete, because the step parameter elements cannot be fully described. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-398) Avoid running out of threads when connecting to the DC from a slave to pull down missing data

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-398?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-315 to WFCORE-398: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-398 (was: WFLY-315) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Avoid running out of threads when connecting to the DC from a slave to pull down missing data > --------------------------------------------------------------------------------------------- > > Key: WFCORE-398 > URL: https://issues.jboss.org/browse/WFCORE-398 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Emanuel Muckenhuber > Priority: Blocker > Fix For: 1.0.0.Beta1 > > > For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC. > The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-399) Domain Management - Support for database connection pool in non AS process.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-399?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-434 to WFCORE-399: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-399 (was: WFLY-434) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Domain Management - Support for database connection pool in non AS process. > --------------------------------------------------------------------------- > > Key: WFCORE-399 > URL: https://issues.jboss.org/browse/WFCORE-399 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > We need to support authentication for users stored in database, the domain management is in a non-AS process so we also need a pool of database connections. > These connections will be used to read only from the database, other than the isolation offered by the driver we should not require any advanced transaction support. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

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

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-400?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-571 to WFCORE-400: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-400 (was: WFLY-571) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Remove <any-ipv4-address/> and <any-ipv6-address> > ------------------------------------------------- > > Key: WFCORE-400 > URL: https://issues.jboss.org/browse/WFCORE-400 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > These options have no reliable semantic (see, for example, WFLY-533) and should be removed. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-401) Consider using a "describe" notion for providing the model to slaves on registration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-401?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-568 to WFCORE-401: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-401 (was: WFLY-568) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.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: Emanuel Muckenhuber > Fix For: 1.0.0.Beta1 > > > 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.8#6338)

11 years, 7 months

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 moved WFLY-565 to WFCORE-402: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-402 (was: WFLY-565) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.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 > Fix For: 1.0.0.Beta1 > > > 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, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-393) Clone a profile

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-393?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1706 to WFCORE-393: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-393 (was: WFLY-1706) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.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.Beta1 > > > 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.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-394) Provide machine readable referential RBAC document with information of default security constrains

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-394?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1958 to WFCORE-394: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-394 (was: WFLY-1958) Component/s: Domain Management Security (was: Domain Management) (was: Security) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Provide machine readable referential RBAC document with information of default security constrains > -------------------------------------------------------------------------------------------------- > > Key: WFCORE-394 > URL: https://issues.jboss.org/browse/WFCORE-394 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Jakub Cechacek > Labels: rbac-filed-by-qa > Fix For: 1.0.0.Beta1 > > > This is more of a future task, but at some point we should make sure that all security constraints are configured properly (right now we have no way of telling which resources should be, for example, sensitive). Thus QE will need something to check against. As a good example of what I mean have a look at referential document for module classification [1] - although for RBAC we would like to see something more "machine-friendly" > This should be something like listing of resources classified by default as sensitive/application/... > [1] https://docspace.corp.redhat.com/docs/DOC-105009 -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-395) Improve reporting during deployment hang

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-395?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-255 to WFCORE-395: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-395 (was: WFLY-255) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Improve reporting during deployment hang > ---------------------------------------- > > Key: WFCORE-395 > URL: https://issues.jboss.org/browse/WFCORE-395 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Environment: http://java.net/jira/browse/EJB_SPEC-60 > java version "1.7.0_09" > OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-0ubuntu1~12.10.1) > OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) > Ubuntu 12.10 > Reporter: Carlo de Wolf > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > Attachments: deployment-hang-20130205.txt, server.log > > > Management Thread waits indefinitely for, what seems to be, a finished operation. > {noformat} > "management-handler-thread - 2" prio=10 tid=0x00007fa1380d0000 nid=0x7683 in Object.wait() [0x00007fa136deb000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor) > at java.lang.Object.wait(Object.java:503) > at org.jboss.as.controller.ContainerStateMonitor.awaitContainerStateChangeReport(ContainerStateMonitor.java:158) > - locked <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor) > at org.jboss.as.controller.ModelControllerImpl.awaitContainerStateChangeReport(ModelControllerImpl.java:464) > at org.jboss.as.controller.OperationContextImpl.awaitModelControllerContainerMonitor(OperationContextImpl.java:148) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:299) > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:142) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:112) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 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 December 2014