June 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (GPD-348) jdpl.xml xmlns altered wrong

by Johan Kumps (JIRA)

jdpl.xml xmlns altered wrong ---------------------------- Key: GPD-348 URL: https://jira.jboss.org/jira/browse/GPD-348 Project: JBoss jBPM GPD Issue Type: Bug Affects Versions: jBPM jPDL Designer 4.0.0.beta2 Reporter: Johan Kumps Assignee: Koen Aers Priority: Minor When changing the layout in the diagram view, the xmlns="http://jbpm.org/4.0/jpdl" is altered to xmlns="http://jbpm.org/4/jpdl" causing : org.jbpm.api.JbpmException: error: no start activity in process at org.jbpm.pvm.internal.xml.ProblemList.getJbpmException(ProblemList.java:169) at org.jbpm.pvm.internal.xml.ProblemList.getJbpmException(ProblemList.java:142) at org.jbpm.pvm.internal.repository.RepositorySessionImpl.deploy(RepositorySessionImpl.java:58) at org.jbpm.pvm.internal.cmd.DeployCmd.execute(DeployCmd.java:47) at org.jbpm.pvm.internal.cmd.DeployCmd.execute(DeployCmd.java:33) at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42) at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:54) at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:54) at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55) at org.jbpm.pvm.internal.repository.DeploymentImpl.deploy(DeploymentImpl.java:81) at org.jbpm.pvm.internal.ant.JbpmDeployTask.deployFile(JbpmDeployTask.java:108) at org.jbpm.pvm.internal.ant.JbpmDeployTask.execute(JbpmDeployTask.java:60) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1189) at org.apache.tools.ant.Main.runBuild(Main.java:758) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) -- 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

17 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (GPD-345) XML namespaces are not consistent between GPD and the engine

by Alexis Seigneurin (JIRA)

XML namespaces are not consistent between GPD and the engine ------------------------------------------------------------ Key: GPD-345 URL: https://jira.jboss.org/jira/browse/GPD-345 Project: JBoss jBPM GPD Issue Type: Bug Reporter: Alexis Seigneurin Assignee: Koen Aers The graphical designer and the process engine do not use the same XML namespace. GPD uses http://jbpm.org/4/jpdl whereas the engine uses http://jbpm.org/4.0/jpdl. The consequence is that a process created with the designer does not work in the engine. You get errors like these: 2009-05-27 16:19:09,117 DEBUG [org.jbpm.jpdl.internal.xml.JpdlParser] - <unrecognized activity: start> 2009-05-27 16:19:09,117 DEBUG [org.jbpm.jpdl.internal.xml.JpdlParser] - <unrecognized activity: decision> 2009-05-27 16:19:09,117 DEBUG [org.jbpm.jpdl.internal.xml.JpdlParser] - <unrecognized activity: state> 2009-05-27 16:19:09,117 DEBUG [org.jbpm.jpdl.internal.xml.JpdlParser] - <unrecognized activity: state> 2009-05-27 16:19:09,117 DEBUG [org.jbpm.jpdl.internal.xml.JpdlParser] - <unrecognized activity: state> 2009-05-27 16:19:09,258 INFO [org.jbpm.pvm.internal.repository.RepositorySessionImpl] - <errors during deployment of deployment(96): error: no start activity in process > -- 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

17 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (GPD-328) support Java attributes and elements

by Koen Aers (JIRA)

support Java attributes and elements ------------------------------------ Key: GPD-328 URL: https://jira.jboss.org/jira/browse/GPD-328 Project: JBoss jBPM GPD Issue Type: Task Components: jpdl Reporter: Koen Aers Assignee: Koen Aers Fix For: jBPM jPDL Designer 4.0.0.CR1 attributes: class, method, var elements: field, arg -- 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

17 years, 1 month

1
2
0 / 0

[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

17 years, 1 month

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

17 years, 1 month

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

17 years, 1 month

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

17 years, 1 month

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

17 years, 1 month

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

17 years, 1 month

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

17 years, 1 month

1
3
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 June 2009