November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-482?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-482: --------------------------------- Forum Reference: http://lists.jboss.org/pipermail/wildfly-dev/2016-October/005519.html > Add log4j2 support for WildFly > ------------------------------ > > Key: WFCORE-482 > URL: https://issues.jboss.org/browse/WFCORE-482 > Project: WildFly Core > Issue Type: Task > Components: Logging > Environment: Spring 3, Hibernate, Wicket, JBoss AS7 > Reporter: Amarkanth Ranganamayna > Assignee: James Perkins > Priority: Optional > > I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2. > Looks like Jboss AS7 by default use log4j 1.x > Are you guys already working on using log4j2 ? > If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging. > Thanks, > Amar -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1912) Redeploy deployment if all missing dependencies for deployment are corrected

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1912?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1912: ------------------------------------------ The rollback behavior of the deployment scanner is configurable via the runtime-failure-causes-rollback attribute and the standard setting in our config files is 'false'. It's not practical to control this behavior from a descriptor, as the MSC services involved in deployment do not have access to any mechanism to control the decisions of the management layer about rollback. It's also not possible to control rollback based on an individual resource's configuration. Rollback behavior is per overall request, and a request can involve multiple resources. Boot basically implemented as a single request and a composite op is a single request potentially involving multiple resources. An individual resource should not be able to dictate the rollback behavior of a request that involves other resources. > Redeploy deployment if all missing dependencies for deployment are corrected > ----------------------------------------------------------------------------- > > Key: WFCORE-1912 > URL: https://issues.jboss.org/browse/WFCORE-1912 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Miroslav Novak > Assignee: Jason Greene > Labels: user_experience > > If deployment failed to deploy and later all missing dependencies for deployment are corrected then deployment would redeploy automatically. This behavior could be configurable. > For example if you deploy EJB which injects queue like: > {code} > @Resource(mappedName = "java:/jms/queue/OutQueue") > private Queue outQueue; > {code} > and administrator deploys queue later then EJB would automatically get redeployed. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7439) Implement suspend and resume support for transaction recovery service

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/WFLY-7439?page=com.atlassian.jira.plugin.... ] Gytis Trikleris commented on WFLY-7439: --------------------------------------- Pull request on Narayana fork: https://github.com/jbosstm/jboss-as/pull/58 > Implement suspend and resume support for transaction recovery service > --------------------------------------------------------------------- > > Key: WFLY-7439 > URL: https://issues.jboss.org/browse/WFLY-7439 > Project: WildFly > Issue Type: Feature Request > Components: Transactions > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > As part of the https://issues.jboss.org/browse/WFLY-4937 feature transaction recovery service needs to support suspend and resume requests. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7439) Implement suspend and resume support for transaction recovery service

by Gytis Trikleris (JIRA)

