April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3893) JacORB compatibility subsystem

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-3893?page=com.atlassian.jira.plugin.... ] Tomasz Adamski closed WFLY-3893. -------------------------------- Resolution: Done > JacORB compatibility subsystem > ------------------------------ > > Key: WFLY-3893 > URL: https://issues.jboss.org/browse/WFLY-3893 > Project: WildFly > Issue Type: Feature Request > Components: IIOP > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > > Create jacorb compatibility subsystem which will be able to parse jacorb subsystem configuration, map it to iiop-openjdk configuration, and (if possible) emulate jacorb subsystem using iiop-openjdk subsystem. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 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: ------------------------------------ It sounds like what you're describing is more along the lines of consulting a Filter (instead of doing a level check) to determine if a message is logged during certain operations. Would you say that is an accurate assessment? > 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 > Attachments: force_logging.patch > > > 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)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2455) Provide a way to add custom XAResource frameworks to the transaction manager

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-2455?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed WFLY-2455. ------------------------------- Resolution: Rejected > Provide a way to add custom XAResource frameworks to the transaction manager > ---------------------------------------------------------------------------- > > Key: WFLY-2455 > URL: https://issues.jboss.org/browse/WFLY-2455 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Affects Versions: 8.0.0.Beta1 > Reporter: Koen Janssens > Assignee: Amos Feng > > Using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting, i can register a custom recovery manager for arjuna. > However, the ArjunaRecoveryManagerService class overwrite the recovery configuration mentioned in my jbossts-properties.xml file with a hardcoded list of recovery modules. > This makes me wonder if/how the hornetq recovery (org.hornetq.jms.server.recovery.HornetQXAResourceRecover) gets registered in wildfly.. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2455) Provide a way to add custom XAResource frameworks to the transaction manager

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-2455?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on WFLY-2455: ------------------------------------- And of course, it already exists! Sorry about that, the method you need to call is in: https://github.com/jbosstm/jboss-transaction-spi/blob/master/src/main/jav... You can see how it is resolved in a few different places: 1. Clustering https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/exte... https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/exte... 2. EJB3 https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... 3. HornetQ https://github.com/wildfly/wildfly/blob/master/messaging/src/main/java/or... (used internally in HornetQ - https://github.com/hornetq/hornetq/blob/master/hornetq-jms-server/src/mai...) > Provide a way to add custom XAResource frameworks to the transaction manager > ---------------------------------------------------------------------------- > > Key: WFLY-2455 > URL: https://issues.jboss.org/browse/WFLY-2455 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Affects Versions: 8.0.0.Beta1 > Reporter: Koen Janssens > Assignee: Amos Feng > > Using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting, i can register a custom recovery manager for arjuna. > However, the ArjunaRecoveryManagerService class overwrite the recovery configuration mentioned in my jbossts-properties.xml file with a hardcoded list of recovery modules. > This makes me wonder if/how the hornetq recovery (org.hornetq.jms.server.recovery.HornetQXAResourceRecover) gets registered in wildfly.. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4497) Fix Compiler Warnings in JPA Subsystem

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-4497?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-4497: ------------------------------------ Thanks for fixing the warnings! > Fix Compiler Warnings in JPA Subsystem > -------------------------------------- > > Key: WFLY-4497 > URL: https://issues.jboss.org/browse/WFLY-4497 > Project: WildFly > Issue Type: Patch > Components: JPA / Hibernate > Reporter: Philippe Marschall > Assignee: Scott Marlow > Fix For: 9.0.0.CR1 > > > The JPA subsystem contains several compiler warnings. Some of them (mostly related to generics) are quite easy to fix. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4497) Fix Compiler Warnings in JPA Subsystem

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-4497?page=com.atlassian.jira.plugin.... ] Scott Marlow reassigned WFLY-4497: ---------------------------------- Assignee: Philippe Marschall (was: Scott Marlow) > Fix Compiler Warnings in JPA Subsystem > -------------------------------------- > > Key: WFLY-4497 > URL: https://issues.jboss.org/browse/WFLY-4497 > Project: WildFly > Issue Type: Patch > Components: JPA / Hibernate > Reporter: Philippe Marschall > Assignee: Philippe Marschall > Fix For: 9.0.0.CR1 > > > The JPA subsystem contains several compiler warnings. Some of them (mostly related to generics) are quite easy to fix. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4497) Fix Compiler Warnings in JPA Subsystem

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-4497?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-4497: ------------------------------- Fix Version/s: 9.0.0.CR1 > Fix Compiler Warnings in JPA Subsystem > -------------------------------------- > > Key: WFLY-4497 > URL: https://issues.jboss.org/browse/WFLY-4497 > Project: WildFly > Issue Type: Patch > Components: JPA / Hibernate > Reporter: Philippe Marschall > Assignee: Philippe Marschall > Fix For: 9.0.0.CR1 > > > The JPA subsystem contains several compiler warnings. Some of them (mostly related to generics) are quite easy to fix. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

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

