May 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPM-951) change logging policy

by Tom Baeyens (JIRA)

change logging policy --------------------- Key: JBPM-951 URL: http://jira.jboss.com/jira/browse/JBPM-951 Project: JBoss jBPM Issue Type: Feature Request Reporter: Tom Baeyens Assigned To: Tom Baeyens Fix For: jBPM jPDL 3.2.1 in the suite, make sure that the jboss defaults are kept instead of the custom logging file that we have now. then in the docs, there should be a big-attention-screaming-section that explains how to easily turn on debug logs for jbpm. -- 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

19 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-735) BisocketClientInvoker.PingTimerTask should try multiple times to send ping.

by Ron Sigal (JIRA)

BisocketClientInvoker.PingTimerTask should try multiple times to send ping. --------------------------------------------------------------------------- Key: JBREM-735 URL: http://jira.jboss.com/jira/browse/JBREM-735 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Currently, the PingTimerTask will shut down if the first attempt to send ping fails. It should retry multiple times. -- 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

19 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-645) Need to cleanup locatorURI parsing

by Scott M Stark (JIRA)

Need to cleanup locatorURI parsing ---------------------------------- Key: JBREM-645 URL: http://jira.jboss.com/jira/browse/JBREM-645 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: general Affects Versions: 2.2.0.Alpha3 (Bluto) Reporter: Scott M Stark Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) Remoting is using its own parsing logic to extract the host and port when it should be using a URI object, and have a ctor supporting a URI type. This URI which parses fine via the URI class: URI x = new URI("socket://succubus.starkinternational.com:4446?datatype=invocation"); int port = x.getPort(); fails to parse when passed to the InvokerLocator 370232 ERROR [DeploymentWorker] Operation Distribute failed on target org.jboss.deployment.remoting.StreamingTarget@11e9c82e java.lang.NumberFormatException: For input string: "4446?datatype=invocation" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:456) at java.lang.Integer.parseInt(Integer.java:497) at org.jboss.remoting.InvokerLocator.<init>(InvokerLocator.java:191) at org.jboss.deployment.remoting.StreamingTarget.getClient(StreamingTarget.java:254) at org.jboss.deployment.remoting.StreamingTarget.deploy(StreamingTarget.java:140) at org.jboss.deployment.spi.DeploymentWorker.run(DeploymentWorker.java:74) -- 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

19 years, 1 month

3
6
0 / 0

[JBoss JIRA] Created: (BPEL-256) First activity of a flow has to have a defined target even if the containing flow element has a target

by Santiago Erquicia (JIRA)

First activity of a flow has to have a defined target even if the containing flow element has a target ------------------------------------------------------------------------------------------------------ Key: BPEL-256 URL: http://jira.jboss.com/jira/browse/BPEL-256 Project: JBoss jBPM BPEL Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM BPEL 1.1 beta 3 Reporter: Santiago Erquicia Assigned To: Alejandro Guizar The first activity of a flow is forced to have targets even if the flow definition has targets already defined. This does not happen with the last activity of a flow, which doesn't have a source defined because the flow definition has a source defined. For example: <bpel:flow name="Flow1"> <bpel:targets> <bpel:target linkName="Link20"/> </bpel:targets> <bpel:sources> <bpel:source linkName="Link25"/> </bpel:sources> <bpel:links> <bpel:link name="Link21"/> <bpel:link name="Link27"/> <bpel:link name="Link28"/> </bpel:links> <bpel:assign name="InitializeCounter">  <bpel:targets> <bpel:target linkName="Link20"/> </bpel:targets>  <bpel:sources> <bpel:source linkName="Link21"/> </bpel:sources> <bpel:copy> <bpel:from>0</bpel:from> <bpel:to part="count" variable="Count"/> </bpel:copy> </bpel:assign> ........... This extract of a bpel definition shouldn't require the target definition of InitializeCounter. -- 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

19 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1065) TreeCacheView should just inject Cache

by Brian Stansberry (JIRA)

TreeCacheView should just inject Cache -------------------------------------- Key: JBCACHE-1065 URL: http://jira.jboss.com/jira/browse/JBCACHE-1065 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 2.0.0.CR3 TreeCacheView has the funky "inject ObjectName, figure out MBeanServer, lookup cache via JMX" way of doing things. Replace with simple dependency injection. -- 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

19 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-3848) jms message disappeared from db then exception is occured

by Ramil Israfilov (JIRA)

