May 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBLOGGING-104) MDC Logging not appearing in server.log

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-104?page=com.atlassian.jira.plu... ] James Perkins commented on JBLOGGING-104: ----------------------------------------- You would need to put a value of {{entry1}} and {{entry2}} into MDC in order for this to work. The pattern is {{%x{mdcKey}}} where mdcKey is the key for the MDC value you want to see. > MDC Logging not appearing in server.log > --------------------------------------- > > Key: JBLOGGING-104 > URL: https://issues.jboss.org/browse/JBLOGGING-104 > Project: JBoss Logging > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jboss-logging-logmanager, jboss-logging-spi > Affects Versions: 3.1.4.GA > Environment: Local > Reporter: ArunPrasath Rajmohan > Assignee: James Perkins > Original Estimate: 1 day, 4 hours > Remaining Estimate: 1 day, 4 hours > > Hi > I am trying to log using org.jboss.logging.MDC but the log entry is not found in server.log > Steps followed: > 1.Maven Dependency Used: > {code:xml} > <dependency> > <groupId>org.jboss.logging</groupId> > <artifactId>jboss-logging</artifactId> > <version>3.1.4.GA</version> > </dependency> > {code} > 2.Athe below code in the controller > org.jboss.logging.MDC.put("MDC Worked", new String("MDC Worked")); > 3.Placed the jboss-logging.xml inside META-INF folder of the web application. > The content of jboss-logging.xml is as follows: > {code:xml} > <periodic-rotating-file-handler > file-name="${jboss.server.log.dir}/server.log" > name="FILE" > autoflush="true" > append="true" > suffix=".yyyy-MM-dd"> > > <error-manager> > <only-once/> > </error-manager> > > <formatter> > <pattern-formatter pattern="%d %-5p [%c] (%t) [%X{entry1}, %X{entry2}] %s%E%n"/> > </formatter> > </periodic-rotating-file-handler> > {code} > Problem: > There are no errors but the log entry is not found in the server.log > Regards > Arun > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-104) MDC Logging not appearing in server.log

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-104?page=com.atlassian.jira.plu... ] James Perkins updated JBLOGGING-104: ------------------------------------ Description: Hi I am trying to log using org.jboss.logging.MDC but the log entry is not found in server.log Steps followed: 1.Maven Dependency Used: {code:xml} <dependency> <groupId>org.jboss.logging</groupId> <artifactId>jboss-logging</artifactId> <version>3.1.4.GA</version> </dependency> {code} 2.Athe below code in the controller org.jboss.logging.MDC.put("MDC Worked", new String("MDC Worked")); 3.Placed the jboss-logging.xml inside META-INF folder of the web application. The content of jboss-logging.xml is as follows: {code:xml} <periodic-rotating-file-handler file-name="${jboss.server.log.dir}/server.log" name="FILE" autoflush="true" append="true" suffix=".yyyy-MM-dd"> <error-manager> <only-once/> </error-manager> <formatter> <pattern-formatter pattern="%d %-5p [%c] (%t) [%X{entry1}, %X{entry2}] %s%E%n"/> </formatter> </periodic-rotating-file-handler> {code} Problem: There are no errors but the log entry is not found in the server.log Regards Arun was: Hi I am trying to log using org.jboss.logging.MDC but the log entry is not found in server.log Steps followed: 1.Maven Dependency Used: <dependency> <groupId>org.jboss.logging</groupId> <artifactId>jboss-logging</artifactId> <version>3.1.4.GA</version> </dependency> 2.Athe below code in the controller org.jboss.logging.MDC.put("MDC Worked", new String("MDC Worked")); 3.Placed the jboss-logging.xml inside META-INF folder of the web application. The content of jboss-logging.xml is as follows: <periodic-rotating-file-handler file-name="${jboss.server.log.dir}/server.log" name="FILE" autoflush="true" append="true" suffix=".yyyy-MM-dd"> <error-manager> <only-once/> </error-manager> <formatter> <pattern-formatter pattern="%d %-5p [%c] (%t) [%X{entry1}, %X{entry2}] %s%E%n"/> </formatter> </periodic-rotating-file-handler> Problem: There are no errors but the log entry is not found in the server.log Regards Arun > MDC Logging not appearing in server.log > --------------------------------------- > > Key: JBLOGGING-104 > URL: https://issues.jboss.org/browse/JBLOGGING-104 > Project: JBoss Logging > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jboss-logging-logmanager, jboss-logging-spi > Affects Versions: 3.1.4.GA > Environment: Local > Reporter: ArunPrasath Rajmohan > Assignee: James Perkins > Original Estimate: 1 day, 4 hours > Remaining Estimate: 1 day, 4 hours > > Hi > I am trying to log using org.jboss.logging.MDC but the log entry is not found in server.log > Steps followed: > 1.Maven Dependency Used: > {code:xml} > <dependency> > <groupId>org.jboss.logging</groupId> > <artifactId>jboss-logging</artifactId> > <version>3.1.4.GA</version> > </dependency> > {code} > 2.Athe below code in the controller > org.jboss.logging.MDC.put("MDC Worked", new String("MDC Worked")); > 3.Placed the jboss-logging.xml inside META-INF folder of the web application. > The content of jboss-logging.xml is as follows: > {code:xml} > <periodic-rotating-file-handler > file-name="${jboss.server.log.dir}/server.log" > name="FILE" > autoflush="true" > append="true" > suffix=".yyyy-MM-dd"> > > <error-manager> > <only-once/> > </error-manager> > > <formatter> > <pattern-formatter pattern="%d %-5p [%c] (%t) [%X{entry1}, %X{entry2}] %s%E%n"/> > </formatter> > </periodic-rotating-file-handler> > {code} > Problem: > There are no errors but the log entry is not found in the server.log > Regards > Arun > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-475) Drools condition part always use MVEL strict mode (extended classes doen't get properties of super class )

