September 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-6917) Add a apache-log4j-extra functions In Jboss-logging

by Marcio AntÃ£o (JIRA)

Add a apache-log4j-extra functions In Jboss-logging ---------------------------------------------------- Key: JBAS-6917 URL: https://jira.jboss.org/jira/browse/JBAS-6917 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Environment: software platform Reporter: Marcio AntÃ£o Jboss-logging use a apache-log4j-extra . This extras functions is very utils Example : Compress GZ (Log Rotation with Compact logs) Tks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-6197) Clean up the HAPartition interface

by Brian Stansberry (JIRA)

Clean up the HAPartition interface ---------------------------------- Key: JBAS-6197 URL: https://jira.jboss.org/jira/browse/JBAS-6197 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.Alpha1 Remove deprecated methods, replace usage of ArrayList and Vector with List, add generics info. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-3594) Allow HAPartitionStateTransfer subscribers to get state after HAPartition start() is called.

by Brian Stansberry (JIRA)

Allow HAPartitionStateTransfer subscribers to get state after HAPartition start() is called. -------------------------------------------------------------------------------------------- Key: JBAS-3594 URL: http://jira.jboss.com/jira/browse/JBAS-3594 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.1.CR1 Use the JGroups partial state transfer API for this. Remove the need for dependent services to register as a subscriber before HAPartition.start() is called. Having services interact with HAPartition before start() is contrary to the intended lifecycle semantics. -- 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

16 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-7254) Remove ChannelFactory additional_data usage

by Brian Stansberry (JIRA)

Remove ChannelFactory additional_data usage ------------------------------------------- Key: JBAS-7254 URL: https://jira.jboss.org/jira/browse/JBAS-7254 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.Alpha1 org.jboss.ha.framework.server.JChannelFactory supports a form of logical addresses by setting additional_data on the channel (see setChannelUniqueId()). This should be replaced by calling the JGroups 2.8 Channel.setName() method. The ClusterPartition.verifyNodeIsUnique() method uses the additional_data to try to ensure that the same node cannot rejoin the group until its previous incarnation has been removed from the view. Confirm that JGroups 2.8 handles this itself, removing the need for the AS to do it. Then make verifyNodeIsUnique a deprecated no-op (if this JIRA is done for AS 5.2) and remove it for AS 6. Can't just remove the method in 5.2 as it is protected; some subclass somewhere may invoke or override it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-6133) Upgrade Quartz to latest release

by Tomaz Cerar (JIRA)

Upgrade Quartz to latest release -------------------------------- Key: JBAS-6133 URL: https://jira.jboss.org/jira/browse/JBAS-6133 Project: JBoss Application Server Issue Type: Thirdparty Change Security Level: Public (Everyone can see) Components: Scheduling/Timers Affects Versions: JBossAS-5.0.0.CR2 Reporter: Tomaz Cerar Assignee: Dimitris Andreadis Jboss 5 currenty (trunk) comes with quartz 1.5.2. which is more than 2 years old, it would be nice if if would be upgraded to latest release (1.6.1 at this time) if I just replace jar from latest dist it looks like everything works... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

5
6
0 / 0

[JBoss JIRA] Created: (JBAS-6782) Seam/VFS integration issue

by Charles Crouch (JIRA)

Seam/VFS integration issue -------------------------- Key: JBAS-6782 URL: https://jira.jboss.org/jira/browse/JBAS-6782 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.1.0.CR1 Reporter: Charles Crouch Assignee: Jason T. Greene Fix For: JBossAS-5.1.0.GA Essentially Seam is scanning too many files looking for Seam components when a Seam based web app is being deployed. This increases the deployment time significantly, e.g. double it in the case of EMBJOPR. See https://jira.jboss.org/jira/browse/EMBJOPR-85?focusedCommentId=12461922#a... for more details -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

4
9
0 / 0

[JBoss JIRA] Created: (JBAS-7165) start page (i.e. /index.html) still has old (pre Red Hat) JBoss logo and overall dated L&F

by Ian Springer (JIRA)

start page (i.e. /index.html) still has old (pre Red Hat) JBoss logo and overall dated L&F ------------------------------------------------------------------------------------------ Key: JBAS-7165 URL: https://jira.jboss.org/jira/browse/JBAS-7165 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Other Affects Versions: JBossAS-5.1.0.GA Reporter: Ian Springer Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

3
4
0 / 0

[JBoss JIRA] Created: (JGRP-692) Unable to recover from suspect/merge, with auto-reconnect

