February 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBASMP-10) Remove EJB3 TestRunner Plugin from Aggregator

by Andrew Lee Rubinger (JIRA)

Remove EJB3 TestRunner Plugin from Aggregator --------------------------------------------- Key: JBASMP-10 URL: https://jira.jboss.org/jira/browse/JBASMP-10 Project: JBoss AS Maven Plugins Issue Type: Task Affects Versions: 0.1.0 Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger The EJB3 TestRunner Plugin is now deprecated in favor of moving the EJB3 TestSuite to either AS or Core/Embedded Unit tests -- 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, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (JBASMP-6) Align current versions to all start at 0.1.0-SNAPSHOT

by Andrew Lee Rubinger (JIRA)

Align current versions to all start at 0.1.0-SNAPSHOT ----------------------------------------------------- Key: JBASMP-6 URL: http://jira.jboss.com/jira/browse/JBASMP-6 Project: JBoss AS Maven Plugins Issue Type: Task Components: build, common, control-example, control-plugin Reporter: Andrew Lee Rubinger Assigned To: Andrew Lee Rubinger Fix For: 0.1.0 POMs should be set to same version, 0.1.0-SNAPSHOT, including the Aggregator POM -- 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, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (JBBUILD-682) http://repository.jboss.org/maven2/ serving HTTP 403 to hosts outside RedHat VPN

by Marek Schmidt (JIRA)

http://repository.jboss.org/maven2/ serving HTTP 403 to hosts outside RedHat VPN -------------------------------------------------------------------------------- Key: JBBUILD-682 URL: https://issues.jboss.org/browse/JBBUILD-682 Project: JBoss Build System Issue Type: Bug Reporter: Marek Schmidt Assignee: Paul Gier Priority: Critical The legacy maven repository http://repository.jboss.org/maven2/ is serving HTTP 403 to hosts outside RedHat VPN, causing lots of builds to fail. e.g. http://community.jboss.org/message/606819?tstart=0 with error: Access denied to: http://repository.jboss.org/maven2/trove/trove/2.1.1/trove-2.1.1.pom -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

11
23
0 / 0

[JBoss JIRA] Created: (JBBUILD-666) upload hsqldb 2.0.1-rc3 to our nexus

by Strong Liu (JIRA)

upload hsqldb 2.0.1-rc3 to our nexus ------------------------------------ Key: JBBUILD-666 URL: https://issues.jboss.org/browse/JBBUILD-666 Project: JBoss Build System Issue Type: Task Components: Sonatype Reporter: Strong Liu Assignee: Paul Gier since hsqldb 2.0.0 has some problems, we need 2.0.1-rc3 to run the test now, only 2.0.0 is available on the nexus (maven-central) so, would you please upload this one http://sourceforge.net/projects/hsqldb/files/alpha_beta/hsqldb-2.0.1-rc3.... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-8134) Common mechanism for all secure socket definitions

by Brian Stansberry (JIRA)

Common mechanism for all secure socket definitions -------------------------------------------------- Key: JBAS-8134 URL: https://jira.jboss.org/browse/JBAS-8134 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Fix For: Unscheduled This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010: >> The JAASSecurityDomain in my opinion should >> handle all secure socket definitions. Mod-cluster currently does >> not support JAASSecurityDomains. I won't comment either way on whether JAASSecurityDomain is how we'll do this, but I definitely agree that a common mechanism should be used for all secure socket definitions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

6
12
0 / 0

[JBoss JIRA] Created: (JGRP-1326) Gossip Router dropping message for node that is in its routing table list

by vivek v (JIRA)

Gossip Router dropping message for node that is in its routing table list ------------------------------------------------------------------------- Key: JGRP-1326 URL: https://issues.jboss.org/browse/JGRP-1326 Project: JGroups Issue Type: Bug Affects Versions: 2.10 Environment: Linux, Windows Reporter: vivek v Assignee: Bela Ban We are using Tunnel protocol with two Gossip Routers. For some reason we start seeing lots of suspect messages in all the nodes - there are 7 nodes in the group. Six of the nodes (including the coordinator) was suspecting node A (manager_172.27.75.11) and node A was suspecting the coordinator, but no new view was being created. After turning on the trace on both gossip routers (GR1 and GR2) I see following for every message that's sent to Node A (manager_172.27.75.11), {noformat} 2011-05-20 15:56:21,186 TRACE [gossip-handlers-6] GossipRouter - cannot find manager_172.27.75.11:4576 in the routing table, routing table= 172.27.75.11_group: probe_172.27.75.13:4576, collector_172.27.75.12:4576, probe_172.27.75.15:4576, manager_172.27.75.11:4576, probe_172.27.75.16:4576, probe_172.27.75.14:4576 {noformat} Now, the issue is the routing table does indeed shows that there is "manager_172.27.75.11" - so why is the GR dropping messages for that node. I suspect that somehow the Gossip Router has got some old entry which has not been cleaned up - different UUID with same logical address. I tried going through the GossipRouter.java code, but couldn't find how would this be possible. As I understand a node randomly chooses a GR if there are multiple of them for its communication. Each GR would keep a separate list of physical addresses for each node - so is it possible somehow it uses physical address instead of UUID for cleaning/retrieving the node list? This seems to be creating big issue and the only work around is to restart the Gossip Routers. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
13
0 / 0

