April 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3949) Upgrade to log4j 1.2.14

by Dimitris Andreadis (JIRA)

Upgrade to log4j 1.2.14 ----------------------- Key: JBAS-3949 URL: http://jira.jboss.com/jira/browse/JBAS-3949 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Logging Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-4.2.0.CR1 Upgrade to the latest stable log4j release 1.2.14 http://logging.apache.org/log4j/docs/download.html -- 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
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-928) Consider adding a method to expose lifecycle state

by Brian Stansberry (JIRA)

Consider adding a method to expose lifecycle state -------------------------------------------------- Key: JBCACHE-928 URL: http://jira.jboss.com/jira/browse/JBCACHE-928 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 2.0.0.BETA1 In 1.x, in the AS at least, the lifecycle state of a cache could be determined via the inherited ServiceMBeanSupport.getState(). Now there is no way to find out if the cache is created/started/stopped/destroyed. We should consider adding this, perhaps as a method in the Cache interface. -- 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

3
6
0 / 0

[JBoss JIRA] Created: (JBFORUMS-219) Release JBoss Forums 1.0.0 GA

by Ryszard Kozmik (JIRA)

Release JBoss Forums 1.0.0 GA ----------------------------- Key: JBFORUMS-219 URL: http://jira.jboss.com/jira/browse/JBFORUMS-219 Project: JBoss Forums Issue Type: Release Components: Portlet Productization Reporter: Ryszard Kozmik Assigned To: Ryszard Kozmik Fix For: 1.0.0 GA Process of releasing: - detailed test of all 3 branches - package - place packages on a server and create needed configurations - write report and annoucement on forums -- 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-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: (EJBTHREE-727) @Depends annotation does not work in EJB3 Embeddable release

by Magesh Kumar B (JIRA)

@Depends annotation does not work in EJB3 Embeddable release ------------------------------------------------------------ Key: EJBTHREE-727 URL: http://jira.jboss.com/jira/browse/EJBTHREE-727 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC9 - FD Reporter: Magesh Kumar B The ServiceOne, ServiceTwo and ServiceThree example given in the EJB3.0 documentation does not work when testing with the embeddable 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

19 years, 2 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-3985) EJB3 hot redeployment causes a permanently locked file handle

by Vladimir Ralev (JIRA)

EJB3 hot redeployment causes a permanently locked file handle ------------------------------------------------------------- Key: JBAS-3985 URL: http://jira.jboss.com/jira/browse/JBAS-3985 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services, EJB3 Affects Versions: JBossAS-4.0.5.GA Environment: Windows XP Pro, JRE 1.5_9, JBoss AS 4.0.5.GA, EJB3.CR9.patch1 Reporter: Vladimir Ralev Assigned To: Dimitris Andreadis I am not sure which component is responsible for the bug, but since it happened with an ejb3-jar I am rising it here. If it doesn't belong here please forward it the right place. 1. I copy titan.jar to the deploy folder -> the server deploys the ejb3 application and says ejb running 2. I delete titan.jar from the deploy folder -> the server says that the app is undeployed 3. I copy titian.jar in the deploy folder again -> the server deploys the ejb3 application and says ejb running again (everything seems ok for now, here comes the problem) 4. I try to delete titan.jar from the deploy folder -> I get a windows explorer error message saying that the file is in use and can't be deleted. When I checked with process explorer which process is using the file it turned out it's the java.exe process (the server didn't release the handle?). This doesn't not occur on Linux! -- 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

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-4055) Hot Deploy doesn't work in JBoss 5.0.0.Beta1

by Charles Crouch (JIRA)

Hot Deploy doesn't work in JBoss 5.0.0.Beta1 -------------------------------------------- Key: JBAS-4055 URL: http://jira.jboss.com/jira/browse/JBAS-4055 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.Beta1 Reporter: Charles Crouch Fix For: JBossAS-5.0.0.Beta2 Hot Deploy doesn't work in JBoss 5.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, 2 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-4229) HASingletonController doesn't handle "split brain" correctly.

by Adrian Brock (JIRA)

HASingletonController doesn't handle "split brain" correctly. ------------------------------------------------------------- Key: JBAS-4229 URL: http://jira.jboss.com/jira/browse/JBAS-4229 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.0.3 SP1 Reporter: Adrian Brock Assigned To: Brian Stansberry The HASingletonController doesn't understand the "split brain" problem. Take for example a JBossMQ destination (queue) which needs to be "restored" from the database when a new singleton is elected. The scenario goes as follows: STEP1 (original state): cluster=server1, server2 master=server1 STEP2 (unplug server1 from the network): cluster=server2 master=server2 server2 will now restore the queue from the database BUT! server1 has the view cluster=server1 master=server1 STEP3 (plug server1 back into the network) cluster=server1, server2 master=server1 We are back to the original state, but since server1 thinks it never left the cluster, it doesn't restore the changes (from the database) that server2 made to the queue between STEP2 and STEP3. This is because it doesn't restart the HASingleton on server1. If there was a third server (server3) to abitrate this wouldn't be a problem. Both server2 and server3 would agree that server2 is the master and that server1 has left and must rejoin. There needs to be some extra processing in the "merge" when two masters agree to form a cluster that ensures that whoever they elect as the new master gets its HASingleton(s) restarted. Otherwise, it won't have the up-to-date state from the other master. -- 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
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-843) Clustered ConnectionFactory with no load balancing, but failover capabilities needed

by Ovidiu Feodorov (JIRA)

Clustered ConnectionFactory with no load balancing, but failover capabilities needed ------------------------------------------------------------------------------------ Key: JBMESSAGING-843 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-843 Project: JBoss Messaging Issue Type: Feature Request Components: AS Integration Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.CR2 Needed by the MDB containers. An MDB creates several connections during its deployment. If using a load-balancing clustered ConnectionFactory, they'll end up on different cluster nodes, which is precisely what the MDB container doesn't need. On the other hand, if using a "dumb" non-clustered ConnectionFactory, the MDB container doesn't benefit from the cluster failover capabilities. A clustered ConnectionFactory with no load balancing, but failover capabilities is needed. -- 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
8
0 / 0

[JBoss JIRA] Created: (JBRULES-690) improve fron-end Standards and templates

by Fernando Meyer (JIRA)

improve fron-end Standards and templates ---------------------------------------- Key: JBRULES-690 URL: http://jira.jboss.com/jira/browse/JBRULES-690 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Fernando Meyer Assigned To: Fernando Meyer -- 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2007