April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2730) empty target-name in constant-permission-mapper is not allowed

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2730?page=com.atlassian.jira.plugi... ] Jan Kalina reassigned WFCORE-2730: ---------------------------------- Assignee: Jan Kalina > empty target-name in constant-permission-mapper is not allowed > -------------------------------------------------------------- > > Key: WFCORE-2730 > URL: https://issues.jboss.org/browse/WFCORE-2730 > Project: WildFly Core > Issue Type: Bug > Reporter: Eva Jarkovská > Assignee: Jan Kalina > > I need to have an empty target-name because of the WebResourcePermission. But with unspecified target-name the primary underlying error message was: > | > ParseError at [row,col]:[367,5] > | > Message: "WFLYCTL0113: '' is an invalid value for parameter > | > target-name. Values must have a minimum length of 1 characters" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (LOGMGR-124) Add marker support

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-124?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-124: -------------------------------------- I'm just a bit hesitant to add a new API to the JBoss Log Manager. Both slf4j and log4j2 seem to have their own marker API and I just don't love the idea of adding yet another to the mix. However, maybe people use markers more than I thought. > Add marker support > ------------------ > > Key: LOGMGR-124 > URL: https://issues.jboss.org/browse/LOGMGR-124 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.2.Final > Reporter: Rob Heine > Priority: Optional > > The logging engine currently (talking about the one included in WF-9) does not support Markers (like in implementations like "logback" and/or "log4j2"). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8660) Naming fix for jboss-seam-int

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-8660?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-8660: ----------------------------------- Description: The rpm file "eap7-jboss-seam-int-0:7.0.0-1.GA_redhat_1.1.ep7.el6.noarch.rpm" contains jar named "jboss-seam-int-jbossas-7.0.0.GA-redhat-1.jar". The corresponding file in the the zip in the location: modules/system/layers/base/org/jboss/integration/ext-content/main/bundled/ has name jboss-seam-int.jar. Fix is to add "-jbossas-" string to the jar file name in the dist. was: The rpm file "eap7-jboss-seam-int-0:7.0.0-1.GA_redhat_1.1.ep7.el6.noarch.rpm" contains jar named "jboss-seam-int-jbossas-7.0.0.GA-redhat-1.jar". The corresponding file in the the zip in the location: modules/system/layers/base/org/jboss/integration/ext-content/main/bundled/ has name jboss-seam-int.jar. Either we remove the version part (7.0.0.GA-redhat-1), there is still difference in naming with "-jbossas-" string. Desired change is to remove "-jbossas-" string from the jar file name. > Naming fix for jboss-seam-int > ----------------------------- > > Key: WFLY-8660 > URL: https://issues.jboss.org/browse/WFLY-8660 > Project: WildFly > Issue Type: Bug > Components: Server > Reporter: Katerina Novotna > Assignee: Brian Stansberry > > The rpm file "eap7-jboss-seam-int-0:7.0.0-1.GA_redhat_1.1.ep7.el6.noarch.rpm" contains jar named "jboss-seam-int-jbossas-7.0.0.GA-redhat-1.jar". > The corresponding file in the the zip in the location: > modules/system/layers/base/org/jboss/integration/ext-content/main/bundled/ > has name jboss-seam-int.jar. > Fix is to add "-jbossas-" string to the jar file name in the dist. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (LOGMGR-30) Support automatic log file compression in FileHandler (for compressing all files in real time) and PeriodicRotatingFileHandler (for compressing upon rotation)

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-30?page=com.atlassian.jira.plugin.... ] James Perkins commented on LOGMGR-30: ------------------------------------- It's been on the back burner for a while now. It's probably something we should resurrect though. > Support automatic log file compression in FileHandler (for compressing all files in real time) and PeriodicRotatingFileHandler (for compressing upon rotation) > -------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: LOGMGR-30 > URL: https://issues.jboss.org/browse/LOGMGR-30 > Project: JBoss Log Manager > Issue Type: Feature Request > Reporter: Aleksander Adamowski > Assignee: James Perkins > Fix For: 2.1.0.Alpha2 > > > This is a follow up to JBAS-6917. > It would be nice to have an automatic compression of log files similar to the one implemented in Log4j extras: > http://logging.apache.org/log4j/companions/extras/apidocs/org/apache/log4... > "TimeBasedRollingPolicy supports automatic file compression. This feature is enabled if the value of the FileNamePattern option ends with .gz or .zip." > In JBoss Logging, I suppose this could be implemented on 2 levels: > 1) In the FileHandler (http://anonsvn.jboss.org/repos/common/jboss-logmanager/trunk/src/main/jav...) so that, with proper configuration, each log file is compressed in real time, and it exists only in compressed form from the moment of its creation. > 2) In the PeriodicRotatingFileHandler (http://anonsvn.jboss.org/repos/common/jboss-logmanager/trunk/src/main/jav...) so that with proper configuration, archival log files can be compressed the moment they are rotated (e.g. server.log.2010-05-06.gz is created instead of server.log.2010-05-06), but the current log file should be plain text. > In PeriodicRotatingFileHandler, the implementation must take into account that compression of rotated log files may take considerable time and should be performed in the background - the handler should be able to process log records at any time, particularly during rotation, without losing any. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8660) Naming fix for jboss-seam-int

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-8660?page=com.atlassian.jira.plugin.... ] Brian Stansberry moved JBEAP-10599 to WFLY-8660: ------------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8660 (was: JBEAP-10599) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Server (was: RPM) Affects Version/s: (was: 7.0.0.ER2 (Beta)) > Naming fix for jboss-seam-int > ----------------------------- > > Key: WFLY-8660 > URL: https://issues.jboss.org/browse/WFLY-8660 > Project: WildFly > Issue Type: Bug > Components: Server > Reporter: Katerina Novotna > Assignee: Brian Stansberry > > The rpm file "eap7-jboss-seam-int-0:7.0.0-1.GA_redhat_1.1.ep7.el6.noarch.rpm" contains jar named "jboss-seam-int-jbossas-7.0.0.GA-redhat-1.jar". > The corresponding file in the the zip in the location: > modules/system/layers/base/org/jboss/integration/ext-content/main/bundled/ > has name jboss-seam-int.jar. > Either we remove the version part (7.0.0.GA-redhat-1), there is still difference in naming with "-jbossas-" string. > Desired change is to remove "-jbossas-" string from the jar file name. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (LOGMGR-30) Support automatic log file compression in FileHandler (for compressing all files in real time) and PeriodicRotatingFileHandler (for compressing upon rotation)

