March 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBAS-3215) Add 'grace period' to deployment scanner between finding a new/changed deployment and actually deploying it

by David Richmond (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3215?page=comments#action_12354686 ] David Richmond commented on JBAS-3215: -------------------------------------- Will something be done about this? It keeps occuring at the most inconvenient times, mostly when my boss is breathing down my neck. > Add 'grace period' to deployment scanner between finding a new/changed deployment and actually deploying it > ----------------------------------------------------------------------------------------------------------- > > Key: JBAS-3215 > URL: http://jira.jboss.com/jira/browse/JBAS-3215 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: System service > Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.4.CR2 > Environment: jboss-4.0.3SP1 and jboss-4.0.4CR2 on Windows 2000 server using JVM 1.5.04 > WAR file is built on JDK 1.5.04 using the ANT 1.6.5 WAR task > Reporter: David Richmond > Assigned To: Dimitris Andreadis > > To avoid unpredictable "org.jboss.deployment.DeploymentException: Unexpected end of ZLIB input stream" exceptions could a grace period (delay) be added to the JBoss deployment deployer. This delay should be applied as follows: > 1. Scanner finds new deployments > 2. WAIT for grace period > 3. Scanner deploys new deployments > Setting the grace-period to 0 would emulate the current JBoss behaviour -- 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: (JBPM-619) outofmemory during ant test suite run

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-619?page=all ] Tom Baeyens updated JBPM-619: ----------------------------- Summary: outofmemory during ant test suite run (was: MailTests failure) > outofmemory during ant test suite run > ------------------------------------- > > Key: JBPM-619 > URL: http://jira.jboss.com/jira/browse/JBPM-619 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM jPDL 3.2 > Reporter: Jim Rigsbee > Assigned To: Tom Baeyens > Fix For: jBPM jPDL 3.2 > > > MailTests will fail if your local workstation is not setup correctly. These tests are failing in the cruise control build as well. -- 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] Closed: (JBPM-469) Dates are shifted in different time zones

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-469?page=all ] Tom Baeyens closed JBPM-469. ---------------------------- Resolution: Rejected not a jbpm problem > Dates are shifted in different time zones > ----------------------------------------- > > Key: JBPM-469 > URL: http://jira.jboss.com/jira/browse/JBPM-469 > Project: JBoss jBPM > Issue Type: Bug > Environment: Fedora Core 4 > Reporter: Juan Acosta > Assigned To: Tom Baeyens > > An example of the problem is as follows with timezone GMT-5: > When a new task is created, the creation date of the task is five hours ahead of the server time. When the task is modified (example: it is marked as ended), the start date shifts another five hours (in total ten hours) and the end date is five hours off. -- 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] Commented: (JBPM-165) process instance versioning

by Bernd Ruecker (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-165?page=comments#action_12354677 ] Bernd Ruecker commented on JBPM-165: ------------------------------------ What I have already as a command (not yet committed, because the test is not ready) is to change the version of a process instance. But I just changed the associations from the runtime objects to the new version defintion objects (this code we had already in out toolkit for jbpm). But this is not yet the solution Tom wanted to have. But I can commit it today as a "preview", so everybody can have a look at it. > process instance versioning > --------------------------- > > Key: JBPM-165 > URL: http://jira.jboss.com/jira/browse/JBPM-165 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > Fix For: jBPM jPDL 3.2 > > > i think jbpm could offer some degree of assistence in process instance versioning. > when a new version of a process is deployed, jbpm could do the following conversion for a process instance : > * input required: mapping of the nodes from the old to the new definition. > * cancel the old process instance > * create a new process instance and copy the runtime (exe) information such as tokens and process variables from the old process instance. > * then establish a special link between the 2 process instances to indicate that the new process instance is the continuation of the old process instance. > this way we can avoid the problematic conversion of logs, while still keeping them in the system. -- 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] Created: (JBRULES-663) rule modeller: have "=" in action to indicate a forumula

by Michael Neale (JIRA)

rule modeller: have "=" in action to indicate a forumula -------------------------------------------------------- Key: JBRULES-663 URL: http://jira.jboss.com/jira/browse/JBRULES-663 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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: (JBMESSAGING-904) org.jboss.test.messaging.jms.clustering.MultipleFailoverTest.testFailoverFloodTwoServers() fails on Linux

by Ovidiu Feodorov (JIRA)

org.jboss.test.messaging.jms.clustering.MultipleFailoverTest.testFailoverFloodTwoServers() fails on Linux --------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-904 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-904 Project: JBoss Messaging Issue Type: Bug Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Blocker Fix For: 1.2.0.GA junit.framework.AssertionFailedError at org.jboss.test.messaging.jms.clustering.MultipleFailoverTest.testFailoverFloodTwoServers(MultipleFailoverTest.java:252) -- 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
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-903) org.jboss.test.messaging.jms.clustering.MergeQueueTest.testMergeQueue2() fails on Linux

by Ovidiu Feodorov (JIRA)

org.jboss.test.messaging.jms.clustering.MergeQueueTest.testMergeQueue2() fails on Linux --------------------------------------------------------------------------------------- Key: JBMESSAGING-903 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-903 Project: JBoss Messaging Issue Type: Bug Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Blocker Fix For: 1.2.0.GA expected:<......> but was:<...1...> junit.framework.ComparisonFailure: expected:<......> but was:<...1...> at org.jboss.test.messaging.jms.clustering.MergeQueueTest.testMergeQueue2(MergeQueueTest.java:214) -- 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: (JBMESSAGING-899) QueueTest::testClosedConsumerBeforeStart fails because a possible anti-pattern

by Clebert Suconic (JIRA)

QueueTest::testClosedConsumerBeforeStart fails because a possible anti-pattern ------------------------------------------------------------------------------ Key: JBMESSAGING-899 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-899 Project: JBoss Messaging Issue Type: Bug Reporter: Clebert Suconic Assigned To: Clebert Suconic Priority: Blocker Fix For: 1.2.0.GA If this anti-pattern is being used: MessageConsumer c2 = s2.createConsumer(queue); conn2.start(); c2.close(); c2 = s2.createConsumer(queue); We might loose messages until we restart the server. -- 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
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 March 2007