September 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-1067) Use of Shutdown Hooks on ClusteredConnectionFactories

by Clebert Suconic (JIRA)

Use of Shutdown Hooks on ClusteredConnectionFactories ----------------------------------------------------- Key: JBMESSAGING-1067 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1067 Project: JBoss Messaging Issue Type: Feature Request Affects Versions: 1.4.0.CR2 Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: 1.4.0.GA ClusteredCF has a connection to receive updates on topology. We need to add a Shutdown hook to close the callback when the client is regularly finished. And this has to be done without holding hard references, so this will need to use WeakReferences. -- 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

18 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4463) escape syntax

by Alexey Loubyansky (JIRA)

escape syntax ------------- Key: JBAS-4463 URL: http://jira.jboss.com/jira/browse/JBAS-4463 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: CMP service Affects Versions: JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA Reporter: Alexey Loubyansky Assigned To: Alexey Loubyansky Fix For: JBossAS-5.0.0.Beta3, JBossAS-4.0.5.SP1 , JBossAS-4.2.1.CR1 Escape syntax should be {escape 'escape-character'} instead of plain escape 'escape-character'. See "5.1.6 SQL Escape Syntax in Statements" http://java.sun.com/j2se/1.4.2/docs/guide/jdbc/getstart/statement.html -- 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

18 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-743) Optionally allow swimlanes to perform assignment for each evaluation

by Brian Greene (JIRA)

Optionally allow swimlanes to perform assignment for each evaluation -------------------------------------------------------------------- Key: JBPM-743 URL: http://jira.jboss.com/jira/browse/JBPM-743 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Environment: All Reporter: Brian Greene Assigned To: Tom Baeyens Swimlanes are a very effective way to perform assignment, and we have implemented several that are nicely reusable. A swimlane though, isn't always (to my mind) the same actor or actors throughout the life of a process instance. In our case (and we've several use cases where this is applicable) a swimlane may represent an actor(s) that are related to a particular object or object in the process. The problem arises when the user(s) that are related to said object change in a long-running process. For example, a long running requisition process. The manager of the user who made the requisition may wish to have notifications as the process goes along (we have integrated email functionality in a custom extension). The most intuitive way to handle this as a process author is to use a swimlane that defines the relationship. The current jBPM TaskMgtInstance will only perform the assignment once per swimlane though, assuming that the SAME actor(s) will be used for the life of the process. Depending on what you're orchestrating, this may not be tenable. I think at the least there ought to be a way to allow a swimlane to configure a swimlane to perform its work every time it is referenced rather than using the previously determined actor(s). I've made a modification to jBPM to force swimlane instances to ALWAYS perform assignment, and while this fixes the issue in the short term, eventually I plan to modify either the global config for swimlanes, and better, add an attribute to the swimlane declaration that allows configurable behavior on a swimlane that will override the global default. In this way you could have the current behavior or configure the global setting to behave as I've discussed and provide an override to the current behavior on a case by case basis. You can get this behavior using nested assignment delegations, but there are reusability issues as well as the general cleanliness of the jPDL language to consider. We think swimlanes are in many cases more intuitive, and make the process definition much more readable. As we've discussed in internally, this seems reasonable, and seems to be required in a flexible environment supporting long running processes. -- 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

18 years, 10 months

6
7
0 / 0

[JBoss JIRA] Created: (JBPM-1049) ending task does not save form data, even when required=true is specified on form inputs

by Ross McDonald (JIRA)

ending task does not save form data, even when required=true is specified on form inputs ---------------------------------------------------------------------------------------- Key: JBPM-1049 URL: http://jira.jboss.com/jira/browse/JBPM-1049 Project: JBoss jBPM Issue Type: Bug Components: Web Interface Affects Versions: jBPM jPDL 3.2.1 Environment: tomcat 5.0.28, mysql 5.0.37 macbook pro, jbpm-jpdl-3.2.1 Reporter: Ross McDonald Assigned To: Tom Baeyens Hi, when I specify required=true on form inputs for task forms generated with the eclipse plugin, the validation does indeed occur when pressing the save button on the task form in the jbpm-console webapp, and the data is saved correctly in the database. However, it seems that when I end a task with the end transition, the process is completely separate from any save functionality. It would seem that data the user should still be prompted to enter data into required fields, and that this data should be saved. Perhaps there is a workaround I am unaware of, or I can attach javascript to trap for this? Any help is appreciated, thanks. -- 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

18 years, 10 months

3
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1177) Problem when adding dynamic rules to networks with shared AlphaNodes

by Edson Tirelli (JIRA)

Problem when adding dynamic rules to networks with shared AlphaNodes -------------------------------------------------------------------- Key: JBRULES-1177 URL: http://jira.jboss.com/jira/browse/JBRULES-1177 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Edson Tirelli Assigned To: Mark Proctor The problem is easy to see in the StateExampleWithDynamicRules. After the addition of the dynamic rule, it is activated 4 times instead of a single time as it is supposed to be. The problem is in the AlphaNode.updateSink() method, that simply calls (when node memory is off): // get the objects from the parent this.objectSource.updateSink( sink, context, workingMemory ); Passing "sink" as a parameter, what causes the propagation to skip the alpha constraints. I was able to isolate that in an unit test. Fixing now. -- 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

18 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBWEB-85) Cannot parse web.xml for jsp vehicle

