July 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-1361) Arquillian AS7 Container force a dependency on Arquillian Service in manifest.mf

by Aslak Knutsen (JIRA)

Arquillian AS7 Container force a dependency on Arquillian Service in manifest.mf -------------------------------------------------------------------------------- Key: AS7-1361 URL: https://issues.jboss.org/browse/AS7-1361 Project: Application Server 7 Issue Type: Bug Components: Test Suite Affects Versions: 7.0.0.Final Reporter: Aslak Knutsen Assignee: Andrew Rubinger Fix For: 7.0.1.Final When trying to e.g. use the Servlet Protocol instead of the jmx-as7 protocol you will get the following exception: ["jboss.deployment.unit.\"624b14c4-2bb2-4d44-be9e-1168c4d29164.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.arquillian-service\".main ] The AS7 container adds a dependency to the Arquillian Service using ApplicationArchiveProcessors which is a general purpose archive processor and it not tied to the Protocol itself. This handling needs to be moved to the DeploymentPackager. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-8923) WAR with bundled Mojarra 2.1.0-b11

by Lukas Fryc (JIRA)

WAR with bundled Mojarra 2.1.0-b11 ---------------------------------- Key: JBAS-8923 URL: https://issues.jboss.org/browse/JBAS-8923 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JSF Affects Versions: 6.0.0.Final Environment: RichFaces 4.0.0.20110227-CR1 r.21967 Mojarra 2.1.0-FCS JBoss AS 6.0.0.Final (default profile) OpenJDK Runtime Environment 1.6.0_20-b20 @ Linux http://anonsvn.jboss.org/repos/richfaces/modules/tests/metamer/tags/metam... Reporter: Lukas Fryc Assignee: Stan Silvert When new profile Mojarra-2.1 (with 2.1.0-b11 libs) is created and WAR without jsf-libs is deployed, application works fine. But when JSF is bundled into WAR (and use WAR_BUNDLES_JSF_IMPL param) and deployed onto default Mojarra-2.0 profile, it doesn't work with exception bellow. Shortened stacktrace: 17:42:14,288 ERROR [[/metamer]] Error configuring application listener of class com.sun.faces.application.ServletContextSensitiveSingletonStore: java.lang.InstantiationException: com.sun.faces.application.ServletContextSensitiveSingletonStore at java.lang.Class.newInstance0(Class.java:357) [:1.6.0_20] at java.lang.Class.newInstance(Class.java:325) [:1.6.0_20] at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:280) [:6.0.0.Final] at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:264) [:6.0.0.Final] at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3319) [:6.0.0.Final] at org.apache.catalina.core.StandardContext.start(StandardContext.java:3828) [:6.0.0.Final] at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:294) [:6.0.0.Final] at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:146) [:6.0.0.Final] at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:477) [:6.0.0.Final] at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) [:6.0.0.Final] at org.jboss.web.deployers.WebModule.start(WebModule.java:95) [:6.0.0.Final] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.6.0_20] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.6.0_20] at java.lang.reflect.Method.invoke(Method.java:616) [:1.6.0_20] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.GA] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.GA] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.GA] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.GA] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.GA] at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206) [:2.2.0.GA] ... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

5
9
0 / 0

[JBoss JIRA] Created: (JGRP-1309) Discovery: max_rank doesn't make any sense

by Bela Ban (JIRA)

Discovery: max_rank doesn't make any sense ------------------------------------------ Key: JGRP-1309 URL: https://issues.jboss.org/browse/JGRP-1309 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.0 Discovery.max_rank was originally meant to reduce traffic in the discovery phase: rather than 100 members replying to a discovery request, only the coordinators (max_rank=1) would reply and this would be enough for a joiner to find the coordinator and send it a JOIN request. However, discovery responses also contain additional information, such as the logical name (if set) and the physical address of a member. This is needed by all members of a cluster, and so everyone should return this information to a new joiner. Seen under this aspect, max_rank is useless and even conter-productive ! If we have 100 members: - max_rank=0: we get 100 discovery responses - max_rank=1 (sets return_entire_cache to true): the coordinator return the entire cache to the joiner (1 unicast / cache entry: 100 unicasts) - max_rank=2: the coordinator plus the next in line return the entire cache: 200 unicasts - and so on The current problem is that ergonomics sets return_entire_cache which - in conjunction with max_rank > 0 - generates even more discovery responses than is max_rank is 0 ! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
7
0 / 0

[JBoss JIRA] Created: (JBAS-8551) tests.classpath length impacts running tests on Windows

by Shelly McGowan (JIRA)

tests.classpath length impacts running tests on Windows ------------------------------------------------------- Key: JBAS-8551 URL: https://jira.jboss.org/browse/JBAS-8551 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Shelly McGowan Assignee: Shelly McGowan Fix For: 6.0.0.CR1 http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-Wind... -- 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

14 years, 4 months

