March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBFORUMS-109) BBCode support for standalone version

by Ryszard Kozmik (JIRA)

BBCode support for standalone version ------------------------------------- Key: JBFORUMS-109 URL: http://jira.jboss.com/jira/browse/JBFORUMS-109 Project: JBoss Forums Issue Type: Task Components: Forum Enhancements Reporter: Ryszard Kozmik Fix For: 1.0.0 Alpha BBCode parser is now working only in portal environment. We need make it work as a standalone too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 weeks

4
5
0 / 0

[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender

by Bela Ban (JIRA)

Optimization: make threads return immediately if NAKACK has another active thread for the same sender ----------------------------------------------------------------------------------------------------- Key: JGRP-457 URL: http://jira.jboss.com/jira/browse/JGRP-457 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.5 In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up. If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock. The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 months

2
3
0 / 0

[JBoss JIRA] (JBRULES-3445) DSL expander expands lines in /* */comment block

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3445: ------------------------------------ Summary: DSL expander expands lines in /* */comment block Key: JBRULES-3445 URL: https://issues.jboss.org/browse/JBRULES-3445 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco When you comment some code in dslr file, the expander still tries to expand it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

7 months, 3 weeks

3
10
0 / 0

[JBoss JIRA] (LOGTOOL-100) Remove the hasFieldFor and hasMethodFor methods in the ReturnType interface

by James Perkins (JIRA)

James Perkins created LOGTOOL-100: ------------------------------------- Summary: Remove the hasFieldFor and hasMethodFor methods in the ReturnType interface Key: LOGTOOL-100 URL: https://issues.jboss.org/browse/LOGTOOL-100 Project: Log Tool Issue Type: Task Reporter: James Perkins Assignee: James Perkins These methods are only used in validation. The validation should just handle this internally rather than keeping extra maps around. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-71) Allow messages to have expressions resolved at code generation time

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-71?page=com.atlassian.jira.plugin... ] James Perkins updated LOGTOOL-71: --------------------------------- Fix Version/s: 2.1.0.Alpha1 (was: 1.2.2.Final) > Allow messages to have expressions resolved at code generation time > ------------------------------------------------------------------- > > Key: LOGTOOL-71 > URL: https://issues.jboss.org/browse/LOGTOOL-71 > Project: Log Tool > Issue Type: Feature Request > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.1.0.Alpha1 > > > Allow messages in the {{@Message}} annotation to allow expressions in the format of: > {code} > ${property.name:default} > {code} > A warning message should be generated if the property name was not found. If not default is found an error should be generated. > The properties file needs to have the same fully qualified path and name of the interface. The properties file will not be used at runtime. There should also be an annotation processing option to allow a path to a properties file. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6448) Allow configuration of testsuite such that StandardConfigsXMLValidationUnitTestCase can deal with CI testing of a core snapshot with a new kernel xsd

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-6448: -------------------------------------- Summary: Allow configuration of testsuite such that StandardConfigsXMLValidationUnitTestCase can deal with CI testing of a core snapshot with a new kernel xsd Key: WFLY-6448 URL: https://issues.jboss.org/browse/WFLY-6448 Project: WildFly Issue Type: Enhancement Components: Domain Management, Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry StandardConfigsXMLValidationUnitTestCase fails CI tests of core whenever the core snapshot under test includes a new version of the kernel xsd. See, for example, https://github.com/wildfly/wildfly-core/pull/1366. The problem is the test picks up the new xsd version as the latest, and rejects full's standard config files for using an old xsd. This makes doing xsd updates in core a hassle. Goal is to have a way to configure CI runs for core snapshots in full to avoid this problem. System property most likely. I'm quite certain my fix will be hacky! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6415) Deprecate org.jboss.as.clustering.infinispan.subsystem.ScheduledThreadPoolResourceDefinition#keepAliveTime since it has no valid meaning

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6415?page=com.atlassian.jira.plugin.... ] Paul Ferraro reassigned WFLY-6415: ---------------------------------- Assignee: Paul Ferraro (was: Radoslav Husar) > Deprecate org.jboss.as.clustering.infinispan.subsystem.ScheduledThreadPoolResourceDefinition#keepAliveTime since it has no valid meaning > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6415 > URL: https://issues.jboss.org/browse/WFLY-6415 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Paul Ferraro > > {code} > * <p>While this class inherits from {@link ThreadPoolExecutor}, a few > * of the inherited tuning methods are not useful for it. In > * particular, because it acts as a fixed-sized pool using > * {@code corePoolSize} threads and an unbounded queue, adjustments > * to {@code maximumPoolSize} have no useful effect. Additionally, it > * is almost never a good idea to set {@code corePoolSize} to zero or > * use {@code allowCoreThreadTimeOut} because this may leave the pool > * without threads to handle tasks once they become eligible to run. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6442) Inconsistent behavior of journal object store for heuristic state

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/WFLY-6442?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated WFLY-6442: ----------------------------------- Comment: was deleted (was: The fix will be in 5.3.2.Final which is due for release tomorrow after which I will raise a PR to get it into WildFly.) > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: WFLY-6442 > URL: https://issues.jboss.org/browse/WFLY-6442 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Ondřej Chaloupka > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 10.1.0.Final > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > * enlist activemq JMS resource > * enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}} > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6442) Inconsistent behavior of journal object store for heuristic state

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/WFLY-6442?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on WFLY-6442: ---------------------------------------- The fix will be in 5.3.2.Final which is due for release tomorrow after which I will raise a PR to get it into WildFly. > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: WFLY-6442 > URL: https://issues.jboss.org/browse/WFLY-6442 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Ondřej Chaloupka > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 10.1.0.Final > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > * enlist activemq JMS resource > * enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}} > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBAS-8359) Old Hibernate Validator bundled with JBossAS6 M4

by Hardy Ferentschik (JIRA)

[ https://issues.jboss.org/browse/JBAS-8359?page=com.atlassian.jira.plugin.... ] Hardy Ferentschik reassigned JBAS-8359: --------------------------------------- Assignee: Scott Marlow (was: Hardy Ferentschik) > Old Hibernate Validator bundled with JBossAS6 M4 > ------------------------------------------------ > > Key: JBAS-8359 > URL: https://issues.jboss.org/browse/JBAS-8359 > Project: Application Server 3 4 5 and 6 > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 6.0.0.M4 > Environment: Mac OS 10.6.4 > Reporter: Ken Britton > Assignee: Scott Marlow > Fix For: No Release > > > There is an issue with validation of non-JPA POJOs in Hibernate Validator 4.0.2 that is resolved in 4.1.0 Final. This would not be an issue if JBoss AS6 M4+ was bundled with 4.1.0... but it is bundled with 4.0.2 > POJO validation issue described here: https://forum.hibernate.org/viewtopic.php?f=9&t=1001354&start=0 > Upgrade hibernate-validator.jar? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 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 March 2016