March 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-4150) DuplicateServiceException when deploying application a second time with different name, ServiceName not including EAR-name

by Frank Langelage (JIRA)

Frank Langelage created AS7-4150: ------------------------------------ Summary: DuplicateServiceException when deploying application a second time with different name, ServiceName not including EAR-name Key: AS7-4150 URL: https://issues.jboss.org/browse/AS7-4150 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.1.1.Final Reporter: Frank Langelage See also forum reference. Deployed ear-file with same structure and modules twice, only different persistence.xml because of database name. This gives an error with cause Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.security.jacc."ws-core.war" is already registered As you can see, the name of the module is only build of the module within the ear itself, the ear name itself is not used. Neither the file name of the ear itself nor the application-name from application.xml file. -- 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

14 years, 1 month

2
6
0 / 0

[JBoss JIRA] (AS7-4160) CLONE - Double-checked locking in org.jboss.weld.util.BeansClosure#getClosure is a cause for NPE

by Stuart Douglas (JIRA)

Stuart Douglas created AS7-4160: ----------------------------------- Summary: CLONE - Double-checked locking in org.jboss.weld.util.BeansClosure#getClosure is a cause for NPE Key: AS7-4160 URL: https://issues.jboss.org/browse/AS7-4160 Project: Application Server 7 Issue Type: Bug Components: CDI / Weld Affects Versions: 7.1.0.Final, 7.1.1.Final Environment: N/A Reporter: Anton Arhipov Assignee: Stuart Douglas Application deployment fails with a following exception: 05:33:26,201 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.deployment.unit."exp-cdi-injectApplication.war".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."exp-cdi-injectApplication.war".WeldService: java.lang.NullPointerException at org.jboss.as.weld.services.WeldService.start(WeldService.java:83) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_27] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_27] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_27] Caused by: java.lang.NullPointerException at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:194) at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:336) at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) ... 5 more Looking at the code that belongs to weld-core-1.1.5.AS71.Final, we can see the following at the lines 193-194 of BeanDeployment: 193: BeansClosure closure = BeansClosure.getClosure(this.beanManager); 194: closure.addEnvironment(this.beanDeployer.getEnvironment()); Which leads to a conclusion that closure is null (the lines prior to the mentioned ones show that beanDeployer itself couldn't be null). Looking into BeansClosure#getClosure(): public static BeansClosure getClosure(BeanManagerImpl beanManager) { BeansClosure closure = (BeansClosure)closureMap.get(beanManager); if (closure == null) { synchronized (closureMap) { if (!closureMap.containsKey(beanManager)) { closure = new BeansClosure(); for (Iterable beanManagers : BeanManagers.getAccessibleClosure(beanManager)) { for (BeanManagerImpl accessibleBeanManager : beanManagers) { closureMap.put(accessibleBeanManager, closure); } } } } } return closure; } To prevent race conditions, maybe it makes sense to reside the full method body into synchronized block. -- 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

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBBUILD-701) Configure jboss-parent to deploy full project sources as part of each release

by Paul Gier (JIRA)

Configure jboss-parent to deploy full project sources as part of each release ----------------------------------------------------------------------------- Key: JBBUILD-701 URL: https://issues.jboss.org/browse/JBBUILD-701 Project: JBoss Build System Issue Type: Enhancement Components: JBoss Parent POM Reporter: Paul Gier Assignee: Paul Gier Fix For: JBoss Parent POM - 7 For each JBoss project release, the full source zip should be deployed along with the other artifacts. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (AS7-1893) JDBC cache store configuration improvements

by Manik Surtani (JIRA)

JDBC cache store configuration improvements ------------------------------------------- Key: AS7-1893 URL: https://issues.jboss.org/browse/AS7-1893 Project: Application Server 7 Issue Type: Feature Request Components: Clustering Reporter: Manik Surtani Assignee: Paul Ferraro Fix For: 7.1.0.Beta1 The current <jdbc-store ...> element isn't quite explicit enough to differentiate between the 3 types of JDBC cache stores Infinispan has to offer. <string-keyed-jdbc-store ... >, <binary-keyed-jdbc-store ... > and <mixed-keyed-jdbc-store ... > may be better. Similarly, <bucket-table> and <entry-table> expose implementation details. <binary-keyed-table ...> and <string-keyed-table ... > may be better. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

7
15
0 / 0

[JBoss JIRA] Created: (JBRULES-3007) Planner: tabu size is not respected when there are multiple tabus per property tabu

by Geoffrey De Smet (JIRA)

Planner: tabu size is not respected when there are multiple tabus per property tabu ----------------------------------------------------------------------------------- Key: JBRULES-3007 URL: https://issues.jboss.org/browse/JBRULES-3007 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-planner Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet This code is the problem in AbstractTabuAcceptor: while (tabuSequenceList.size() >= maximumTabuListSize) { Consider these moves: move 1 (tabu A, tabu B, tabu C) move 2 (tabu D, tabu E, tabu F, tabu G) move 3 (tabu A, tabu B) and a tabu move size of 4, then move 3 isn't seen as tabu with move 1, while it should be! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
1
0 / 0

