May 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1068) Get rid of LifeCycle interface

by Brian Stansberry (JIRA)

Get rid of LifeCycle interface ------------------------------ Key: JBCACHE-1068 URL: http://jira.jboss.com/jira/browse/JBCACHE-1068 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR1 Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 2.0.0.CR2 The org.jboss.cache.jmx.LifeCycle interface is more trouble than help. No code refers to anything by that interface. All it does is encapsulate create/start/stop/destroy so various subinterfaces can save four lines of code. Problem is the subinterfaces that use it can reasonably declare different exception types, forcing LifeCycle to say "throws Exception". That makes using LifeCycle in any kind of utility code unworkable. -- 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

19 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1047) CacheJmxWrapper and PojoCacheJmxWrapper should allow explicit config of whether to control cache lifecycle

by Brian Stansberry (JIRA)

CacheJmxWrapper and PojoCacheJmxWrapper should allow explicit config of whether to control cache lifecycle ---------------------------------------------------------------------------------------------------------- Key: JBCACHE-1047 URL: http://jira.jboss.com/jira/browse/JBCACHE-1047 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR1 Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 2.0.0.CR2 When the lifecycle methods are invoked on CacheJmxWrapper and PojoCacheJmxWrapper, those classes need to decide whether to pass the lifecycle call on to the underlying cache they are wrapping. They currently make that decision based on how the underlying cache was created: 1) If the underlying cache was injected, they don't manage its lifecycle (assume whoever injected it, e.g. AS microcontainer will do it.) 2) If they constructed the cache themselves from a Configuration, then the lifecycle calls are passed through. That's fine for most use cases, but while writing some unit tests yesterday it didn't seem clean when I was doing things programatically. E.g. create a cache, inject it into a wrapper, register the wrapper in JMX, call start on the wrapper. Underlying cache is not started; code has to call start() on the cache as well. So, I've added a ManageCacheLifecycle attribute to the wrapper's where the desired behavior can be explicitly set. If the attribute is not set, the default behavior is what I described above. -- 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

19 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-4437) Log4jProxy in commons-logging fork throws NPE if TCCL is null

by Brian Stansberry (JIRA)

Log4jProxy in commons-logging fork throws NPE if TCCL is null ------------------------------------------------------------- Key: JBAS-4437 URL: http://jira.jboss.com/jira/browse/JBAS-4437 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Affects Versions: JBossAS-4.2.0.GA, JBossAS-4.0.5.GA Reporter: Brian Stansberry Assigned To: Scott M Stark The Log4jProxy class in the JCL fork has this: ClassLoader loader = Thread.currentThread().getContextClassLoader(); // Validate that TCL can actually see the log4j classes try { Class levelClass = loader.loadClass("org.apache.log4j.Level"); ... } catch(ClassNotFoundException e) { // No, hack to fall back to this class' class loader loader = Log4jProxy.class.getClassLoader(); } This throws an NPE if the TCCL is null. On a recent case a finalize() method ended up trying to instantiate a logger; failed because the Finalizer thread didn't have a TCCL set. -- 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

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (HIBERNATE-64) Hibernate Dialect is not auto-detected for Sybase ASE and DB2

by Shelly McGowan (JIRA)

Hibernate Dialect is not auto-detected for Sybase ASE and DB2 ------------------------------------------------------------- Key: HIBERNATE-64 URL: http://jira.jboss.com/jira/browse/HIBERNATE-64 Project: Hibernate Issue Type: Bug Reporter: Shelly McGowan Assigned To: Emmanuel Bernard The hibernate auto-detection mechanism was tested with the following Databases. DB2 and Sybase ASE - are not automatically detected. DB2 v8.0: javax.persistence.PersistenceException: org.hibernate.HibernateException: Hibernate Dialect must be explicitly set for database: DB2/LINUX NOTE: looks like it will be auto-detected for DB2/NT Sybase ASE 12.5: [SettingsFactory] RDBMS: Adaptive Server Enterprise, version: Adaptive Server Enterprise/12.5.3/EBF 13332 ESD#7/P/Linux Intel/Enterprise Linux/ase1253/1951/32-bit/OPT/Fri Mar 24 00:40:52 2006 16:52:09,234 INFO [SettingsFactory] JDBC driver: jConnect (TM) for JDBC (TM), version: jConnect (TM) for JDBC(TM)/5.5(Build 25827)/P/EBF13045/JDK13/Mon Oct 3 7:31:59 2005 javax.persistence.PersistenceException: org.hibernate.HibernateException: Hibernate Dialect must be explicitly set for database: Adaptive Server Enterprise The following were auto-detected: Oracle 9i: OLAP and Oracle Data Mining options JServer Release 9.2.0.1.0 - Production [SettingsFactory] JDBC driver: Oracle JDBC driver, version: 10.1.0.3.0 [Dialect] Using dialect: org.hibernate.dialect.Oracle9Dialect Oracle 10g: [org.hibernate.cfg.SettingsFactory] RDBMS: Oracle, version: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production [org.hibernate.cfg.SettingsFactory] JDBC driver: Oracle JDBC driver, version: 10.1.0.3.0 [org.hibernate.dialect.Dialect] Using dialect: org.hibernate.dialect.Oracle9Dialect MsSQLServer 2005: [org.hibernate.cfg.SettingsFactory] RDBMS: Microsoft SQL Server, version:9.00.2047 14:25:23,808 INFO [SettingsFactory] JDBC driver: Microsoft SQL Server 2005 JDBC Driver, version: 1.1.1501.101 [Dialect] Using dialect: org.hibernate.dialect.SQLServerDialect PostgresSQL 8.1: [SettingsFactory] RDBMS: PostgreSQL, version: 8.2.3 [SettingsFactory] JDBC driver: PostgreSQL Native Driver,version: PostgreSQL 8.2 JDBC3 with SSL (build 504) [Dialect] Using dialect: org.hibernate.dialect.PostgreSQLDialect MySQL 5.0: SettingsFactory] RDBMS: MySQL, version:5.0.27-standard-log [SettingsFactory] JDBC driver: MySQL-AB JDBC Driver, version: mysql-connector-java-5.0.4 ( $Date: 2006-10-19 17:47:48 +0200 (Thu, 19 Oct 2006) $, $Revision: 5908 $ ) [Dialect] Using dialect: org.hibernate.dialect.MySQLDialect -- 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

