October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3336) Not able to separate application(EAR) logging with the use of logging profile

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3336?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-3336: ---------------------------------- Attachment: logging-profile.zip > Not able to separate application(EAR) logging with the use of logging profile > ----------------------------------------------------------------------------- > > Key: WFCORE-3336 > URL: https://issues.jboss.org/browse/WFCORE-3336 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Attachments: 01933631-new.tar.gz, logging-profile.zip > > > Two ear files are deployed on EAP instance and both are configured to use different logging profile through EAR/META-INF/MANIFEST.MF file. > WAR file from EAR uses some libraries those are present in the "lib" folder of each ear file. Application1.ear which logs in app1.log and Application2.ear which logs in app2.log. > when we access application we can see logging from EAR1 into EAR2 log file . -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3336) Not able to separate application(EAR) logging with the use of logging profile

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3336?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-3336: --------------------------------------- Since the library doing the logging is a shared in the EAR it looks like when first invoked it's seeing the log context from the first WAR in the EAR that uses it. This should see whichever log context belongs to the EAR not either of the WAR's. What this means is that any libraries in the EAR's {{lib}} directory should be using the EAR's log context. In the case of the attached example the shared library should be using the system log context since the EAR does not have a logging profile associated with it. > Not able to separate application(EAR) logging with the use of logging profile > ----------------------------------------------------------------------------- > > Key: WFCORE-3336 > URL: https://issues.jboss.org/browse/WFCORE-3336 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Attachments: 01933631-new.tar.gz > > > Two ear files are deployed on EAP instance and both are configured to use different logging profile through EAR/META-INF/MANIFEST.MF file. > WAR file from EAR uses some libraries those are present in the "lib" folder of each ear file. Application1.ear which logs in app1.log and Application2.ear which logs in app2.log. > when we access application we can see logging from EAR1 into EAR2 log file . -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3336) Not able to separate application(EAR) logging with the use of logging profile

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3336?page=com.atlassian.jira.plugi... ] James Perkins moved JBEAP-13387 to WFCORE-3336: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-3336 (was: JBEAP-13387) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Logging (was: Logging) Affects Version/s: (was: 7.0.5.GA) > Not able to separate application(EAR) logging with the use of logging profile > ----------------------------------------------------------------------------- > > Key: WFCORE-3336 > URL: https://issues.jboss.org/browse/WFCORE-3336 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Attachments: 01933631-new.tar.gz > > > Two ear files are deployed on EAP instance and both are configured to use different logging profile through EAR/META-INF/MANIFEST.MF file. > WAR file from EAR uses some libraries those are present in the "lib" folder of each ear file. Application1.ear which logs in app1.log and Application2.ear which logs in app2.log. > when we access application we can see logging from EAR1 into EAR2 log file . -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1384) Fix the DER encoding of the subject key identifier extension

by Farah Juma (JIRA)