jms message disappeared from db then exception is occured --------------------------------------------------------- Key: JBAS-3848 URL: http://jira.jboss.com/jira/browse/JBAS-3848 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-4.0.5.GA Environment: JBOSS 4.0.5.GA, JDK1.5.0_06, solarisx86, clustered on two nodes Reporter: Ramil Israfilov Assigned To: Adrian Brock We running clustered jboss4.0.5 and JBOSS MQ is configured to run in clustered environment. The node which was running Jboss MQ went down. JBOSS MQ successfully restarted on second node.But deliver of JMS message failed with error: 2006-11-13 11:47:59,130 ERROR [org.jboss.resource.adapter.jms.inflow.JmsServerSession] (cludev02) (WorkManager(3)-28:) Unexpected error delivering message SpyTextMessage { Header { jmsDestination : QUEUE.certione/ExecutorQueue jmsDeliveryMode : 2 jmsExpiration : 0 jmsPriority : 4 jmsMessageID : ID:13-116341486898510 jmsTimeStamp : 1163414868985 jmsCorrelationID: null jmsReplyTo : null jmsType : CertioneAsyncProcessingMessage jmsRedelivered : false jmsProperties : {TrackItemId=738, ExecutorName=certione/PreProcessingProcessRemote, TokenId=19666, AuditRecord=137} jmsPropReadWrite: false msgReadOnly : true producerClientId: ID:13 } Body { text :null } } javax.ejb.EJBException: Failed to acquire the pool semaphore, strictTimeout=10000 at org.jboss.ejb3.StrictMaxPool.get(StrictMaxPool.java:106) at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:54) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:245) at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:268) at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:138) at $Proxy272.onMessage(Unknown Source) at org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:183) at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:905) at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:170) at org.jboss.mq.SpySession.run(SpySession.java:323) at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:249) at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204) at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743) at java.lang.Thread.run(Thread.java:595) And the most important is that JMS message disappeared after that from database ! -- 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

19 years, 1 month

8
25
0 / 0

[JBoss JIRA] Created: (JBAS-3738) On Windows: timer.test.BasicTimerUnitTestCase fails

by Prabhat Jha (JIRA)

On Windows: timer.test.BasicTimerUnitTestCase fails --------------------------------------------------- Key: JBAS-3738 URL: http://jira.jboss.com/jira/browse/JBAS-3738 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Environment: Windows 2003, Sun JDK1.4 Reporter: Prabhat Jha Assigned To: Dimitris Andreadis Fix For: JBossAS-4.0.5.GA Test Class: org.jboss.test.timer.test.BasicTimerUnitTestCase Test Name: testMDBTimer Message property 'UNIQUE_ID' not set. java.lang.NumberFormatException: Message property 'UNIQUE_ID' not set. at org.jboss.mq.SpyMessage.getIntProperty(SpyMessage.java:581) at org.jboss.test.timer.test.BasicTimerUnitTestCase.testMDBTimer(BasicTimerUnitTestCase.java:332) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) -- 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

19 years, 1 month

3
4
0 / 0

[JBoss JIRA] Created: (JBBUILD-370) Add property verification to the enforcer plugin

by Paul Gier (JIRA)

Add property verification to the enforcer plugin ------------------------------------------------ Key: JBBUILD-370 URL: http://jira.jboss.com/jira/browse/JBBUILD-370 Project: JBoss Build System Issue Type: Feature Request Components: Maven Reporter: Paul Gier Assigned To: Paul Gier Fix For: MavenBuild 2.0 It would be good to have the ability for maven to check if a given property is set, and then fail with an error message if the property is not set. This feature could be added to the maven enforcer plugin. http://maven.apache.org/plugins/maven-enforcer-plugin/ Checked with maven devs, and they would like to have this feature. -- 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

19 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-459) disable_initial_coord not working

by Graeme Ahokas (JIRA)

disable_initial_coord not working ---------------------------------- Key: JGRP-459 URL: http://jira.jboss.com/jira/browse/JGRP-459 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 SP1 Environment: mac os x, Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164) Reporter: Graeme Ahokas Assigned To: Bela Ban We've got the following scenario: three applications, App1, App2, and App3. We want App3 to be the coordinator when the apps first start, so there is no confusion about multiple groups / coordinators. So, we set App1 and App2's disable_initial_coord = true, and App3's disable_initial_coord=false. Then we start App1, and it will wait. Then we start App2, and App1 / App2 will determine a coordinator, even though disable_initial_coord is set to true for both, and we have not started App3 yet! This seems to conflict with the documentation which states: Note that - if a member is started as first member of a group - but its property is set to true, then it will loop until another member whose disable_initial_coord property is set to false, is started. We need disable_initial_coord to work as documented. -- 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

19 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-506) loopback should use thread pool to deliver message up the stack

by Michael Newcomb (JIRA)

loopback should use thread pool to deliver message up the stack --------------------------------------------------------------- Key: JGRP-506 URL: http://jira.jboss.com/jira/browse/JGRP-506 Project: JGroups Issue Type: Bug Reporter: Michael Newcomb Assigned To: Bela Ban If loopback is true, the thread calling down() also delivers the message up(). -- 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

19 years, 1 month

2
6
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 May 2007