by John Mezzetta (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] John Mezzetta commented on LOGMGR-120: -------------------------------------- Hi David, Thanks for the quick response. I reread your comments and agree with them 100%. The thing that stands out the most is the fact that you were concerned with "thread local access is very slow compared to our existing volatile int read". This is exactly the type of discussion that we had when assessing the performance characteristics. However, the current proposed implementation isn't even close to this level of performance, as I describe above. In terms of a final solution, i don't think that the jboss log manager (the system, not the class) should store the thread local boolean to force logging. I am not sure if that is being considered, but in case it is let me explain why it would not be good for us. Under such a system, the log manager would (typically) provide an accessor and mutator method to manipulate the thread local force logging flag. Although this would be the safest implementation from the jboss perspective (since the performance would be deterministic), i don't think the system would work, at least from the perspective of our requirements. The reason for this is that when a new context begins use of a thread (i.e. doGet() servlet method is called), the force logging criteria need to be established and an algorithm needs to be executed to determine if the force logging flag is set to true or false. This algorithm is expensive, so it should only be executed once and its result should be cached for the duration of the context thread execution. To make the API for this system small and clean, we do not expose any methods to explicitly execute the algorithm. We do it automatically when the first log record is output (for the context). That is why we need the jboss log manager to invoke the forceLogging() method that we implement. We rely on the jboss logging manager to trigger the execution of the algorithm (and the subsequent cacheing), as opposed to exposing and API method to explicitly trigger the algorithm and set the thread local flag in the jboss log manager. This makes the system more robust and simpler to use. Invoking a forceLogging() method is the only real "low level" requirement that we have. The rest are just implementation details and anything that is efficient and cohesive would suffice. The implementation i describe above captures this requirement in the most succinct and efficient way possible. Actually, to prototype things and assess performance, i would likely not even implement the SPI lookup, but rather put a setter method in the jboss log manager (the class) to register the implementation. This is not really the greatest approach since the registration of the implementor of the forceLogging() method will come much later in the system, but it should be good enough for our specific purposes. And i don't expect the proposed implementation to be taken as a contribution; it is only meant to communicate our low level technical requirements. The reality is that the production solution needs to interface with the jboss cli in some way so that a regular user can specify things in the usual way. I am not even attempting to describe this solution... Regards, John > 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 > Attachments: force_logging.patch > > > 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)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-637) /subsystem=logging/log-file resource cannot cope with an expression in the path

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-637?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-637: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1203101 > /subsystem=logging/log-file resource cannot cope with an expression in the path > ------------------------------------------------------------------------------- > > Key: WFCORE-637 > URL: https://issues.jboss.org/browse/WFCORE-637 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Affects Versions: 1.0.0.Beta3 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > In log subsystem, nested expression can be used for path. > {noformat} > "path" => { > "type" => STRING, > "description" => "The filesystem path.", > "expressions-allowed" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > } > {noformat} > so if I use following log configuration : > {noformat} > <periodic-rotating-file-handler name="FILE" autoflush="true"> > <formatter> > <named-formatter name="PATTERN"/> > </formatter> > <file relative-to="jboss.server.log.dir" path="${jboss.server.name}.log"/> > <suffix value=".yyyy-MM-dd"/> > <append value="true"/> > {noformat} > server log name will be HOST_NAME.log and there is no problems to write. > However, there is no log-file resource for it. This also leads into an issue that it cannot be displayed in Admin console Log Viewer menu. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-637) /subsystem=logging/log-file resource cannot cope with an expression in the path

by Ivo Studensky (JIRA)

Ivo Studensky created WFCORE-637: ------------------------------------ Summary: /subsystem=logging/log-file resource cannot cope with an expression in the path Key: WFCORE-637 URL: https://issues.jboss.org/browse/WFCORE-637 Project: WildFly Core Issue Type: Bug Components: Logging Affects Versions: 1.0.0.Beta3 Reporter: Ivo Studensky Assignee: Ivo Studensky In log subsystem, nested expression can be used for path. {noformat} "path" => { "type" => STRING, "description" => "The filesystem path.", "expressions-allowed" => true, "nillable" => false, "min-length" => 1L, "max-length" => 2147483647L } {noformat} so if I use following log configuration : {noformat} <periodic-rotating-file-handler name="FILE" autoflush="true"> <formatter> <named-formatter name="PATTERN"/> </formatter> <file relative-to="jboss.server.log.dir" path="${jboss.server.name}.log"/> <suffix value=".yyyy-MM-dd"/> <append value="true"/> {noformat} server log name will be HOST_NAME.log and there is no problems to write. However, there is no log-file resource for it. This also leads into an issue that it cannot be displayed in Admin console Log Viewer menu. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

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