by Heiko Braun (JIRA)

Cannot parse web.xml for jsp vehicle ------------------------------------- Key: JBWEB-85 URL: http://jira.jboss.com/jira/browse/JBWEB-85 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Heiko Braun Assigned To: Mladen Turk The following descriptor let's the jboss web digester choke, even though it's a perfectly legal j2ee1.4 web.xml: <?xml version="1.0" encoding="UTF-8"?> <web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:ns1="http://extra-header.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> <display-name>W2JRLR2753TestService_jsp_vehicle</display-name> <servlet> <servlet-name>jsp_vehicle</servlet-name> <jsp-file>/jsp_vehicle.jsp</jsp-file> <load-on-startup>0</load-on-startup> </servlet> <session-config> <session-timeout>54</session-timeout> </session-config> <service-ref> <service-ref-name>service/SimpleTest</service-ref-name> <service-interface>javax.xml.rpc.Service</service-interface> <wsdl-file>WEB-INF/wsdl/SimpleTest.wsdl</wsdl-file> <jaxrpc-mapping-file>SimpleTest.xml</jaxrpc-mapping-file> <port-component-ref> <service-endpoint-interface>com.sun.ts.tests.jaxrpc.wsi.w2j.rpc.literal.R2753.SimpleEndpoint</service-endpoint-interface> </port-component-ref> <handler> <handler-name>Handler1</handler-name> <handler-class>com.sun.ts.tests.jaxrpc.wsi.w2j.rpc.literal.R2753.R2753Handler</handler-class> <soap-header xmlns:soap-header_ns__="http://extra-header.org">soap-header_ns__:extra-header</soap-header> <soap-role>extra-header-actor</soap-role> </handler> </service-ref> </web-app> The Bug occured in the JBossWS test case for CTS 1.4. However i was able to nail it down a the jboss web Digester implementation. -- 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

18 years, 10 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-4096) Cleanup the JBoss JTS implementation

by Dimitris Andreadis (JIRA)

Cleanup the JBoss JTS implementation ------------------------------------ Key: JBAS-4096 URL: http://jira.jboss.com/jira/browse/JBAS-4096 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: IIOP service Reporter: Dimitris Andreadis Assigned To: Francisco Reverbel Fix For: JBossAS-4.2.1.CR1 Under the J2EE spec, JTS support is optional. It is preferable not to support it by default, rather than maintaining a JTS implementation inside the app server code base in addition to JBossTS JTS as we go forward. App server users requiring transactions over RMI/IIOP will need to download and drop in the JBoss JTS. Some cleanup of the app server code will be beneficial to ensure elegant failure rather than the current exceptions. We may be able to achieve this though the jboss iiop-service.xml settings? See also JBAS-4024 -- 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

18 years, 10 months

1
2
0 / 0

[JBoss JIRA] Updated: (JBAS-2777) Remove StandardMBeanInfoInterceptor

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2777?page=all ] Dimitris Andreadis updated JBAS-2777: ------------------------------------- Fix Version/s: Backlog > Remove StandardMBeanInfoInterceptor > ----------------------------------- > > Key: JBAS-2777 > URL: http://jira.jboss.com/jira/browse/JBAS-2777 > Project: JBoss Application Server > Issue Type: Patch > Security Level: Public(Everyone can see) > Components: JMX > Affects Versions: JBossAS-4.0.3 SP1 > Environment: JMX > Reporter: Fabiano C. de Oliveira > Priority: Minor > Fix For: Backlog > > Attachments: jmx_interceptor.patch, test_interceptor.patch > > > This is a clean to remove StandardMBeanInfoInterceptor. > Please see the forum topic for more information. > And http://www.jboss.com/index.html?module=bb&op=viewtopic&t=75448 -- 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

18 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2301) Startup fails if plus sign in JBoss home path

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2301?page=all ] Dimitris Andreadis updated JBAS-2301: ------------------------------------- Comment: was deleted > Startup fails if plus sign in JBoss home path > --------------------------------------------- > > Key: JBAS-2301 > URL: http://jira.jboss.com/jira/browse/JBAS-2301 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: System service > Affects Versions: JBossAS-4.0.3RC2 > Environment: Linux > Reporter: Ortwin Glück > Priority: Minor > > If the JBoss home directory contains a plus sign (+) startup fails with a ClassNotFoundException. In my setup the real path contained the plus sign but I used a symlink without a plus and it still crashed. I guess this is due to missing/wrong URL encoding when you configure the URLClassLoader in the startup classes. -- 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

18 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2301) Startup fails if plus sign in JBoss home path

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2301?page=all ] Dimitris Andreadis updated JBAS-2301: ------------------------------------- Comment: was deleted > Startup fails if plus sign in JBoss home path > --------------------------------------------- > > Key: JBAS-2301 > URL: http://jira.jboss.com/jira/browse/JBAS-2301 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: System service > Affects Versions: JBossAS-4.0.3RC2 > Environment: Linux > Reporter: Ortwin Glück > Priority: Minor > > If the JBoss home directory contains a plus sign (+) startup fails with a ClassNotFoundException. In my setup the real path contained the plus sign but I used a symlink without a plus and it still crashed. I guess this is due to missing/wrong URL encoding when you configure the URLClassLoader in the startup classes. -- 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

18 years, 10 months

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 September 2007