by Matt Magoffin (JIRA)

Unable to recover from suspect/merge, with auto-reconnect --------------------------------------------------------- Key: JGRP-692 URL: http://jira.jboss.com/jira/browse/JGRP-692 Project: JGroups Issue Type: Bug Affects Versions: 2.6.1 Environment: JBoss 4.2.2 on Linux 2.4.21-47.0.1.ELsmp i686 using Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode) Reporter: Matt Magoffin Assigned To: Bela Ban Attachments: jgroups-logs.tbz2 I'm having an issue with a 2-machine cluster using a TCP stack based on the tcp.xml from JGroups 2.6.1. On each machine I have 8 separate channels running, on different ports, with 4 groups in 2 JVM instances. After some period of time, one machine will fail to respond to a FD ping, and gets suspected. The machine that failed is not responding in time it seems from high CPU use, and many of the channels will fail FD around the same time. The channels are configured with auto-reconnect. My understanding was that the channel should "heal" itself and eventually re-form into a new view with the same 2 members in the cluster, which should apply to this situation because the machine that failed to respond eventually will respond. However, the group does not always seem to "heal" (sometimes it does, sometimes not). Once it stops healing, it never seems to ever do so again, and I get tons of NAKACK "message X not found in retransmission table" ERROR logs. The only way to get the channel working agin is to shut down the channel on both machines and then start them up again. I'm not using muxed channels... just normal channels. I have for now disabled shunning, and the channels seem to be able to re-connect after a shun situation occurs, but after time I'm still seeing something wrong with the channel in that the nodes are not able to send messages to each other successfully, and I have tons of 2008-02-21 21:01:53,572 WARN [org.jgroups.protocols.pbcast.NAKACK] 172.16.172.233:19182] discarded message from non-member 172.16.172.234:19182, my view is [172.16.172.233:19182|8] [172.16.172.233:19182] log entries, even while FD is receiving acks on that channel. this is a degradation problem for me while my servers are running, not just during deployment. After a while of running, the nodes get shunned/disconnected some how (often from a slow response from the other node) and then fail to ever merge back to form the original view of the 2 nodes again. Now even with shun set to false in both FD and pbcast.GMS on both nodes for all channels, eventually still the nodes reach the same state of never re-forming... and I have tons eventual 2008-02-21 21:28:24,857 WARN [org.jgroups.protocols.pbcast.NAKACK] 172.16.172.233:19182] discarded message from non-member 172.16.172.234:19182, my view is [172.16.172.233:19182|8] [172.16.172.233:19182] After a while in my application I'll force the channel to close wait a minute, and reopen, and sometimes this gets the channel working again, but doesn't always seem to. -- 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

16 years, 3 months

4
24
0 / 0

[JBoss JIRA] Created: (JBAS-5558) AnnotationMetaDataDeployer should be rewritten to not load the classes

by Kabir Khan (JIRA)

AnnotationMetaDataDeployer should be rewritten to not load the classes ---------------------------------------------------------------------- Key: JBAS-5558 URL: http://jira.jboss.com/jira/browse/JBAS-5558 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Scott M Stark Fix For: JBossAS-5.0.0.CR1 -- 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

16 years, 3 months

5
14
0 / 0

[JBoss JIRA] Created: (JBAS-6225) MetaData repository loader for ServiceMetaData annotations

by Scott M Stark (JIRA)

MetaData repository loader for ServiceMetaData annotations ---------------------------------------------------------- Key: JBAS-6225 URL: https://jira.jboss.org/jira/browse/JBAS-6225 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: MicroContainer bus, ProfileService, System service Affects Versions: JBossAS-5.0.0.CR2 Reporter: Scott M Stark Assignee: Ales Justin Fix For: JBossAS-5.0.0.GA See forum discussion about how we can introduce an annotation such as: <annotation> @org.jboss.system.deployers.managed.ManagementObjectClass(code=org.jboss.jms.server.destination.QueueServiceMO) </annotation> For all org.jboss.jms.server.destination.QueueService rather than having to add the annotation to each mbean deployment: <mbean code="org.jboss.jms.server.destination.QueueService" name="jboss.messaging.destination:service=Queue,name=DLQ" xmbean-dd="xmdesc/Queue-xmbean.xml"> <annotation>@org.jboss.system.deployers.managed.ManagementObjectClass(code=org.jboss.jms.server.destination.QueueServiceMO)</annotation> <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends> <depends>jboss.messaging:service=PostOffice</depends> </mbean> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

3
2
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 September 2009