July 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8671) ClassNotFoundException when a EJB Timer with custom info is deserialized

by Sipatha Shoko (JIRA)

ClassNotFoundException when a EJB Timer with custom info is deserialized ------------------------------------------------------------------------ Key: JBAS-8671 URL: https://jira.jboss.org/browse/JBAS-8671 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-5.1.0.GA Environment: WinXP 32 bit, Ubuntu 10.04 32 bit, SunOS 5.10 sparc Reporter: Sipatha Shoko Assignee: Carlo de Wolf When an EJB3 Timer is created, you can optionally specify information pertaining to the timer. The information object must be serializable. A TimerVo (packaged in the same jar as the EJB) object thats serializable is used as the information. The EJB is first deployed, the timer is correctly created. However if the server is restarted, a ClassNotFoundException for TimerVo is thrown when the previously saved timer is deserialised. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

4
5
0 / 0

[JBoss JIRA] Created: (JBAS-8814) Track EJB3 upgrades to AS trunk

by jaikiran pai (JIRA)

Track EJB3 upgrades to AS trunk ------------------------------- Key: JBAS-8814 URL: https://issues.jboss.org/browse/JBAS-8814 Project: JBoss Application Server Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: EJB3 Reporter: jaikiran pai Assignee: jaikiran pai Fix 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, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (AS7-1156) The JMX-AS7 Protocol should default to Remote

by Aslak Knutsen (JIRA)

The JMX-AS7 Protocol should default to Remote --------------------------------------------- Key: AS7-1156 URL: https://issues.jboss.org/browse/AS7-1156 Project: Application Server 7 Issue Type: Feature Request Components: Test Suite Affects Versions: 7.0.0.CR1 Reporter: Aslak Knutsen Currently the user has to provide this config for Arquillian to work with AS7 {code} <container qualifier="jboss7" default="true"> <protocol type="jmx-as7"> <property name="executionType">REMOTE</property> </protocol> </container> {code} With out that, they will get a nasty exception: {code} java.lang.reflect.UndeclaredThrowableException at $Proxy17.runTestMethodEmbedded(Unknown Source) at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:78) at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute( {code} Since Embedded mode is currently not used at all, Remote should be default. Possible the protocol can figure this out on it's own at runtime. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

2
3
0 / 0

[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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 months

4
11
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