January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBCACHE-664) Add JBossRetro jars, baseline to Java5 and create a Java1.4 compat binary

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-664?page=all ] Manik Surtani closed JBCACHE-664. --------------------------------- Resolution: Done > Add JBossRetro jars, baseline to Java5 and create a Java1.4 compat binary > ------------------------------------------------------------------------- > > Key: JBCACHE-664 > URL: http://jira.jboss.com/jira/browse/JBCACHE-664 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.4.0.GA > Reporter: Manik Surtani > Assigned To: Manik Surtani > Priority: Critical > Fix For: 2.0.0.BETA1, 2.0.0.GA > > Original Estimate: 2 days > Remaining Estimate: 2 days > > * Use JBossRetro to build a compat version of JBossCache > * Baseline against Java5 for 'normal' builds > * Don't migrate concurrent.jar - still stick with concurrent.jar for concurrent utils rather than java.util.concurrent. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBCACHE-664) Add JBossRetro jars, baseline to Java5 and create a Java1.4 compat binary

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-664?page=comments#action_12351119 ] Manik Surtani commented on JBCACHE-664: --------------------------------------- Worked around JBBUILD-332 by using a switch statement in LockFactory > Add JBossRetro jars, baseline to Java5 and create a Java1.4 compat binary > ------------------------------------------------------------------------- > > Key: JBCACHE-664 > URL: http://jira.jboss.com/jira/browse/JBCACHE-664 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.4.0.GA > Reporter: Manik Surtani > Assigned To: Manik Surtani > Priority: Critical > Fix For: 2.0.0.BETA1, 2.0.0.GA > > Original Estimate: 2 days > Remaining Estimate: 2 days > > * Use JBossRetro to build a compat version of JBossCache > * Baseline against Java5 for 'normal' builds > * Don't migrate concurrent.jar - still stick with concurrent.jar for concurrent utils rather than java.util.concurrent. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-889) EvictionPolicy methods for 2.0, consider revising

by Elias Ross (JIRA)

EvictionPolicy methods for 2.0, consider revising ------------------------------------------------- Key: JBCACHE-889 URL: http://jira.jboss.com/jira/browse/JBCACHE-889 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.ALPHA2 Reporter: Elias Ross Assigned To: Manik Surtani I noticed that nobody seems to use EvictionPolicy methods such as getChildrenNames(), hasChild(), getCacheData(), etc. It might make sense to simply remove these methods and add a EvictionPolicy { Cache getCache(); } . Change EvictionPolicy.configure() to EvictionPolicy.setCache() to match. -- 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, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-940) Creating a child with explicit data version under a parent also with an explicit data version causes the parent to be added with DefaultDataVersion

by Manik Surtani (JIRA)

Creating a child with explicit data version under a parent also with an explicit data version causes the parent to be added with DefaultDataVersion --------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBCACHE-940 URL: http://jira.jboss.com/jira/browse/JBCACHE-940 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.ALPHA2 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.BETA1 -- 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, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-867) Refactor use of TreeCacheProxyImpl

by Elias Ross (JIRA)

Refactor use of TreeCacheProxyImpl ---------------------------------- Key: JBCACHE-867 URL: http://jira.jboss.com/jira/browse/JBCACHE-867 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Elias Ross Assigned To: Manik Surtani Move methods from TreeCacheProxyImpl to the NodeImpl itself. Consider also removing this class and having TreeCache implement Cache. -- 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, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAOP-341) ClassCastException on MethodWrapper for BootClassPath GenAdvisor Tests

by Flavia Rainone (JIRA)

ClassCastException on MethodWrapper for BootClassPath GenAdvisor Tests ---------------------------------------------------------------------- Key: JBAOP-341 URL: http://jira.jboss.com/jira/browse/JBAOP-341 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Flavia Rainone Fix For: 1.5.3.GA Class Cast exception on method wrapper, for tests org.jboss.test.aop.basic.AOPTester.testInterfaceUsedInHas and org.jboss.test.aop.regression.jbaop137.ExtenderTestCase.testMethod. On the first case, the method execution wrapper tries to cast: org.jboss.test.aop.basic.SubclassInterfaceUsedInHasImpl$SubclassInterfaceUsedInHasImplAdvisor to org.jboss.test.aop.basic.InterfaceUsedInHasImpl$InterfaceUsedInHasImplAdvisor. But, even though SuclassInterfaceUsedInHasImpl extends InterfaceUsedInHasImpl, its advisor extends GeneratedAdvisor. On the second test failure, an instance of org.jboss.test.aop.regression.jbaop137.Extender$ExtenderInstanceAdvisor is cast to org.jboss.test.aop.regression.jbaop137.Base$BaseAdvisor. But this advisor extends org.jboss.test.aop.regression.jbaop137.Extender$ExtenderAdvisor,which extends GeneratedAdvisor. The problem here is that the generated advisor of a class should extend the advisor of its superclass. The problem happens only on bootclasspath-genadvisor-tests. For precompiled-genadvisor-tests, everything is as expected. -- 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, 4 months