by Rob Heine (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-30?page=com.atlassian.jira.plugin.... ] Rob Heine commented on LOGMGR-30: --------------------------------- Just for curiousity: how is the progress on this issue? > Support automatic log file compression in FileHandler (for compressing all files in real time) and PeriodicRotatingFileHandler (for compressing upon rotation) > -------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: LOGMGR-30 > URL: https://issues.jboss.org/browse/LOGMGR-30 > Project: JBoss Log Manager > Issue Type: Feature Request > Reporter: Aleksander Adamowski > Assignee: James Perkins > Fix For: 2.1.0.Alpha2 > > > This is a follow up to JBAS-6917. > It would be nice to have an automatic compression of log files similar to the one implemented in Log4j extras: > http://logging.apache.org/log4j/companions/extras/apidocs/org/apache/log4... > "TimeBasedRollingPolicy supports automatic file compression. This feature is enabled if the value of the FileNamePattern option ends with .gz or .zip." > In JBoss Logging, I suppose this could be implemented on 2 levels: > 1) In the FileHandler (http://anonsvn.jboss.org/repos/common/jboss-logmanager/trunk/src/main/jav...) so that, with proper configuration, each log file is compressed in real time, and it exists only in compressed form from the moment of its creation. > 2) In the PeriodicRotatingFileHandler (http://anonsvn.jboss.org/repos/common/jboss-logmanager/trunk/src/main/jav...) so that with proper configuration, archival log files can be compressed the moment they are rotated (e.g. server.log.2010-05-06.gz is created instead of server.log.2010-05-06), but the current log file should be plain text. > In PeriodicRotatingFileHandler, the implementation must take into account that compression of rotated log files may take considerable time and should be performed in the background - the handler should be able to process log records at any time, particularly during rotation, without losing any. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1536) Augment KieAssembler with a kjar context

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1536?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1536: ------------------------------------- Cherry-picked to branch 7.0.x with https://github.com/kiegroup/drools/commit/9f5c9cb27 > Augment KieAssembler with a kjar context > ---------------------------------------- > > Key: DROOLS-1536 > URL: https://issues.jboss.org/browse/DROOLS-1536 > Project: Drools > Issue Type: Enhancement > Reporter: Matteo Mortari > Assignee: Mario Fusco > > Currently KieAssembler are created per-runtime and cached globally, a sort of a singleton. > There is a need to have a "kjar context" so that KieAssembler might be able to cache some resources as needed on a per-kjar basis. > Currently this is not possible because indeed KieAssemblers are created at runtime singleton-like level, and unaware of the kjar context. > (a KBuilder is passed, but this would offer only a creation-time context, and a cache based on this could not realize when the related kjar context is no longer needed.) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2548) Native management interface ignores SSL/TLS based on Elytron SSL Context when remote protocol is used

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2548?page=com.atlassian.jira.plugi... ] Ken Wills reassigned WFCORE-2548: --------------------------------- Assignee: Ken Wills > Native management interface ignores SSL/TLS based on Elytron SSL Context when remote protocol is used > ----------------------------------------------------------------------------------------------------- > > Key: WFCORE-2548 > URL: https://issues.jboss.org/browse/WFCORE-2548 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ondrej Kotek > Assignee: Ken Wills > Priority: Blocker > Labels: cli, management, model-controller-client, remoting, ssl, tls > Fix For: 3.0.0.Beta16 > > > Following [1] to set management {{native-interface}} backed by SSL Context from Elytron. Using {{remote}} protocol, {{jboss-cli}} connects to server ignoring a need to have trusted client certificate. > [1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildF... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2548) Native management interface ignores SSL/TLS based on Elytron SSL Context when remote protocol is used

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2548?page=com.atlassian.jira.plugi... ] Ken Wills resolved WFCORE-2548. ------------------------------- Fix Version/s: 3.0.0.Beta16 Resolution: Done > Native management interface ignores SSL/TLS based on Elytron SSL Context when remote protocol is used > ----------------------------------------------------------------------------------------------------- > > Key: WFCORE-2548 > URL: https://issues.jboss.org/browse/WFCORE-2548 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ondrej Kotek > Assignee: Ken Wills > Priority: Blocker > Labels: cli, management, model-controller-client, remoting, ssl, tls > Fix For: 3.0.0.Beta16 > > > Following [1] to set management {{native-interface}} backed by SSL Context from Elytron. Using {{remote}} protocol, {{jboss-cli}} connects to server ignoring a need to have trusted client certificate. > [1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildF... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2733) JBossAllXmlParserRegisteringProcessor leaks deployment unit attachments on undeploy

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2733?page=com.atlassian.jira.plugi... ] Paul Ferraro moved JBEAP-10597 to WFCORE-2733: ---------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2733 (was: JBEAP-10597) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Server (was: Clustering) Affects Version/s: 3.0.0.Beta16 (was: 7.1.0.DR17) > JBossAllXmlParserRegisteringProcessor leaks deployment unit attachments on undeploy > ----------------------------------------------------------------------------------- > > Key: WFCORE-2733 > URL: https://issues.jboss.org/browse/WFCORE-2733 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 3.0.0.Beta16 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > Seen in our clustering tests for singleton deployments. > Timeline: > Node1 elected as the singleton provider > Some other node gets elected after topology change > Node1 gets elected after another topology change and logs: > {code} > 13:08:42,248 INFO [org.wildfly.clustering.server] (DistributedSingletonService - 1) WFLYCLSV0003: node1 elected as the singleton provider of the jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".installer service > 13:08:42,474 INFO [org.wildfly.clustering.server] (DistributedSingletonService - 1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".installer service > 13:08:42,476 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".STRUCTURE: WFLYSRV0153: Failed to process phase STRUCTURE of deployment "clusterbench-ee7-singleton-jbossall.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalArgumentException: Root element supplier for {http://www.jboss.com/xml/ns/javaee}jboss-app already registered > at org.jboss.staxmapper.XMLMapperImpl.registerRootElement(XMLMapperImpl.java:51) > at org.jboss.staxmapper.XMLMapperImpl.registerRootElement(XMLMapperImpl.java:46) > at org.jboss.as.server.deployment.jbossallxml.JBossAllXMLParsingProcessor.deploy(JBossAllXMLParsingProcessor.java:90) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) > ... 5 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

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 April 2017