Gytis Trikleris created WFLY-7439: ------------------------------------- Summary: Implement suspend and resume support for transaction recovery service Key: WFLY-7439 URL: https://issues.jboss.org/browse/WFLY-7439 Project: WildFly Issue Type: Feature Request Components: Transactions Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Critical Fix For: 11.0.0.Alpha1 As part of the https://issues.jboss.org/browse/WFLY-4937 feature transaction recovery service needs to support suspend and resume requests. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1912) Redeploy deployment if all missing dependencies for deployment are corrected

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1912?page=com.atlassian.jira.plugi... ] Miroslav Novak edited comment on WFCORE-1912 at 11/1/16 10:28 AM: ------------------------------------------------------------------ Correct, just tried it myself. Is it possible to configure it globally so it's applied on to all deployments or directly in deployment using deployment descriptor. The idea is that if developer simply copies jar/war/ear to deployments directory and set {{rollback-on-runtime-failure=false}} for this deployment then it's no need call {code}deploy ~/tmp/luckywinner.ear --unmanaged --headers={rollback-on-runtime-failure=false}{code} was (Author: mnovak): Correct, just tried it myself. Is it possible to configure it globally so it's applied on to all deployments or directly in deployment using deployment descriptor. The idea is that if developer simply copies jar/war/ear to deployments directory then he can set {{rollback-on-runtime-failure=false}} for this deployment without need to call {code}deploy ~/tmp/luckywinner.ear --unmanaged --headers={rollback-on-runtime-failure=false}{code} > Redeploy deployment if all missing dependencies for deployment are corrected > ----------------------------------------------------------------------------- > > Key: WFCORE-1912 > URL: https://issues.jboss.org/browse/WFCORE-1912 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Miroslav Novak > Assignee: Jason Greene > Labels: user_experience > > If deployment failed to deploy and later all missing dependencies for deployment are corrected then deployment would redeploy automatically. This behavior could be configurable. > For example if you deploy EJB which injects queue like: > {code} > @Resource(mappedName = "java:/jms/queue/OutQueue") > private Queue outQueue; > {code} > and administrator deploys queue later then EJB would automatically get redeployed. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5227) Move security-manager subsystem from WildFly to WildFly Core

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-5227?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-5227: ---------------------------------------- [~luck3y] Please coordinate with [~dlofthouse] on this, and do it when he wants it. He is the guru on the elytron schedule and the elytron schedule is the key factor in all such decisions. > Move security-manager subsystem from WildFly to WildFly Core > ------------------------------------------------------------ > > Key: WFLY-5227 > URL: https://issues.jboss.org/browse/WFLY-5227 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Reporter: Josef Cacek > Assignee: Ken Wills > Priority: Critical > > It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core. > More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html...] thread on {{wildfly-dev}} mailing list. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1912) Redeploy deployment if all missing dependencies for deployment are corrected

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1912?page=com.atlassian.jira.plugi... ] Miroslav Novak commented on WFCORE-1912: ---------------------------------------- Correct, just tried it myself. Is it possible to configure it globally so it's applied on to all deployments or directly in deployment using deployment descriptor. The idea is that if developer simply copies jar/war/ear to deployments directory then he can set {{rollback-on-runtime-failure=false}} for this deployment without need to call {code}deploy ~/tmp/luckywinner.ear --unmanaged --headers={rollback-on-runtime-failure=false}{code} > Redeploy deployment if all missing dependencies for deployment are corrected > ----------------------------------------------------------------------------- > > Key: WFCORE-1912 > URL: https://issues.jboss.org/browse/WFCORE-1912 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Miroslav Novak > Assignee: Jason Greene > Labels: user_experience > > If deployment failed to deploy and later all missing dependencies for deployment are corrected then deployment would redeploy automatically. This behavior could be configurable. > For example if you deploy EJB which injects queue like: > {code} > @Resource(mappedName = "java:/jms/queue/OutQueue") > private Queue outQueue; > {code} > and administrator deploys queue later then EJB would automatically get redeployed. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5227) Move security-manager subsystem from WildFly to WildFly Core

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-5227?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-5227: ----------------------------------- [~luck3y] you should know never to ask that question ;) > Move security-manager subsystem from WildFly to WildFly Core > ------------------------------------------------------------ > > Key: WFLY-5227 > URL: https://issues.jboss.org/browse/WFLY-5227 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Reporter: Josef Cacek > Assignee: Ken Wills > Priority: Critical > > It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core. > More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html...] thread on {{wildfly-dev}} mailing list. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5227) Move security-manager subsystem from WildFly to WildFly Core

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFLY-5227?page=com.atlassian.jira.plugin.... ] Ken Wills commented on WFLY-5227: --------------------------------- Hi [~jtymel] & All, I'm aiming to have this tested on my side and ready to go by end of this week, if that works for everyone else? Does anyone have timing they would prefer? > Move security-manager subsystem from WildFly to WildFly Core > ------------------------------------------------------------ > > Key: WFLY-5227 > URL: https://issues.jboss.org/browse/WFLY-5227 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Reporter: Josef Cacek > Assignee: Ken Wills > Priority: Critical > > It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core. > More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html...] thread on {{wildfly-dev}} mailing list. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1912) Redeploy deployment if all missing dependencies for deployment are corrected

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1912?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFCORE-1912 at 11/1/16 10:09 AM: -------------------------------------------------------------------- I won't reject this because it's a valid request, but I'd be surprised if any activity happens on it for a long time as it's not clear at all how to do such a thing. The data structures that record all this dependency state are tied to the objects that are created as part of deployment and are discarded on undeploy or rollback. Keeping all that data around somehow and then being able to make use of it later would be complex. I'm not clear though on why the existing rollback-on-runtime-failure=false behavior doesn't suffice. The behavior at boot is to not roll back. I'll play a bit to see if I can understand the problem; perhaps some detail has changed that I've forgotten about. was (Author: brian.stansberry): I won't reject this because it's a valid request, but I'd be surprised if any activity happens on it for a long time as it's not clear at all how to do such a thing. The data structures that record all this dependency state are tied to the objects that are created as part of deployment and are discarded on undeploy. Keeping all that data around somehow and then being able to make use of it later would be complex. I'm not clear though on why the existing rollback-on-runtime-failure=false behavior doesn't suffice. The behavior at boot is to not roll back. I'll play a bit to see if I can understand the problem; perhaps some detail has changed that I've forgotten about. > Redeploy deployment if all missing dependencies for deployment are corrected > ----------------------------------------------------------------------------- > > Key: WFCORE-1912 > URL: https://issues.jboss.org/browse/WFCORE-1912 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Miroslav Novak > Assignee: Jason Greene > Labels: user_experience > > If deployment failed to deploy and later all missing dependencies for deployment are corrected then deployment would redeploy automatically. This behavior could be configurable. > For example if you deploy EJB which injects queue like: > {code} > @Resource(mappedName = "java:/jms/queue/OutQueue") > private Queue outQueue; > {code} > and administrator deploys queue later then EJB would automatically get redeployed. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 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 2016