April 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1218) System property substitution in config file parsing

by Brian Stansberry (JIRA)

System property substitution in config file parsing --------------------------------------------------- Key: JBCACHE-1218 URL: http://jira.jboss.com/jira/browse/JBCACHE-1218 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani Since JBC parses its own config files it would be nice to support the ${some.system.property:somedefault} syntax. This should be trivial to do; just add callouts to org.jboss.util.StringPropertyReplacer.replaceProperties(String) in XmlHelper.getAttributeValue() and XmlHelper.getElementContent(). This could even be helpful in JBoss AS if XmlParsingConfigurationRegistry is used -- the normal AS parsing wouldn't be used in that case. But, it would be simple enough though for me to write a different ConfigurationRegistry that had its config injected from MC beans rather than parsing the XML itself. Manik, I left this assigned to you to give you a shot at making any inputs. If you think its worthwhile, feel free to assign back to me. -- 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

17 years, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (JBRULES-1544) Improve Drools' serialization performance

by Ming Jin (JIRA)

Improve Drools' serialization performance ----------------------------------------- Key: JBRULES-1544 URL: http://jira.jboss.com/jira/browse/JBRULES-1544 Project: JBoss Drools Issue Type: Task Security Level: Public (Everyone can see) Components: Drl Parser/Builder Reporter: Ming Jin Assigned To: Ming Jin Priority: Minor Fix For: 5.0.0-M1 Both the memory consumption and timing performance of Drools' Package/RuleBase serialization using native Java could be improved, especially when dealing with large number of rules. The design was to use a custom serializer, and implement read/writeExternal as much as possible. -- 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

17 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1254) XA naming WARN message when using JBoss Cache with JBoss TS

by Manik Surtani (JIRA)

XA naming WARN message when using JBoss Cache with JBoss TS ----------------------------------------------------------- Key: JBCACHE-1254 URL: http://jira.jboss.com/jira/browse/JBCACHE-1254 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Priority: Minor Fix For: 2.2.0.GA >From the forum thread: "... each time the standalone JBossCache application is launched, an annoying WARN message pops up in the log file as follows: ------------------------------------------------------ ...[com.arjuna.ats.arjuna.coordinator.TxControl_1] - Name of XA node not defined. Using -53eefec4:11ee:477aefc2:1 ------------------------------------------------------ " -- 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

17 years, 9 months

1
3
0 / 0

[JBoss JIRA] Updated: (JBAS-2131) Better support for BMT SFSB "mistakes"

by Jesper Pedersen (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2131?page=all ] Jesper Pedersen updated JBAS-2131: ---------------------------------- Assignee: Jesper Pedersen (was: Weston Price) > Better support for BMT SFSB "mistakes" > -------------------------------------- > > Key: JBAS-2131 > URL: http://jira.jboss.com/jira/browse/JBAS-2131 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: EJB2 > Affects Versions: JBossAS-4.0.3RC2 > Reporter: Adrian Brock > Assigned To: Jesper Pedersen > Fix For: JBossAS-4.2.3.GA > > > Further to JBAS-2128 we should also implement some sort of listener on the transaction timeout. > Given the stupid BMT SFSB semantics (this part of the spec is one my favourite anti-patterns :-) > where a client can hog server resources. > sfsb.doBegin(); > doLongRunningProcess(); > sfsb.doCommit(); > And even crash during the doLongRunningProcess(). > We should allow the server to reclaim the resources from a transaction timeout more quickly. > Another option would be to allow a configuration that does a rollback() at transaction timeout. > But this would require some serious testing to make sure all JBoss code is checking transaction status correctly. > It would also confuse any non-j2ee compliant framework that registers transaction synchronizations > and then assumes their "thread local" is still valid from the timeout thread or they aren't threadsafe. > No names mentioned to protect the guilty :-) -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3207) Unification of Timer implementation for JBossAS

by Jesper Pedersen (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3207?page=all ] Jesper Pedersen updated JBAS-3207: ---------------------------------- Assignee: Jesper Pedersen (was: Weston Price) > Unification of Timer implementation for JBossAS > ----------------------------------------------- > > Key: JBAS-3207 > URL: http://jira.jboss.com/jira/browse/JBAS-3207 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JCA service > Affects Versions: JBossAS-5.0.0.GA > Reporter: Weston Price > Assigned To: Jesper Pedersen > Priority: Critical > Fix For: JBossAS-5.0.0.GA > > > * Unification of timers into a Quartz based implementation. Timer uses to unify include: > ** jPBM timers > ** EJB/EJB3 timers > ** jmx timers > ** jmx timer service > ** org.jboss.util.* custom timers > * Have a Quartz rar providing a message inflow adaptor that delivers a Quartz event. > * Expose the Quartz APIs as Seam components -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3981) Statment caching in update query which return value

by erahamim (JIRA)

