May 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-1201) System property -Djgroups.ignore.bind_addr is ignored

by Bela Ban (JIRA)

System property -Djgroups.ignore.bind_addr is ignored ----------------------------------------------------- Key: JGRP-1201 URL: https://jira.jboss.org/jira/browse/JGRP-1201 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.10 ./run.sh in JBoss defaults to 127.0.0.1 In JGroups, by default the first non-loopback NIC is chosen. However, ./run.sh -Djgroups.ignore.bind_addr=true *still* uses the loopback 127.0.0.1 address ! -- 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

13 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-1200) GossipRouter: lookup fails when we have multiple GossipRouters and any of them throws an exception

by Bela Ban (JIRA)

GossipRouter: lookup fails when we have multiple GossipRouters and any of them throws an exception -------------------------------------------------------------------------------------------------- Key: JGRP-1200 URL: https://jira.jboss.org/jira/browse/JGRP-1200 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.10 Example: <TCPGOSSIP initial_hosts="A[12001],B[12001]" /> If GossipRouter on host A is not running, but B *is* running, then the discovery will return with an empty list because connecting to A threw an exception. SOLUTION: parallelize connections to A and B and ignore exception for non-available hosts -- 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

13 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (JBBUILD-590) Create a nexus plugin to allow users to see who uploaded an artifact

by Paul Gier (JIRA)

Create a nexus plugin to allow users to see who uploaded an artifact -------------------------------------------------------------------- Key: JBBUILD-590 URL: https://jira.jboss.org/jira/browse/JBBUILD-590 Project: JBoss Build System Issue Type: Task Components: Artifact Repositories Reporter: Paul Gier Fix For: Maven Repository 2.0 We need a nexus plugin that can display the user that uploaded specific artifacts and directories. -- 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

13 years, 11 months

1
2
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

13 years, 11 months

1
2
0 / 0

[JBoss JIRA] Closed: (JBCLUSTER-30) EJB3.0 and 2.1 clustering integration

by Brian Stansberry (JIRA)

[ https://jira.jboss.org/jira/browse/JBCLUSTER-30?page=com.atlassian.jira.p... ] Brian Stansberry closed JBCLUSTER-30. ------------------------------------- Fix Version/s: (was: Q2Y8) Resolution: Out of Date > EJB3.0 and 2.1 clustering integration > ------------------------------------- > > Key: JBCLUSTER-30 > URL: https://jira.jboss.org/jira/browse/JBCLUSTER-30 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assignee: Ben Wang > Original Estimate: 6 weeks > Remaining Estimate: 6 weeks > > Future ejb3.0 will run along side ejb2.1. In terms of clustering offering, ejb2.1 SFSB and entity bean will use the original implementation while 3.0 will use JBossCache and Hibernate. What's the clustering implication and integration needs? Or just pure documentation? -- 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

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-7561) Integrate AS module-level tests into smoke tests

by Brian Stansberry (JIRA)

Integrate AS module-level tests into smoke tests ------------------------------------------------ Key: JBAS-7561 URL: https://jira.jboss.org/jira/browse/JBAS-7561 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Blocker Fix For: JBossAS-6.0.0.CR1 A number of modules in the AS testsuite include tests that are never getting executed. How these are organized varies by module; typical is src/tests/org/jboss... with a build-test.xml file used to build and execute them via ant. These have never been part of the overall build (e.g. the way the maven 'test' goal is executed as part of 'install') nor are they run as part of the testsuite. With the mavenization of AS trunk, these tend to not even work via ant. But there are quite a number of meaningful tests that should not just be abandoned. This JIRA is a parent task for module-specific subtasks. The intent is to get these working via the maven 'test' goal. However, at this point we don't want to increase the already lengthy build time of trunk by executing them as part of a default install. However, we do want the hudson build to execute them and include the results with the smoke-tests target output it publishes. Perhaps we'll execute them via the smoke-tests target itself. These tests are meant to be fast unit tests, so any lengthy ones we find should probably be moved to the testsuite module. -- 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

13 years, 11 months

1
1
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

13 years, 11 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

13 years, 11 months

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-7988) Remove quartz update check and associate log message in AS

by Paul Gier (JIRA)

Remove quartz update check and associate log message in AS ---------------------------------------------------------- Key: JBAS-7988 URL: https://jira.jboss.org/jira/browse/JBAS-7988 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Paul Gier Fix For: 6.0.0.CR1 The quartz jar is currently automatically checking for updates and logging a message about the latest version available. Both of these should be removed. -- 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

13 years, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (JBJPA-27) support for detecting version from persistence.xml files and passing it to the JPA 2 provider

by Scott Marlow (JIRA)

support for detecting version from persistence.xml files and passing it to the JPA 2 provider --------------------------------------------------------------------------------------------- Key: JBJPA-27 URL: https://jira.jboss.org/jira/browse/JBJPA-27 Project: JBoss JPA Issue Type: Task Reporter: Scott Marlow Assignee: Carlo de Wolf Fix For: 1.0.1 -- 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

13 years, 11 months

1
12
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2010