4
16
0 / 0

[JBoss JIRA] Created: (JBAS-8627) Fix testsuite failures affecting 6.0.0.Final release

by Shelly McGowan (JIRA)

Fix testsuite failures affecting 6.0.0.Final release ---------------------------------------------------- Key: JBAS-8627 URL: https://jira.jboss.org/browse/JBAS-8627 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Reporter: Shelly McGowan Assignee: Shelly McGowan Fix For: 6.0.0.Final -- 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

14 years, 4 months

1
5
0 / 0

[JBoss JIRA] Created: (JBAS-9428) org.jboss.test.jca.test.DataSourceDeployerTestCase - JTS

by Shelly McGowan (JIRA)

org.jboss.test.jca.test.DataSourceDeployerTestCase - JTS -------------------------------------------------------- Key: JBAS-9428 URL: https://issues.jboss.org/browse/JBAS-9428 Project: Legacy JBoss Application Server 6 Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Shelly McGowan testBasicDeployment: javax.management.InstanceNotFoundException: jboss.jca:name=DSEARXML,service=ManagedConnectionFactory is not registered. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-9155) jboss processes only one persistence.xml file per war file

by Vincent A (JIRA)

jboss processes only one persistence.xml file per war file ----------------------------------------------------------- Key: JBAS-9155 URL: https://issues.jboss.org/browse/JBAS-9155 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JPA / Hibernate Affects Versions: 6.0.0.Final Reporter: Vincent A Assignee: Scott Marlow If a war file contains several Persistence Archive jars, JBoss starts only the persitence unit(s) defined in the first jar it scans, ignoring the remaining ones. For instance, given the following war file: {code} my-war +-- WEB-INF +-- lib +-- pu1.jar +-- META-INF + persistence.xml // <persistence-unit name="pu1" >...</persistence-unit> +-- pu2.jar +-- META-INF + persistence.xml // <persistence-unit name="pu2" >...</persistence-unit>}} {code} Jboss will only starts the pu1 persistence unit. And if the war file has the following structure: {code} my-war +-- WEB-INF +-- classes +-- META-INF + persistence.xml // <persistence-unit name="pu0" >...</persistence-unit> +-- lib +-- pu1.jar +-- META-INF + persistence.xml // <persistence-unit name="pu1" >...</persistence-unit> +-- pu2.jar +-- META-INF + persistence.xml // <persistence-unit name="pu2" >...</persistence-unit> {code} Jboss starts pu0, and skips the PU's defined in pu1.jar and pu2.jar. This behaviour is non-compliant. Section 6.2 of the spec states that: {quote} A persistence unit may be packaged within one or more jar files contained within a WAR or EAR, as a set of classes within an EJB-JAR file or in the WAR classes directory, or as a combination of these as defined below. {quote} [...] {quote} It is not required that an EJB-JAR or WAR containing a persistence unit be packaged in an EAR unless the persistence unit contains persistence classes in addition to those contained in the EJB-JAR or WAR. {quote} And from section 7: {quote} 7.1.1 Responsibilities of the Container At deployment time the container is responsible for scanning the locations specified in Section 6.2 and discovering the persistence.xml files and processing them. When the container finds a persistence.xml file, it processes the persistence unit definitions that it contains. {quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

4
11
0 / 0

[JBoss JIRA] Created: (JBAS-8896) @Inject:ed EJBs not considered dependencies when resolving startup order

by Nicklas Karlsson (JIRA)

@Inject:ed EJBs not considered dependencies when resolving startup order ------------------------------------------------------------------------ Key: JBAS-8896 URL: https://issues.jboss.org/browse/JBAS-8896 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: 6.0.0.Final Reporter: Nicklas Karlsson Assignee: Carlo de Wolf I have a asynchronous @Startup @Singleton that @Inects a @Stateless EJB, but it dies in @PostConstruct since apparently the dependency isn't ready. If I inject the dependency with @EJB, everything is fine. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

4
6
0 / 0

[JBoss JIRA] Created: (JBAS-8807) Track Component Upgrades for 6.0.1 Release

by Shelly McGowan (JIRA)

Track Component Upgrades for 6.0.1 Release ------------------------------------------ Key: JBAS-8807 URL: https://issues.jboss.org/browse/JBAS-8807 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Integration Reporter: Shelly McGowan Assignee: Shelly McGowan Container task for component upgrades intended for 6.0.1 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-1315) Discovery: don't send view back with discovery response

by Bela Ban (JIRA)

Discovery: don't send view back with discovery response ------------------------------------------------------- Key: JGRP-1315 URL: https://issues.jboss.org/browse/JGRP-1315 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12.2, 3.0 We send back a View with each discovery response. This is wasteful if we have large clusters. SOLUTION: change this to only return the coordinator's address for initial discovery. Note: look into only returning the ViewId for merge triggered discovery -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
8
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 July 2011