by Shailesh T (JIRA)

[ https://issues.jboss.org/browse/DROOLS-475?page=com.atlassian.jira.plugin... ] Shailesh T closed DROOLS-475. ----------------------------- Thanks for immediate fix. Verified with 'drools-distribution-6.1.0.Beta4', This is working. > Drools condition part always use MVEL strict mode (extended classes doen't get properties of super class ) > ---------------------------------------------------------------------------------------------------------- > > Key: DROOLS-475 > URL: https://issues.jboss.org/browse/DROOLS-475 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.1.Final > Environment: JDK 6, MVEL as default, with strict-mode set to false with file META-INF/drools.default.packagebuilder.conf with following entries > drools.dialect.default = mvel > drools.dialect.java = org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration > drools.dialect.java.compiler = ECLIPSE > drools.dialect.mvel = org.drools.compiler.rule.builder.dialect.mvel.MVELDialectConfiguration > drools.dialect.mvel.strict = false > Reporter: Shailesh T > Assignee: Mario Fusco > Priority: Critical > Labels: drools, mvel, strict-mode > Fix For: 6.1.0.Beta4 > > Attachments: BasicInclude.drl > > > Even after setting MVEL strict mode to false, condition part of drools works using strict mode and can't work with Inherited getters of HashMap (Breaks lot of working rules from 5.4) > Error: [Error: unable to resolve method using strict-mode: defaultpkg.Test.Price()] > [Near : {... Price < 100 ....}] > ... > t: HashMap( > Price < 11 > ) > .. > Does work but > import java.util.HashMap; > declare HashMap > end > declare Test extends HashMap > end > t: Test( > Price<100 > ) > doesn't work (please see full rules in steps to reproduce) > Even condition > this["OtherPrices"]["OldPrice"] < 9 > does work for Map but not for inherited Test class > (applicable but not included in sample code to reproduce issue, added drl for this as attachment) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SASL-49) Custom Property to Prefer JDK Mechanisms

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/SASL-49?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on SASL-49: --------------------------------- As an alternative you could use {{Security.getProviders()}} with an appropriate filter and filter the list that way, which wouldn't require any nonstandard behavior at all. > Custom Property to Prefer JDK Mechanisms > ---------------------------------------- > > Key: SASL-49 > URL: https://issues.jboss.org/browse/SASL-49 > Project: JBoss SASL Provider > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.0.Alpha1 > > > This is primarily for testing although it could be used for other purposes, a new custom property should be added to JBoss SASL which will cause mechanisms that duplicate JDK supplied mechanisms to avoid being used themselves. > i.e. Even though JBoss SASL could supply an implementation for that mechanisms it will let the JDK supplied version win through. > For testing this will enable interoperability testing between our mechanisms and the JDK mechanisms, for end users they could use JBoss SASL for the new mechanisms we supply whilst still using the JDK for the mechanisms it supplied. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3418) deployed applications are not distributed to host controller(s)

by Tom Fonteyne (JIRA)

[ https://issues.jboss.org/browse/WFLY-3418?page=com.atlassian.jira.plugin.... ] Tom Fonteyne updated WFLY-3418: ------------------------------- Workaround Description: Do not promote an HC. Instead have a backup of the DC and restore when needed. > deployed applications are not distributed to host controller(s) > --------------------------------------------------------------- > > Key: WFLY-3418 > URL: https://issues.jboss.org/browse/WFLY-3418 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.1.0.CR2 > Environment: Wildfly 8.1.0 CR5 domain mode > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > > when a new HC is brought up into an existing DC/HC environment, it does not receive a copy of all deployed applications (e.g. the "content" folder) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3418) deployed applications are not distributed to host controller(s)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3418?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3418: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1102753, https://bugzilla.redhat.com/show_bug.cgi?id=1102752 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1102753) > deployed applications are not distributed to host controller(s) > --------------------------------------------------------------- > > Key: WFLY-3418 > URL: https://issues.jboss.org/browse/WFLY-3418 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.1.0.CR2 > Environment: Wildfly 8.1.0 CR5 domain mode > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > > when a new HC is brought up into an existing DC/HC environment, it does not receive a copy of all deployed applications (e.g. the "content" folder) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3418) deployed applications are not distributed to host controller(s)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3418?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3418: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1102753 > deployed applications are not distributed to host controller(s) > --------------------------------------------------------------- > > Key: WFLY-3418 > URL: https://issues.jboss.org/browse/WFLY-3418 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.1.0.CR2 > Environment: Wildfly 8.1.0 CR5 domain mode > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > > when a new HC is brought up into an existing DC/HC environment, it does not receive a copy of all deployed applications (e.g. the "content" folder) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3418) deployed applications are not distributed to host controller(s)

by Tom Fonteyne (JIRA)

[ https://issues.jboss.org/browse/WFLY-3418?page=com.atlassian.jira.plugin.... ] Tom Fonteyne updated WFLY-3418: ------------------------------- Summary: deployed applications are not distributed to host controller(s) (was: deployed applications are not distrubuted to host controller(s)) > deployed applications are not distributed to host controller(s) > --------------------------------------------------------------- > > Key: WFLY-3418 > URL: https://issues.jboss.org/browse/WFLY-3418 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.1.0.CR2 > Environment: Wildfly 8.1.0 CR5 domain mode > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > > when a new HC is brought up into an existing DC/HC environment, it does not receive a copy of all deployed applications (e.g. the "content" folder) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3418) deployed applications are not distrubuted to host controller(s)

by Tom Fonteyne (JIRA)

Tom Fonteyne created WFLY-3418: ---------------------------------- Summary: deployed applications are not distrubuted to host controller(s) Key: WFLY-3418 URL: https://issues.jboss.org/browse/WFLY-3418 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management Affects Versions: 8.1.0.CR2 Environment: Wildfly 8.1.0 CR5 domain mode Reporter: Tom Fonteyne Assignee: Brian Stansberry when a new HC is brought up into an existing DC/HC environment, it does not receive a copy of all deployed applications (e.g. the "content" folder) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3072) Support Referrals for security realms using LDAP for authentication or group loading.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3072?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3072: ----------------------------------------------- Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1066488|https://bugzilla.redhat.com/show_bug.cgi?id=1066488] from ON_QA to VERIFIED > Support Referrals for security realms using LDAP for authentication or group loading. > ------------------------------------------------------------------------------------- > > Key: WFLY-3072 > URL: https://issues.jboss.org/browse/WFLY-3072 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.1.0.CR2, 8.1.0.Final > > > I see the following scenarios to cover for this: - > - Authentication - A search is performed e.g against 'uid' and a referral is encountered, the URL needs to be extracted from the referral and a new connection created using the referral URL to load any additional attributes for the user, the referral URL is then used to establish the connection as the user to verify that their password is correct. > Group loading then has a couple of issues, firstly where the user was a referral. > The search for group membership information is a fresh start but now we potentially have 2 simple named and 2 distinguished names that could be referenced from the group object. We may want a config option to specify which one to actually use and even possibly use both. > Next could a group also be a referral, i.e. it contains the reference to the user as an attribute so was matched in the search but is also a referral to the true named group in another location. In this situation I suggest any iterative search takes into account the context containing the actual group definition and continues the search from there. > And then where the principal contains an attribute that references, this one should be a simple following of a referral and once followed continue the attribute loading using the new connection. > The connection manager logic is going to need reworking, ideally for a referral we should check if we have a connection definition that matches based on the URL returned otherwise we will need to try and establish a connection based on the settings of the last connection used, this probably also introduces a notion of some form of connection stack of the connections used for the current request - referrals could have us bouncing back and forth so connections should be cached and re-used where possible during authentication and group loading. > * Connection Settings * > We are going to need to support two different modes in relation to the 'java.naming.referral' property, follow and throw. > - *follow* - In this mode when the InitialDirContext encounters a referral during a search it will automatically follow it, this means automatically connecting to the server in the URL. This is fine if the remaining connection settings are valid for the alternative server e.g. same bindDN and credential. We however need to take the following into account for subsequent operations such as password validation or further queries. > - *throw* - When a referral is encountered and exception will be thrown instead, this mode should make it easier to have some more advanced referral handling logic that allows us control of which connection we subsequently use, e.g. we could not use a completely different host name to the one in the referral or use a different bind DN / credential pair. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2014