Statment caching in update query which return value ---------------------------------------------------- Key: JBAS-3981 URL: http://jira.jboss.com/jira/browse/JBAS-3981 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.5.GA Environment: jboss 4.0.5 on windows xp / linux with database oracle 10.0.2 Reporter: erahamim Priority: Minor When I set statements cache in oracle-xa-ds.xml: <prepared-statement-cache-size>100</prepared-statement-cache-size> For the following statement: BEGIN UPDATE table SET A=? WHERE ID=? AND TIME=? RETURNING TIME INTO ?; END con = DataSourceManager.getConnection(); statement = con.prepareCall( 'The above query'); statement.setInt(1,1); statement.setTimestamp(2, myTime); statement.registerOutParameter(3, Types.TIMESTAMP); statement.executeUpdate(); final Timestamp ts = statement.getTimestamp(lastIndex); In this scenario, I'm always getting back the time result even if the update didn't match any row in database. When I drop the statement cache I get the result only if there was a row that was updated by this statement. I can't use the return value from executeUpdate() since it always return 1. -- 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

17 years, 9 months

3
2
0 / 0

[JBoss JIRA] Updated: (JBAS-1425) Programmatic Connection Definition Deployment

by Jesper Pedersen (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1425?page=all ] Jesper Pedersen updated JBAS-1425: ---------------------------------- Assignee: Jesper Pedersen (was: Weston Price) > Programmatic Connection Definition Deployment > --------------------------------------------- > > Key: JBAS-1425 > URL: http://jira.jboss.com/jira/browse/JBAS-1425 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JCA service > Reporter: Adrian Brock > Assigned To: Jesper Pedersen > Priority: Minor > > Forums Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48673 > Provide a mechanism where ConnectionFactorys/DataSources (Connection Definitions) > can be deployed/undeployed programmatically. > The basic design is as follows: > 1) Provide a mechanism to instantiate MetaData for a connection factory. > This information is the same as the -ds.xml deployment format. > The MetaData can be logically divided into at least the following categories: > * RAR/ConnectionDefinition identification > * ManagedConnectionFactory > * Pool > * Security > * ConnectionManager > * Proxy/JNDI binding > 2) Write an optimized version of the MetaData for the DataSource deployments > which are really a simplified version of the ConnectionFactory deployments with some > hardwiring. > 3) Write a service that deploys the ConnectionFactory (creates MBeans) > from the MetaData and undeploys them based on their id (jndi binding). > 4) Convert the ConnectionFactory deployer to construct the MetaData from the -ds.xml > files and invoke the service new service. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3511) JMS ASF integration and JMS Session Pools need resource management improvements

by Weston Price (JIRA)

JMS ASF integration and JMS Session Pools need resource management improvements ------------------------------------------------------------------------------- Key: JBAS-3511 URL: http://jira.jboss.com/jira/browse/JBAS-3511 Project: JBoss Application Server Issue Type: Support Patch Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.0.3 SP1 Reporter: Weston Price Assigned To: Weston Price Priority: Minor A client has requested that the JMS applications server integration facilities for resource management and JMS session pooling be improved primarily in two areas: 1) The ability to not create all JMS sessions on container startup. 2) The ability to recycle/release JMS sessions based on a configurable timeout. Both these features would need to be added to the existing JMSContainerInvoker as well as carried forward to the JBossJCA adapter prior to production release. -- 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

17 years, 9 months

3
3
0 / 0

[JBoss JIRA] Updated: (JBAS-2854) Fire local transaction events from the jms resource adapter

by Jesper Pedersen (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2854?page=all ] Jesper Pedersen updated JBAS-2854: ---------------------------------- Assignee: Jesper Pedersen (was: Weston Price) > Fire local transaction events from the jms resource adapter > ----------------------------------------------------------- > > Key: JBAS-2854 > URL: http://jira.jboss.com/jira/browse/JBAS-2854 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: JCA service > Affects Versions: JBossAS-4.0.4RC1 > Reporter: Adrian Brock > Assigned To: Jesper Pedersen > Fix For: JBossAS-4.2.3.GA > > > We need to fire local transaction events from the jms resource adapter. > This is not a trivial change since there is currently no easy way for the JmsSession class > to work out when the transaction started and whether it is a local transaction. > There is no explicit start of transaction in JMS. > It probably needs a modfication to getSession() as this is the most obvious point > where work is first done in a new transaction after the commit/rollback on the session. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1434) JMS Message Inflow

by Jesper Pedersen (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1434?page=all ] Jesper Pedersen updated JBAS-1434: ---------------------------------- Assignee: Jesper Pedersen (was: Weston Price) > JMS Message Inflow > ------------------ > > Key: JBAS-1434 > URL: http://jira.jboss.com/jira/browse/JBAS-1434 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JCA service > Affects Versions: JBossAS-4.0.2 Final > Reporter: Adrian Brock > Assigned To: Jesper Pedersen > Fix For: JBossAS-4.2.3.GA > > > Forums Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48672 > The JMS message inflow in the JMS resource adapter needs properly testing. > There are basic tests, but the following are missing: > 1) Complete tests of edge cases for each configuration parameter in the activation spec > 2) Failure tests to confirm the implementation handles error gracefully > 3) Stress tests to make sure there the implementation is stable > 4) Performance tests to optimize the implementation > Additionally, we need to confirm that it is possible to use this implementation for EJB2.0 > style deployments and hence as the default configuration. > This should be possible provided the user has not created their own > container configuration that uses the old JMSContainerInvoker explicitly. -- 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

17 years, 9 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 April 2008