[JBoss JIRA] Created: (JGRP-1165) Out-of-sync views in the cluster causes NAKACK issues and invalid node list at application layer

by vivek v (JIRA)

Out-of-sync views in the cluster causes NAKACK issues and invalid node list at application layer ------------------------------------------------------------------------------------------------- Key: JGRP-1165 URL: https://jira.jboss.org/jira/browse/JGRP-1165 Project: JGroups Issue Type: Bug Affects Versions: 2.9, 2.8 Reporter: vivek v Assignee: Bela Ban There is a logic in GMS (in the installView(..) method) where it checks whether the node itself is in the view or not, if not then just discard the view, if(checkSelfInclusion(mbrs) == false) { if(log.isWarnEnabled()) log.warn(local_addr + ": not member of view " + new_view + "; discarding it"); return; } Now, the problem /w this logic is that the node will remain /w the old view and when trying to send message to the members in the old view the messages would be discarded /w NAKACK as this node won't be there in their new view. So here is an example, 1) 3 nodes all with same view - V1 {n1, n2, n3} 2) n1 (coordinator) suspects (due to missing heartbeat) n2 and publishes new view - V2 {n1, n3} - n2 discards the suspect message from n1 as FD_SOCK is still connected 3) n2 receives this view, but discards it due to the logic in GMS 4) n2 still keeps the old view V1 and continue to send messages to n1 and n3. n1 and n3 will discard messages from n2 /w NAKACK as it's not in their view (V2). 5) After few minutes (could be 10-15 minutes or more) n1 will publish a merge view V3(n1, n2,n3} - joining V1 and V2. Now all nodes got the same view The problem is on n2 the application layer will never know that it can't talk to n1 and n3 - thus, the RPC calls will fail during the time the nodes had different views. I would assume if a node gets a view, which doesn't have itself in it - it should drop all the nodes that are in that new view. So, basically we will create two new subgroups. This way we won't discard messages from each other. The application layer needs to know at all times what nodes can it talk to. -- 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, 6 months

4
23
0 / 0

[JBoss JIRA] Created: (AS7-1928) Allow deployments to get access to the META-INF folder of their dependency module

by Marius Bogoevici (JIRA)

Allow deployments to get access to the META-INF folder of their dependency module --------------------------------------------------------------------------------- Key: AS7-1928 URL: https://issues.jboss.org/browse/AS7-1928 Project: Application Server 7 Issue Type: Feature Request Affects Versions: 7.1.0.Alpha1 Reporter: Marius Bogoevici Priority: Critical Currently there is absolutely no mechanism (outside of manipulating dependencies programmatically through a subsystem) for deployments to get access to some META-INF/xyz files from a module that they declare as a dependency, except are in META-INF/services. This is a serious impediment when considering the installation of third party libraries as shared libraries (modules) in JBoss AS. Some frameworks may rely upon locating internal descriptors in META-INF, and if the libraries are installed as modules, the descriptors are not accessible to the framework. Essentially, there is no way of accessing resources under META-INF unless they are either services, or the library is packaged in the deployment. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

8
21
0 / 0

[JBoss JIRA] (AS7-2847) TS: Clustering tests cant be run for single test with -Dtest=

by Radoslav Husar (Created) (JIRA)

TS: Clustering tests cant be run for single test with -Dtest= ------------------------------------------------------------- Key: AS7-2847 URL: https://issues.jboss.org/browse/AS7-2847 Project: Application Server 7 Issue Type: Bug Components: Clustering, Documentation, Test Suite Affects Versions: 7.1.0.Beta1 Reporter: Radoslav Husar Assignee: Paul Ferraro Fix For: 7.1.0.CR1 Maybe I missed something? {code}./integration-tests.sh clean install -Dts.clust -Dts.noSmoke{code} works okay, but when I do: {code}./integration-tests.sh clean install -Dts.clust -Dts.noSmoke -Dtest=org.jboss.as.test.clustering.cluster.ClusteredWebTestCase.java{code} then I get: {code} ------------------------------------------------------- T E S T S ------------------------------------------------------- Running org.jboss.as.test.clustering.cluster.ClusteredWebTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.915 sec <<< FAILURE! Results : Tests in error: org.jboss.as.test.clustering.cluster.ClusteredWebTestCase: DeploymentScenario contains targets not matching any defined Container in the registry. clustering-udp-1. Possible causes are: No Deployable Container found on Classpath or your have defined a @org.jboss.arquillian.container.test.api.Deployment with a @org.jboss.arquillian.container.test.api.TargetsContainer value that does not match any found/configured Containers (see arquillian.xml container@qualifier) Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 {code} Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

8
14
0 / 0

[JBoss JIRA] (AS7-2448) TS: Check logging

by Ondřej Chaloupka (Created) (JIRA)

TS: Check logging ------------------ Key: AS7-2448 URL: https://issues.jboss.org/browse/AS7-2448 Project: Application Server 7 Issue Type: Sub-task Reporter: Ondřej Chaloupka Assignee: Ondrej Zizka ./integration-tests.sh clean install -Dtest=org.jboss.as.test.integration.ejb.async.* -Dintegration.module -Dbasic.integration.tests -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

8
9
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 February 2012