March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4398) Upgrade jsf-impl to 2.2.10-jbossorg-2

by Farah Juma (JIRA)

Farah Juma created WFLY-4398: -------------------------------- Summary: Upgrade jsf-impl to 2.2.10-jbossorg-2 Key: WFLY-4398 URL: https://issues.jboss.org/browse/WFLY-4398 Project: WildFly Issue Type: Component Upgrade Components: JSF Reporter: Farah Juma Assignee: Farah Juma Upgrade jsf-impl to 2.2.10-jbossorg-2 to include the fix for WFLY-4349 / [JAVASERVERFACES-3797 | https://java.net/jira/browse/JAVASERVERFACES-3797]. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4017) EjbClientContextSetupProcessor uses ServiceRegistry.getService()

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4017?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4017: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1156620 > EjbClientContextSetupProcessor uses ServiceRegistry.getService() > ---------------------------------------------------------------- > > Key: WFLY-4017 > URL: https://issues.jboss.org/browse/WFLY-4017 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > As no dependencies are in place there is no guarantee this service will exist. If a deployment is present at boot time it is possible that this will not be setup correctly. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4305) Script rumbles on after error

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4305?page=com.atlassian.jira.plugin.... ] Brian Stansberry reopened WFLY-4305: ------------------------------------ I'm going to revert that PR, as I've hit both of the issues Tom described in his comment. > Script rumbles on after error > ----------------------------- > > Key: WFLY-4305 > URL: https://issues.jboss.org/browse/WFLY-4305 > Project: WildFly > Issue Type: Bug > Components: Build System > Reporter: Carlo de Wolf > Assignee: Carlo de Wolf > Fix For: 9.0.0.Beta1 > > > After a failure in the script it rumbles on. > {noformat} > (master) carlo@devel01:~/work/wildfly$ ./build.sh clean > ./tools/download-maven.sh: 20: ./tools/download-maven.sh: curl: not found > Archive: maven.zip > End-of-central-directory signature not found. Either this file is not > a zipfile, or it constitutes one disk of a multi-part archive. In the > latter case the central directory and zipfile comment will be found on > the last disk(s) of this archive. > unzip: cannot find zipfile directory in one of maven.zip or > maven.zip.zip, and cannot find maven.zip.ZIP, period. > mv: cannot stat ‘apache-maven*’: No such file or directory > build.sh: Could not locate Maven; check $MVN or $MAVEN_HOME. > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1692) XSD schema does not specify a target namespace when declaring the type element

by Alessandro Giannone (JIRA)

[ https://issues.jboss.org/browse/JGRP-1692?page=com.atlassian.jira.plugin.... ] Alessandro Giannone commented on JGRP-1692: ------------------------------------------- This issue is present again in JGroups 3.6 > XSD schema does not specify a target namespace when declaring the type element > ------------------------------------------------------------------------------ > > Key: JGRP-1692 > URL: https://issues.jboss.org/browse/JGRP-1692 > Project: JGroups > Issue Type: Feature Request > Reporter: NadirX > Assignee: Tristan Tarrant > Fix For: 3.4 > > > Validator error: Error resolving component 'ConfigType'. It was detected that 'ConfigType' has no namespace, but components with no target namespace are not referenceable from schema document 'null'. If 'ConfigType' is intended to have a namespace, perhaps a prefix needs to be provided. If it is intended that 'ConfigType' has no namespace, then an 'import' without a "namespace" attribute should be added to 'null'. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] David Lloyd commented on LOGMGR-120: ------------------------------------ Yeah that's the plan. The system property is only there to opt in so only people actually using the functionality would pay the performance penalty of checking a thread local on every log message (which will be fairly substantial). > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by Matthew Robson (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] Matthew Robson commented on LOGMGR-120: --------------------------------------- >From the usage point of view, you would want to be able to enable / use this on demand or as necessary. I think a system property would be useful to completely opt-in to this functionality, but once it's enabled, it should be dynamic. > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] David Lloyd commented on LOGMGR-120: ------------------------------------ The only reason we need the system property is because thread local access is very slow compared to our existing volatile int read. So this functionality would have to be enabled by a boolean constant field that we initialize from a system property so that C2 can eliminate the extra code completely when it isn't enabled, something like this: {code} final int effectiveLevel = loggerNode.getEffectiveLevel(); if ((level.intValue() < effectiveLevel || effectiveLevel == OFF_INT) && !(PER_THREAD_ENABLED && level.intValue() < threadLocal.get().intValue())) { return; } {code} If C2 compiles this code and PER_THREAD_ENABLED is false, it reduces like this: {code} if ((level.intValue() < effectiveLevel || effectiveLevel == OFF_INT) && !(PER_THREAD_ENABLED && level.intValue() < threadLocal.get().intValue())) { // becomes: if ((level.intValue() < effectiveLevel || effectiveLevel == OFF_INT) && !(false && level.intValue() < threadLocal.get().intValue())) { // becomes: if ((level.intValue() < effectiveLevel || effectiveLevel == OFF_INT) && !(false)) { // becomes: if ((level.intValue() < effectiveLevel || effectiveLevel == OFF_INT) && true) { // becomes: if (level.intValue() < effectiveLevel || effectiveLevel == OFF_INT) { // ...which is the original code == just as fast. {code} > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-120: -------------------------------------- Yeah it was the way the description was worded that threw me off a bit. If we're just trying to bypass the level check on the logger to get further down the chain it might be simpler than checking a log level system property. On the other hand if what we're really after is to tell a specific thread to log at a `DEBUG` level then we need a different approach. I suppose the later is more versatile though. > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] David Lloyd commented on LOGMGR-120: ------------------------------------ I think it relates to the closed PR which was about adding a thread-local log level which can be set up to override the logger's log level. This would be a special logmanager API that would only be enabled if some system property were set which configured it. > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-120: -------------------------------------- Is the goal here to pass messages through a filter regardless of the log level? > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 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 March 2015