June 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-6996) ClassNotFoundException for array types in JDK6

by Mike Van Noord (JIRA)

ClassNotFoundException for array types in JDK6 ---------------------------------------------- Key: JBAS-6996 URL: https://jira.jboss.org/jira/browse/JBAS-6996 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX Affects Versions: JBossAS-5.1.0.GA Environment: JDK 1.6 Reporter: Mike Van Noord Assignee: Dimitris Andreadis org.jboss.mx.server.InvocationContext uses the ClassLoader.loadClass() call rather than Class.forName(). Due to a behavioral change from Java 5 to Java 6, this call now throws a ClassNotFoundException when that class is of an array type, e.g. "[Ljava.lang.String;". The situation is the same as the one described here: https://jira.jboss.org/jira/browse/JBRULES-1553 -- 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

14 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBSPRING-6) Modify the Maven build file to create the spring.deployer

by Marius Bogoevici (JIRA)

Modify the Maven build file to create the spring.deployer --------------------------------------------------------- Key: JBSPRING-6 URL: https://jira.jboss.org/jira/browse/JBSPRING-6 Project: JBoss Spring Integration Issue Type: Feature Request Reporter: Marius Bogoevici Assignee: Marius Bogoevici -- 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

14 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-6942) Expose a testConnection operation via JMX

by Heiko W. Rupp (JIRA)

Expose a testConnection operation via JMX ----------------------------------------- Key: JBAS-6942 URL: https://jira.jboss.org/jira/browse/JBAS-6942 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JCA service Reporter: Heiko W. Rupp Assignee: Jesper Pedersen Fix For: JBossAS-5.1.0.GA Hi, would it be possible to expose a "tesConnection" method to JMX and/or the profile service, that basically tries to get a connection with the backend database and returns true if this was successful. The connection itself could directly be closed or put back into the pool. Obtaining the connection should always try to really hit the database and not just get a connection from the pool (unless the valid connection checking mechanism is used, which may or may not be configured on a datasource). Such an operation could be very handy for tools like Jopr. -- 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

14 years, 10 months

4
5
0 / 0

[JBoss JIRA] Created: (JBMAN-85) Don't override the @ManagementObjectID with a default name.

by Emanuel Muckenhuber (JIRA)

Don't override the @ManagementObjectID with a default name. ----------------------------------------------------------- Key: JBMAN-85 URL: https://jira.jboss.org/jira/browse/JBMAN-85 Project: JBoss Managed Issue Type: Bug Affects Versions: JBossMan.2.1.1.Beta1 Reporter: Emanuel Muckenhuber Assignee: Emanuel Muckenhuber Fix For: JBossMan.2.1.1.Beta2 The ManagedObject.hasDefaultName needs to be set to false when setting a @ManagementObjectID, otherwise the default name will be used. -- 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

14 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMETA-201) Provide a validator to check for the presence of atleast one business interface on a EJB3 bean

by jaikiran pai (JIRA)

Provide a validator to check for the presence of atleast one business interface on a EJB3 bean ---------------------------------------------------------------------------------------------- Key: JBMETA-201 URL: https://jira.jboss.org/jira/browse/JBMETA-201 Project: JBoss Metadata Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 1.0.1.GA Reporter: jaikiran pai Assignee: jaikiran pai Provide a validator which validates that the EJB3 bean exposes atleast one business interface. Please see the referenced forum thread for details. -- 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

14 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-6995) portlet fails to start in liferay 5.2.3 Jboss 5.0.0 bundle but no errors

by John Hornsby (JIRA)