Farah Juma created ELY-1384: ------------------------------- Summary: Fix the DER encoding of the subject key identifier extension Key: ELY-1384 URL: https://issues.jboss.org/browse/ELY-1384 Project: WildFly Elytron Issue Type: Bug Components: X.500 Reporter: Farah Juma Assignee: Farah Juma It should be defined as follows as per [RFC 5280 Section 4.2.1.2 |https://tools.ietf.org/html/rfc5280#section-4.2.1.2]: {code} SubjectKeyIdentifier ::= KeyIdentifier KeyIdentifier ::= OCTET STRING {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3311) embedded server --std-out=discard still causes log output to be shown

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3311?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3311: ------------------------------------- Comment: was deleted (was: [~jamezp] I assumed this could be resolved with the logging upgrade.) > embedded server --std-out=discard still causes log output to be shown > --------------------------------------------------------------------- > > Key: WFCORE-3311 > URL: https://issues.jboss.org/browse/WFCORE-3311 > Project: WildFly Core > Issue Type: Bug > Reporter: Ken Wills > Assignee: James Perkins > Fix For: 4.0.0.Alpha1 > > > [disconnected /] embed-server --std-out=discard > 10:27:43,671 INFO [org.jboss.modules] (CLI command executor) JBoss Modules version 1.6.1.Final > 10:27:43,698 INFO [org.jboss.as] (MSC service thread 2-8) WFLYSRV0049: WildFly Core 4.0.0.Alpha1-SNAPSHOT "Kenny" starting > ... etc -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3311) embedded server --std-out=discard still causes log output to be shown

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3311?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3311: ------------------------------------- Comment: was deleted (was: Reopening in case there was more work planned.) > embedded server --std-out=discard still causes log output to be shown > --------------------------------------------------------------------- > > Key: WFCORE-3311 > URL: https://issues.jboss.org/browse/WFCORE-3311 > Project: WildFly Core > Issue Type: Bug > Reporter: Ken Wills > Assignee: James Perkins > Fix For: 4.0.0.Alpha1 > > > [disconnected /] embed-server --std-out=discard > 10:27:43,671 INFO [org.jboss.modules] (CLI command executor) JBoss Modules version 1.6.1.Final > 10:27:43,698 INFO [org.jboss.as] (MSC service thread 2-8) WFLYSRV0049: WildFly Core 4.0.0.Alpha1-SNAPSHOT "Kenny" starting > ... etc -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2235) Intermittent module loading failure in InterdependentDeploymentTestCase

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-2235: ---------------------------------------- Assignee: Richard Opalka [~ropalka] I'm assigning this to you since per our chats you've got this fixed in MSC and an MSC upgrade will take care of it. When the upgrade comes in https://github.com/wildfly/wildfly-core/pull/2871 should be reverted. That PR was an alternative to putting @Ignore on the test, one that should make the failures with the current code rare without completely losing coverage. > Intermittent module loading failure in InterdependentDeploymentTestCase > ----------------------------------------------------------------------- > > Key: WFCORE-2235 > URL: https://issues.jboss.org/browse/WFCORE-2235 > Project: WildFly Core > Issue Type: Bug > Components: Modules, Server > Affects Versions: 3.0.0.Alpha22 > Reporter: Brian Stansberry > Assignee: Richard Opalka > Attachments: WFCORE-2235svcdump.txt > > > InterdependentDeploymentTestCase tests deployment handling of a set of interdependent deployments, where some of the dependencies are optional. > The test intermittently fails due to a ModuleLoadException while deploying one of the modules: > https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFlyCore... > The most notable bit of info in the log is: > {code} > 17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.interrelated-c.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed to load module: deployment.interrelated-c.jar > at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77) > 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: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar > at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834) > at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472) > at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457) > at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370) > at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147) > at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387) > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282) > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270) > at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68) > ... 6 more > {code} > The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The failure occurs during execution of a management op that redeploys interrelated-a.jar. FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on interrelated-c.jar. > The full stdout output for the failed test in the above linked CI run also includes a dump of all MSC services following the failure. Note though that the failure does not result in MSC not obtaining stability. Inability to reach stability was the initial problem that led to the introduction of this test (see https://github.com/wildfly/wildfly-core/pull/2099.) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3335) Allow read-resource users to specify that attrbutes should be organized by attribute group

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3335: ---------------------------------------- Summary: Allow read-resource users to specify that attrbutes should be organized by attribute group Key: WFCORE-3335 URL: https://issues.jboss.org/browse/WFCORE-3335 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Reporter: Brian Stansberry Priority: Minor Currently the read-resource output reports all attributes in a flat list, so the relationship between any attributes that are in an attribute-group is lost.[1] But, the output of read-resource an already be customized in various ways via operations parameters, so I see no reason we couldn't add a param to customize the representation of attributes. An 'attributes-by-group' param could be used to trigger moving away from the flat list. Ungrouped attributes would appear first, followed by the groups. Then there is a node named "attribute-group", the children of which are the group names, and the children of each group name are its attributes. This somewhat makes the term "attribute-group" a reserved word. To help mitigate that, if any ungrouped attribute or resource child type is named "attribute-group" (unlikely but possible), then the attributes for that resource will not be reported in grouped manner the response includes a warning header stating this. A transformer would need to be used with mixed domain. I think it would have to reject the op (or perhaps add a response warning header), as I don't see how we could reliably transform an unsorted response from a slave that didn't understand this param. The DC would not have reliable information to know what the groups are on the slave (which may have a different model than the DC.) THE VERY FIRST STEP ON THIS MUST BE SORTING OUT THE MIXED DOMAIN QUESTION. If we can't sort that in an acceptable manner, we won't implement this. Conceptually the same kind of thing could be applied to read-resource-description, but that is *not* in the scope of this RFE. The r-r-d already reports the attribute-group info for each attribute, so the value is less, while including r-r-d would basically be doubling the amount of work involved. [1] I believe the sorting of the flat list is currently by group, but since the group names are not shown that representation is not visually clear, and there's a JIRA to fix the resulting confusing output by always sorting alphabetically. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9420) Cluster partitions can take up to cca 2 minutes to merge

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9420?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9420: --------------------------------- Summary: Cluster partitions can take up to cca 2 minutes to merge (was: Cluster partitions can take cca 2 minutes to merge) > Cluster partitions can take up to cca 2 minutes to merge > -------------------------------------------------------- > > Key: WFLY-9420 > URL: https://issues.jboss.org/browse/WFLY-9420 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.CR1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Labels: partition_handling > > Using the {{MERGE3}} protocol, it can take significantly longer than {{max_interval}} for merge to happen. > The info sender interval is up to 45 seconds > {code:java} > public long nextInterval() { > return Math.max(min_interval, Util.random(max_interval) + max_interval/2); > } > {code} > and the view consistency checker interval is 48 seconds > {code:java} > protected long computeCheckInterval() { > return (long)(max_interval * 1.6); > } > {code} > which depending on the timing can take significant amount of time. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9420) Cluster partitions can take cca 2 minutes to merge

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9420?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9420: --------------------------------- Summary: Cluster partitions can take cca 2 minutes to merge (was: Cluster partitions can take up to 2 minutes to merge) > Cluster partitions can take cca 2 minutes to merge > -------------------------------------------------- > > Key: WFLY-9420 > URL: https://issues.jboss.org/browse/WFLY-9420 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.CR1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Labels: partition_handling > > Using the {{MERGE3}} protocol, it can take significantly longer than {{max_interval}} for merge to happen. > The info sender interval is up to 45 seconds > {code:java} > public long nextInterval() { > return Math.max(min_interval, Util.random(max_interval) + max_interval/2); > } > {code} > and the view consistency checker interval is 48 seconds > {code:java} > protected long computeCheckInterval() { > return (long)(max_interval * 1.6); > } > {code} > which depending on the timing can take significant amount of time. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2017