[JBoss JIRA] (AS7-4140) Change distributtion of -Dmcast through testsuite

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/AS7-4140?page=com.atlassian.jira.plugin.s... ] Richard Achmatowicz commented on AS7-4140: ------------------------------------------ OK by me. > Change distributtion of -Dmcast through testsuite > ------------------------------------------------- > > Key: AS7-4140 > URL: https://issues.jboss.org/browse/AS7-4140 > Project: Application Server 7 > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 7.1.1.Final > Reporter: Pavel Janousek > Assignee: Ondrej Zizka > Priority: Blocker > Fix For: 7.1.2.Final > > > Please change present behavior. > We need to define only one property -Dmcast (for ex., the name doesn't matter now) as command line parameter - this multicast address is needed to be distributed to every subsystem which manages any multicast communication. It is needed to be unique in every subsystem - JGroups, HornetQ etc. because we must avoid to interfere each other => port assignation must be unique for every a such component. > This change is needed in both - IPV4 and IPv6... -- 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

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4140) Change distributtion of -Dmcast through testsuite

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/AS7-4140?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka commented on AS7-4140: ----------------------------------- I'll get to this at the end of this week, is that ok? I'll include it in a bunch of other updates. > Change distributtion of -Dmcast through testsuite > ------------------------------------------------- > > Key: AS7-4140 > URL: https://issues.jboss.org/browse/AS7-4140 > Project: Application Server 7 > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 7.1.1.Final > Reporter: Pavel Janousek > Assignee: Ondrej Zizka > Priority: Blocker > Fix For: 7.1.2.Final > > > Please change present behavior. > We need to define only one property -Dmcast (for ex., the name doesn't matter now) as command line parameter - this multicast address is needed to be distributed to every subsystem which manages any multicast communication. It is needed to be unique in every subsystem - JGroups, HornetQ etc. because we must avoid to interfere each other => port assignation must be unique for every a such component. > This change is needed in both - IPV4 and IPv6... -- 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

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4140) Change distributtion of -Dmcast through testsuite

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/AS7-4140?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka reassigned AS7-4140: --------------------------------- Assignee: Ondrej Zizka (was: Richard Achmatowicz) > Change distributtion of -Dmcast through testsuite > ------------------------------------------------- > > Key: AS7-4140 > URL: https://issues.jboss.org/browse/AS7-4140 > Project: Application Server 7 > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 7.1.1.Final > Reporter: Pavel Janousek > Assignee: Ondrej Zizka > Priority: Blocker > Fix For: 7.1.2.Final > > > Please change present behavior. > We need to define only one property -Dmcast (for ex., the name doesn't matter now) as command line parameter - this multicast address is needed to be distributed to every subsystem which manages any multicast communication. It is needed to be unique in every subsystem - JGroups, HornetQ etc. because we must avoid to interfere each other => port assignation must be unique for every a such component. > This change is needed in both - IPV4 and IPv6... -- 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

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4140) Change distributtion of -Dmcast through testsuite

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/AS7-4140?page=com.atlassian.jira.plugin.s... ] Richard Achmatowicz commented on AS7-4140: ------------------------------------------ I mentioned earlier in this JIRA that I was seeing test failures whentesting with IPv6 addresses on my local machine. This was due to testsuite configuration errors concerning using distinct nodes and port offsets in the arquillian.xml file and only using port offsets when building the configuration. Tese were fixed by Jason last week. So it looks as though the IPv6 testsuite runs fine, both with loppback and non-loopback global addresses. > Change distributtion of -Dmcast through testsuite > ------------------------------------------------- > > Key: AS7-4140 > URL: https://issues.jboss.org/browse/AS7-4140 > Project: Application Server 7 > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 7.1.1.Final > Reporter: Pavel Janousek > Assignee: Richard Achmatowicz > Priority: Blocker > Fix For: 7.1.2.Final > > > Please change present behavior. > We need to define only one property -Dmcast (for ex., the name doesn't matter now) as command line parameter - this multicast address is needed to be distributed to every subsystem which manages any multicast communication. It is needed to be unique in every subsystem - JGroups, HornetQ etc. because we must avoid to interfere each other => port assignation must be unique for every a such component. > This change is needed in both - IPV4 and IPv6... -- 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

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4140) Change distributtion of -Dmcast through testsuite

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/AS7-4140?page=com.atlassian.jira.plugin.s... ] Richard Achmatowicz edited comment on AS7-4140 at 3/13/12 1:49 PM: ------------------------------------------------------------------- I mentioned earlier in this JIRA that I was seeing test failures whentesting with IPv6 addresses on my local machine. This was due to testsuite configuration errors concerning using distinct nodes and port offsets in the arquillian.xml file and only using port offsets when building the configuration. These issues were fixed by Jason last week. So it looks as though the IPv6 testsuite runs fine, both with loopback and non-loopback global addresses. was (Author: rachmato): I mentioned earlier in this JIRA that I was seeing test failures whentesting with IPv6 addresses on my local machine. This was due to testsuite configuration errors concerning using distinct nodes and port offsets in the arquillian.xml file and only using port offsets when building the configuration. Tese were fixed by Jason last week. So it looks as though the IPv6 testsuite runs fine, both with loppback and non-loopback global addresses. > Change distributtion of -Dmcast through testsuite > ------------------------------------------------- > > Key: AS7-4140 > URL: https://issues.jboss.org/browse/AS7-4140 > Project: Application Server 7 > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 7.1.1.Final > Reporter: Pavel Janousek > Assignee: Richard Achmatowicz > Priority: Blocker > Fix For: 7.1.2.Final > > > Please change present behavior. > We need to define only one property -Dmcast (for ex., the name doesn't matter now) as command line parameter - this multicast address is needed to be distributed to every subsystem which manages any multicast communication. It is needed to be unique in every subsystem - JGroups, HornetQ etc. because we must avoid to interfere each other => port assignation must be unique for every a such component. > This change is needed in both - IPV4 and IPv6... -- 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

14 years, 1 month

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 March 2012