portlet fails to start in liferay 5.2.3 Jboss 5.0.0 bundle but no errors ------------------------------------------------------------------------ Key: JBAS-6995 URL: https://jira.jboss.org/jira/browse/JBAS-6995 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.GA Environment: Win Vista (also tried Win XP, and Ubuntu Linux), Java jdk1.5.0_07 (also tried java jdk1.6.0_02), Using HSQLDB. Same problem using the liferay-portal-jboss-tomcat-5.0-5.2.3.zip and the liferay-portal-jboss-tomcat-5.0-5.2.2.zip bundles. The portlet works successfully in liferay_tomcat bundles. Reporter: John Hornsby Problems deploying portlet successfully. The auto-deployment appears to work OK (there are no errors in any log) but it doesn't start up and doesn't appear in the Add Applications dialogue in Liferay: 10:00:05,753 INFO [STDOUT] Expanding: C:\LR523\deploy\konakartadmin.war into C:\Users\John\AppData\Local\Temp\20090602100005480 10:00:11,931 INFO [STDOUT] Copying 1 file to C:\Users\John\AppData\Local\Temp\20090602100005480\WEB-INF\classes 10:00:13,219 INFO [STDOUT] Warning: META-INF\MANIFEST.MF modified in the future. 10:00:13,560 INFO [STDOUT] Copying 149 files to C:\LR523\jbt\server\default\deploy\konakartadmin.war 10:00:17,393 INFO [STDOUT] Copying 1 file to C:\LR523\jbt\server\default\deploy\konakartadmin.war 10:00:18,027 INFO [STDOUT] Deleting directory C:\Users\John\AppData\Local\Temp\20090602100005480 10:00:23,125 INFO [STDOUT] 10:00:23,124 INFO [PortletAutoDeployListener] Portlets for C:\LR523\deploy\konakartadmin.war copied successfully. Deployment will start in a few seconds. 10:01:00,269 INFO [TomcatDeployment] deploy, ctxPath=/konakartadmin, vfsUrl=konakartadmin.war After the "Deployment will start in a few seconds." I would expect to see the service actually start but it doesn't. No clues as to why appear in the server .log, which actually reports that the war is fully deployed: 2009-06-02 10:55:53,745 DEBUG [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner) Initialized: {WebApplication: /C:/LR523/jbt/server/default/deploy/konakartadmin.war/, URL: vfsfile:/C:/LR523/jbt/server/default/deploy/konakartadmin.war/, classLoader: BaseClassLoader@13c92ad{vfsfile:/C:/LR523/jbt/server/default/deploy/konakartadmin.war/}:20746925} jboss.web:j2eeType=WebModule,name=//localhost/konakartadmin,J2EEApplication=none,J2EEServer=none 2009-06-02 10:55:53,750 DEBUG [org.jboss.deployers.plugins.deployers.DeployersImpl] (HDScanner) Fully Deployed vfsfile:/C:/LR523/jbt/server/default/deploy/konakartadmin.war/ When I shut JBoss down it tells me that the services (defined in my war) were not started: 10:49:13,352 INFO [ContainerBase] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/konakartadmin].[FileUpload] has not been started 10:49:13,373 INFO [ContainerBase] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/konakartadmin].[jsp] has not been started 10:49:13,393 INFO [ContainerBase] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/konakartadmin].[default] has not been started 10:49:13,412 INFO [ContainerBase] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/konakartadmin].[kk_admin_portlet] has not been started 10:49:13,433 INFO [ContainerBase] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/konakartadmin].[KonaKartAdminServlet] has not been started -- 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

14 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1840) StrictMaxPool does not maintain a correct "inUse" count leading to incorrect reporting of "AvailableCount"

by jaikiran pai (JIRA)

StrictMaxPool does not maintain a correct "inUse" count leading to incorrect reporting of "AvailableCount" ---------------------------------------------------------------------------------------------------------- Key: EJBTHREE-1840 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1840 Project: EJB 3.0 Issue Type: Bug Components: pool Affects Versions: 1.1.6 Reporter: jaikiran pai Assignee: jaikiran pai Fix For: 1.1.7 The org.jboss.ejb3.test.stateless.unit.MetricsUnitTestCase shows a failure w.r.t the "AvailableCount" of a bean marked with StrictMaxPool. The StrictMaxPool internally implements the getAvailableCount() as follows: public int getAvailableCount() { return maxSize - inUse; } The "inUse" count is handled incorrectly in the discard and remove method of this pool leading to that count reaching a negative value. Ultimately, this leads to incorrect available count being reported. When an exception occurs, the bean is discarded from the pool. This leads to a call on discard method of the StrictMaxPool which decrements the inUse count and then calls the remove method which *again* decrements the inUse count for the same bean context. -- 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

14 years, 10 months

1
3
0 / 0

[JBoss JIRA] Created: (JBBOOT-75) Don't use common lock for start/shutdown

by Andrew Lee Rubinger (JIRA)

Don't use common lock for start/shutdown ---------------------------------------- Key: JBBOOT-75 URL: https://jira.jboss.org/jira/browse/JBBOOT-75 Project: JBoss Bootstrap Issue Type: Feature Request Components: impl-base Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: 0.1.2 Both startup and shutdown block on the same "this" reference, meaning that the server may not be shutdown until startup is complete. Give each its own lock, and ensure that *all* operations mutating the internal state sync on both locks. -- 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

14 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMAN-84) Set a default MO.name to the MO.componentName

by Scott M Stark (JIRA)

Set a default MO.name to the MO.componentName --------------------------------------------- Key: JBMAN-84 URL: https://jira.jboss.org/jira/browse/JBMAN-84 Project: JBoss Managed Issue Type: Feature Request Components: managedobject Reporter: Scott M Stark Assignee: Scott M Stark Fix For: JBossMan.2.1.1.Beta1 If a ManagedObject has a defaulted name, the name should be set to the ManagedObject.componentName if one exists. -- 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

14 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5261) Check each DS and Destinations properties are accurate/needed

by Mark Spritzler (JIRA)

Check each DS and Destinations properties are accurate/needed ------------------------------------------------------------- Key: JBAS-5261 URL: http://jira.jboss.com/jira/browse/JBAS-5261 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Mark Spritzler -- 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

14 years, 10 months

5
14
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2009