19 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1069) Support injection of CacheJmxWrapper into TcpCacheServer

by Brian Stansberry (JIRA)

Support injection of CacheJmxWrapper into TcpCacheServer -------------------------------------------------------- Key: JBCACHE-1069 URL: http://jira.jboss.com/jira/browse/JBCACHE-1069 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR1 Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 2.0.0.CR2 Makes it easier to do dependency injection if people are using -service.xml files. -- 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

19 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4425) ConnectionFactoryTemplate.xsl incorrectly sets isSameRM-override-value

by Weston Price (JIRA)

ConnectionFactoryTemplate.xsl incorrectly sets isSameRM-override-value ---------------------------------------------------------------------- Key: JBAS-4425 URL: http://jira.jboss.com/jira/browse/JBAS-4425 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.2.0.GA Reporter: Weston Price Assigned To: Weston Price Priority: Blocker The ConnectionFactoryTemplate.xsl was inadvertently modified and as a result incorrectly sets the isSameRM-override-value as a config property. This should be set as an attribute of the ConnectionManager. -- 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

19 years, 2 months

2
6
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1460) Should be possible to rename a portlet instance from the Admin GUI

by Chris Laprun (JIRA)

Should be possible to rename a portlet instance from the Admin GUI ------------------------------------------------------------------ Key: JBPORTAL-1460 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1460 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.CR2 Reporter: Chris Laprun Assigned To: Julien Viet Fix For: 2.8 Final This is in particular useful for Wizard-generated instances... -- 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

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1038) When using optimistic locking and implicit transactions, failures due to rollbacks should be propagated as CacheExceptions and not swallowed.

by Manik Surtani (JIRA)

When using optimistic locking and implicit transactions, failures due to rollbacks should be propagated as CacheExceptions and not swallowed. --------------------------------------------------------------------------------------------------------------------------------------------- Key: JBCACHE-1038 URL: http://jira.jboss.com/jira/browse/JBCACHE-1038 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR1, 1.4.1.GA Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.CR2, 2.0.0.GA When methods like cache.put(fqn, key, value) are used outside the context of a transaction and in optimistic locking mode, an implicit transaction is created and started for the duration of the call. If this implicit transaction fails and rolls back, the method still returns successfully. The method *should* throw a CacheException, which wraps the RollbackException's cause. -- 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

19 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1045) Clean up lifecycle methods

by Brian Stansberry (JIRA)

Clean up lifecycle methods -------------------------- Key: JBCACHE-1045 URL: http://jira.jboss.com/jira/browse/JBCACHE-1045 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR1 Reporter: Brian Stansberry Assigned To: Manik Surtani Looking at the lifecycle methods, they seem conceptually overly complex and easily breakable: 1) create() sets some things up. 2) start() calls create() if it wasn't called. That's ok as a help to users, but begs the question whether the stuff in create() should just be in start() with create() just a no-op. 3) stop() undoes some of the stuff done in create(); i.e. nulls out the channel, stops replQueue. Then sets a flag so a later call to start() will execute create() again. This seems like an unhealthy mingling of concerns -- stop() should reverse stuff done in start(), not stuff done in create(). Also, in create(), the cache is performing operations on services it depends on: 1) Looking up the TransactionManager in JNDI. 2) Creating a Channel using the injected ChannelFactory. Both of these are violations of the rule that a service should not invoke on a dependency in the create phase. The dependency only promises to be ready for invocations after it has returned from start(), and the microcontainer is free to call create() on the cache before calling start() on the dependency. A likely solution to this is: 1) Move the transaction manager lookup, the channel creation and the replQueue creation to start(). Move anything else I may have missed that stop() is reversing. 2) In stop, don't set createCalled = false. That flag only gets set to false in destroy(). -- 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

19 years, 2 months

2
3
0 / 0

[JBoss JIRA] Commented: (JBPM-46) scheduler

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-46?page=comments#action_12362841 ] Ronald van Kuijk commented on JBPM-46: -------------------------------------- I'd prefer these kinds of discussions to be on the forum, but I'll respond nevertheless. Afaik, In 3.2 this is all done by the jobexecuter servlet (in the war version) and ejb timers in the enterprise version. Regarding the sensible approach, see my previous comment (it is a statement from Tom) > scheduler > --------- > > Key: JBPM-46 > URL: http://jira.jboss.com/jira/browse/JBPM-46 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > Priority: Critical > Fix For: jBPM 3.0 alpha 4 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > implement the scheduler functionality + a simple servlet that acts as a cron-task to check for due jobs on regular intervals. -- 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

19 years, 2 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 May 2007