2
4
0 / 0

[JBoss JIRA] Updated: (JBAS-2373) Need to replace PropertyEditorManager with context aware org.jboss.util.propertyeditor.PropertyEditors

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2373?page=all ] Dimitris Andreadis updated JBAS-2373: ------------------------------------- Fix Version/s: (was: JBossAS-4.2.0.CR1) > Need to replace PropertyEditorManager with context aware org.jboss.util.propertyeditor.PropertyEditors > ------------------------------------------------------------------------------------------------------ > > Key: JBAS-2373 > URL: http://jira.jboss.com/jira/browse/JBAS-2373 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Deployment services > Affects Versions: JBossAS-4.0.3 Final > Reporter: Scott M Stark > Assigned To: Dimitris Andreadis > > The use of the java.beans.PropertyEditorManager as a registry for java.beans.PropertyEditor instances does not work with scoped deployments as its a vm global singleton that does not work with scoped deployments, conflicting scoped deployments and redeployments. Use of the PropertyEditorManager needs to be replaced with use of a context aware org.jboss.util.propertyeditor.PropertyEditors that allows different deployments such as a scoped sar and unscoped jmx-console to use the correct PropertyEditor and clear deployment level PropertyEditor on undeployment. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3870) Clone the JBossMX javax.management.timer.Timer implementation, to a jboss package

by Dimitris Andreadis (JIRA)

Clone the JBossMX javax.management.timer.Timer implementation, to a jboss package --------------------------------------------------------------------------------- Key: JBAS-3870 URL: http://jira.jboss.com/jira/browse/JBAS-3870 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JMX Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-5.0.0.CR1, JBossAS-4.2.0.CR1 There are indications that the jdk5 implementation of javax.management.timer.Timer uses internally a single-threaded implementation for executing scheduled tasks, so scheduling of multiple tasks is affected when moving from jdk1.4 and the jboss implementation of Timer, to a jdk5 runtime. The JBossMX Timer implementation in contrast uses a dynamically extensible thread pool to execute scheduled tasks. Since we don't control the jdk5 implementation, a simple solution is to clone the jboss timer into a new package, e.g. org.jboss.javax.management.timer.Timer, for those that want to stick with the jboss implementation. -- 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, 4 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBAS-2833) Externalizing the ServiceController configuration for injecting the configuration of the ServiceBinding aspect

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2833?page=all ] Dimitris Andreadis updated JBAS-2833: ------------------------------------- Fix Version/s: (was: JBossAS-4.2.0.CR1) > Externalizing the ServiceController configuration for injecting the configuration of the ServiceBinding aspect > -------------------------------------------------------------------------------------------------------------- > > Key: JBAS-2833 > URL: http://jira.jboss.com/jira/browse/JBAS-2833 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: System service > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Dimitris Andreadis > Assigned To: Dimitris Andreadis > > The ServiceBindingManager should really be an aspect applied to the ServiceController (see forum post). -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBAS-2299) OutOfMemory error when repetatively deploying and undeploying with 10 minute interval

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ] Dimitris Andreadis reassigned JBAS-2299: ---------------------------------------- Assignee: Clebert Suconic (was: Dimitris Andreadis) Clebert, can you please check if this has been fixed in beanutils 1.7.0 we use in Branch_4_2 ? If not we should consider contributing a fix. > OutOfMemory error when repetatively deploying and undeploying with 10 minute interval > ------------------------------------------------------------------------------------- > > Key: JBAS-2299 > URL: http://jira.jboss.com/jira/browse/JBAS-2299 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Deployment services > Affects Versions: JBossAS-4.0.3RC2 > Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07 > Reporter: Amar Syed > Assigned To: Clebert Suconic > Fix For: JBossAS-4.2.0.CR1 > > Attachments: Data.txt, SampleApp.ear > > Time Spent: 2 hours > Remaining Estimate: 0 minutes > > Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions. > The min and max heap settings were configured as : -Xms128m -Xmx512m > The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle. > I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue. > The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows: > 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null > 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3@c90207{ url=null ,addedOrder=0} > 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error > java.lang.OutOfMemoryError > 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable > java.lang.OutOfMemoryError > 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception > java.lang.OutOfMemoryError > 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null > The following two jars were added to the server\default\lib folder. > commons-validator.jar --- version 1.1.3 > struts.jar ---- version 1.2.4 -- 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, 4 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 January 2007