November 2014 - 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

1 week, 6 days

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] (WFLY-670) Using "attribute" tag causes injection of null values

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-670?page=com.atlassian.jira.plugin.s... ] Tomasz Adamski resolved WFLY-670. --------------------------------- Resolution: Rejected Injecting null values on undeploy is expected and it should be handled in the code. > Using "attribute" tag causes injection of null values > ----------------------------------------------------- > > Key: WFLY-670 > URL: https://issues.jboss.org/browse/WFLY-670 > Project: WildFly > Issue Type: Bug > Components: JMX > Reporter: Anders Welen > Assignee: Tomasz Adamski > Priority: Minor > Fix For: Awaiting Volunteers > > > Using "attribute" tag in "jboss-service.xml" in a SAR archive causes injection of null values. Even if your code can handle this it makes it impossible to use primitive datatypes. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3931) Custom formatter property changes not written to, but overriden by logging.properties

by Vsevolod Golovanov (JIRA)

[ https://issues.jboss.org/browse/WFLY-3931?page=com.atlassian.jira.plugin.... ] Vsevolod Golovanov edited comment on WFLY-3931 at 11/29/14 4:14 PM: -------------------------------------------------------------------- [~ander.parra], [^standalone.xml] - it's just a fresh standalone.xml with the following added: {code} <formatter name="ZZZZ"> <custom-formatter class="org.jboss.logmanager.formatters.PatternFormatter" module="org.jboss.logmanager"> <properties> <property name="pattern" value="1" /> </properties> </custom-formatter> </formatter> {code} No more configuration or code needed to reproduce. was (Author: vsevolodgolovanov): [~ander.parra], here, it's just a fresh standalone.xml with the following added: {code} <formatter name="ZZZZ"> <custom-formatter class="org.jboss.logmanager.formatters.PatternFormatter" module="org.jboss.logmanager"> <properties> <property name="pattern" value="1" /> </properties> </custom-formatter> </formatter> {code} No more configuration or code needed to reproduce. > Custom formatter property changes not written to, but overriden by logging.properties > ------------------------------------------------------------------------------------- > > Key: WFLY-3931 > URL: https://issues.jboss.org/browse/WFLY-3931 > Project: WildFly > Issue Type: Bug > Components: Logging > Affects Versions: 8.1.0.Final > Environment: Wildfly 8.1.0.Final > Reporter: Vsevolod Golovanov > Assignee: James Perkins > Attachments: standalone.xml > > > When you first add custom formatter with properties to standalone.xml, on server start property values get correctly resolved and written to logging.properties. > If you change property values in standalone.xml of an existing custom formatter, that was flushed to logging.properties before, then on the next server start new values don't get written to logging.properties and formatter instance gets the old values from logging.properties. > For properties with static values that are defined in standalone.xml there is a workaround: change the custom formatter name each time you change a property value. > But with more dynamic properties, e.g. that rely on system properties, it's not so simple... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3931) Custom formatter property changes not written to, but overriden by logging.properties

by Vsevolod Golovanov (JIRA)

[ https://issues.jboss.org/browse/WFLY-3931?page=com.atlassian.jira.plugin.... ] Vsevolod Golovanov updated WFLY-3931: ------------------------------------- Attachment: standalone.xml [~ander.parra], here, it's just a fresh standalone.xml with the following added: {code} <formatter name="ZZZZ"> <custom-formatter class="org.jboss.logmanager.formatters.PatternFormatter" module="org.jboss.logmanager"> <properties> <property name="pattern" value="1" /> </properties> </custom-formatter> </formatter> {code} No more configuration or code needed to reproduce. > Custom formatter property changes not written to, but overriden by logging.properties > ------------------------------------------------------------------------------------- > > Key: WFLY-3931 > URL: https://issues.jboss.org/browse/WFLY-3931 > Project: WildFly > Issue Type: Bug > Components: Logging > Affects Versions: 8.1.0.Final > Environment: Wildfly 8.1.0.Final > Reporter: Vsevolod Golovanov > Assignee: James Perkins > Attachments: standalone.xml > > > When you first add custom formatter with properties to standalone.xml, on server start property values get correctly resolved and written to logging.properties. > If you change property values in standalone.xml of an existing custom formatter, that was flushed to logging.properties before, then on the next server start new values don't get written to logging.properties and formatter instance gets the old values from logging.properties. > For properties with static values that are defined in standalone.xml there is a workaround: change the custom formatter name each time you change a property value. > But with more dynamic properties, e.g. that rely on system properties, it's not so simple... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4136) sql parameter log issue spy

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-4136?page=com.atlassian.jira.plugin.... ] James Perkins closed WFLY-4136. ------------------------------- Resolution: Rejected After looking into there is no issue here. The way the spy logs the information is correct. > sql parameter log issue spy > --------------------------- > > Key: WFLY-4136 > URL: https://issues.jboss.org/browse/WFLY-4136 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Affects Versions: 8.2.0.Final > Environment: NA > Reporter: Gulam Samdani > Assignee: Jesper Pedersen > Priority: Critical > > problem description is here . > https://developer.jboss.org/thread/250027 > most of time several people not interested on jboss because this missing feature . it is important for development . but it is not impossible . so , > please add this feature next version . already all server tomcat , glassfish support this , why can not jboss offer this feature . > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-274) The CLI command "read-boot-errors" does not include the timestamp of the error event

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-274?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-274: ------------------------------------------------ Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1160898|https://bugzilla.redhat.com/show_bug.cgi?id=1160898] from POST to MODIFIED > The CLI command "read-boot-errors" does not include the timestamp of the error event > ------------------------------------------------------------------------------------ > > Key: WFCORE-274 > URL: https://issues.jboss.org/browse/WFCORE-274 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > > The CLI command "read-boot-errors" does not include the timestamp of the error event. For anyone using this command for diagnostic purposes, the absence of an event's timestamp decreases the usefulness of the information. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-216) Add ModelValidator to ensure resource model is correct

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-216?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-216: ------------------------------------------------ Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1023064|https://bugzilla.redhat.com/show_bug.cgi?id=1023064] from POST to MODIFIED > Add ModelValidator to ensure resource model is correct > ------------------------------------------------------ > > Key: WFCORE-216 > URL: https://issues.jboss.org/browse/WFCORE-216 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Stefano Maestri > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha12 > > > Currently there is no validation of "requires" and "alternatives" that are specified in attribute metadata / AttributeDefinition > ModelValidator should be added as extra step handler that executes on end of MODEL phase to ensure resource model is correct. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2376) DataSource properties are not persisting via CLI

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2376?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2376: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1023064|https://bugzilla.redhat.com/show_bug.cgi?id=1023064] from POST to MODIFIED > DataSource properties are not persisting via CLI > ------------------------------------------------ > > Key: WFLY-2376 > URL: https://issues.jboss.org/browse/WFLY-2376 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Jay Kumar SenSharma > Assignee: Stefano Maestri > Fix For: 9.0.0.Beta1 > > > - The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration: > {quote} > ./jboss-cli.sh --user=admin --password=admin@123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)" > "stale-connection-checker-properties" => { > "type" => OBJECT, > "description" => "The stale connection checker properties", > "expressions-allowed" => true, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > "reauth-plugin-properties" => { > "type" => OBJECT, > "description" => "The properties for the reauthentication plugin", > "expressions-allowed" => true, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > "exception-sorter-properties" => { > "type" => OBJECT, > "description" => "The exception sorter properties", > "expressions-allowed" => true, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {quote} > - Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource. > ./jboss-cli.sh --user=admin --password=admin@123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})" > - The Generated DataSource looks like following: > ${quote} > <datasource jndi-name="java:jboss/TestDS" pool-name="testpool" enabled="true"> > <connection-url>jdbc:oracle:thin:@DBHostName:1521:DBName</connection-url> > <driver>ojdbc6.jar</driver> > <new-connection-sql>select 1 from dual</new-connection-sql> > <security> > <user-name>user</user-name> > <password>pass</password> > </security> > <validation> > <valid-connection-checker class-name="org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker"/> > <check-valid-connection-sql>select 2 from dual</check-valid-connection-sql> > </validation> > </datasource> > ${quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years

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 November 2014