August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBSEAM-328) Add no-conversation-action to Pageflow Definitition

by John Conner (JIRA)

Add no-conversation-action to Pageflow Definitition --------------------------------------------------- Key: JBSEAM-328 URL: http://jira.jboss.com/jira/browse/JBSEAM-328 Project: JBoss Seam Issue Type: Feature Request Components: BPM Reporter: John Conner In a pageflow definition, would like the ability to specify an action when a conversation is not found. See the forum thread for a fullier description. Quick example, User is executing a shopping cart checkout flow. For whatever reason the conversation times out (or server is restarted). The user than clicks a command button. The conversation is not found by Seam. Right now we only have the no-conversation-view-id to redirect to an error handling page/action. I would like to be able to specify the action in the pageflow definition rather than in the pages.xml (one less thing/plage to configure what should happen). -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (EJBTHREE-560) CLONE -Referencing JAR file in persistence.xml - Still a bug and referenced duplicate issue does not exist

by Gregory Nolle (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-560?page=all ] Gregory Nolle updated EJBTHREE-560: ----------------------------------- Attachment: PersistenceUnitDeployment.diff I came up against this problem as well. It's also mentioned in the forum here with some other symptoms: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=87057. I've attached a patch that fixes the problem. It seems that the original code tries to perform relative path resolution manually which seems rather pointless considering that this functionality is built into java.net.URL itself. > CLONE -Referencing JAR file in persistence.xml - Still a bug and referenced duplicate issue does not exist > ---------------------------------------------------------------------------------------------------------- > > Key: EJBTHREE-560 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-560 > Project: EJB 3.0 > Issue Type: Bug > Affects Versions: EJB 3.0 RC1 > Reporter: geoffm74 > Attachments: PersistenceUnitDeployment.diff > > > I've installed EJB3.0RC1 and the release notes states that now all persistence.xml features are implemented. So I went on trying to use the jar file referencing. > Unfortunately I found that during deployment the only place being searched for this jar file was in JBOSS_HOME/bin. I tried with absolute paths and relative - but it kept hangin on to the bin folder - probably the working folder for jboss launcher. > My jar is bundled with my ear - where should it really be to get the jar reference workin? I think the bin folder is not a proper place.... > Peter -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JGRP-227) Distributed Hashtable call to put() blocks indefinitely

by Mark Kopec (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-227?page=comments#action_12340953 ] Mark Kopec commented on JGRP-227: --------------------------------- In order to be very clear: - What is currently attached to this issue as of August 9th 2006 has a junit test JGroupsDistTest.java if you run this test only one time. It will fail, each subsequent time you run it also. - Included in the Junit test is the workaround, which is located on line 264, using this method you can acheive the same desired functionality that caused a cluster wide lockup. Bela, if you get the chance, please update your website that points to the distributed hashtable api, and make it "undepricated" so that people accessing wikipedias "distributed hashtable" section can use your product more. http://en.wikipedia.org/wiki/Distributed_hash_tables references: http://www.jgroups.org/javagroupsnew/docs/javadoc/org/jgroups/blocks/Dist... I had to fight with some dudes to keep it there, he kept insisting that jgroups is more of a framework, but so is Bamboo (the first entry there). May I say the model is suprisingly similar to Jgroups, imitation is probably the sincerest form of flattery. To make a long story short; it's now a well established member of the wikipedia dht entry community :) > Distributed Hashtable call to put() blocks indefinitely > ------------------------------------------------------- > > Key: JGRP-227 > URL: http://jira.jboss.com/jira/browse/JGRP-227 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.2.9.1 > Environment: Mandrake Linux 9.1, Java 1.4.2 > Reporter: Mark Kopec > Assigned To: Bela Ban > Fix For: 2.4 > > Attachments: JGroupsDistTest.java > > > Distributed hashtable put(x,y) without any ERROR level locks up and creates inconsistent DHT values across cluster. > Here is the code that exposes this error: > MyListener implements DistributedHashtable.notification{ > // other methods > public void entryRemoved(Object key) { > distributedHashTableObject.put(key,"xxxsomeval"); //<-- this and subsequent on the distributedHashTableObject put() or remove() get stuck!!!! > } -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1489) MessageListener does not invoke ExceptionListener on error

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1489?page=all ] Adrian Brock updated JBAS-1489: ------------------------------- Comment: was deleted > MessageListener does not invoke ExceptionListener on error > ---------------------------------------------------------- > > Key: JBAS-1489 > URL: http://jira.jboss.com/jira/browse/JBAS-1489 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 SP1, JBossAS-3.2.7 Final, JBossAS-4.0.1 Final > Reporter: Adrian Brock > Assigned To: Adrian Brock > Fix For: JBossAS-4.0.2RC1 > > > If SpyMessageConsumer detects an error on the MessageListener thread > it should invoke the ExceptionListener. > Also, to avoid potential deadlocks with exceptions detected on the MessageListener > thread, a new thread should be started to invoke the ExceptionListener. > Otherwise the ExceptionListener will not be able to close the consumer. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JGRP-227) Distributed Hashtable call to put() blocks indefinitely

by Mark Kopec (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-227?page=all ] Mark Kopec updated JGRP-227: ---------------------------- Attachment: JGroupsDistTest.java My apologies. I believe the copy that I gave you may have had the workaround implemented into it already. Uncommenting line 264 and commenting out line 265 resolves the issue. > Distributed Hashtable call to put() blocks indefinitely > ------------------------------------------------------- > > Key: JGRP-227 > URL: http://jira.jboss.com/jira/browse/JGRP-227 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.2.9.1 > Environment: Mandrake Linux 9.1, Java 1.4.2 > Reporter: Mark Kopec > Assigned To: Bela Ban > Fix For: 2.4 > > Attachments: JGroupsDistTest.java > > > Distributed hashtable put(x,y) without any ERROR level locks up and creates inconsistent DHT values across cluster. > Here is the code that exposes this error: > MyListener implements DistributedHashtable.notification{ > // other methods > public void entryRemoved(Object key) { > distributedHashTableObject.put(key,"xxxsomeval"); //<-- this and subsequent on the distributedHashTableObject put() or remove() get stuck!!!! > } -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-392) BigDecimal and BigInteger support for literals in evaluators

by Michael Neale (JIRA)

BigDecimal and BigInteger support for literals in evaluators ------------------------------------------------------------ Key: JBRULES-392 URL: http://jira.jboss.com/jira/browse/JBRULES-392 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rule Assemply/SPI Affects Versions: 3.0.3 Reporter: Michael Neale Assigned To: Mark Proctor Fix For: 3.1-m2 Need to have BigDecimal support in the evaluators: Foo(bigDecField > 2) so the literal is converted into a BigDec etc.. (also BigInteger). Should not be too hard. -- 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, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBPM-726) Invalid DbPersistenceServiceFactory XML config example in Section 7.2.2 of documentation

by Chris OBrien (JIRA)

Invalid DbPersistenceServiceFactory XML config example in Section 7.2.2 of documentation ---------------------------------------------------------------------------------------- Key: JBPM-726 URL: http://jira.jboss.com/jira/browse/JBPM-726 Project: JBoss jBPM Issue Type: Bug Components: Documentation Affects Versions: jBPM 3.1.2 Reporter: Chris OBrien Assigned To: Tom Baeyens After fighting with the configuration to disable jBPM's management of transactions, and digging through the code, I finally figured out the issue. An incorrect user guide. In section 7.2.2. The DbPersistenceServiceFactory, it shows an XML snipped how to setup jBPM's persistence layer so it will not fuss with transactions. The example given is wrong. Where it says bean factory="org.jbpm.persistence.db.DbPersistenceServiceFactory" It should say bean class="org.jbpm.persistence.db.DbPersistenceServiceFactory" -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3486) Unable to find deployment resources - org.jboss.test.securitymgr.test.WarPermissionsUnitTestCase

by Rajesh Rajasekaran (JIRA)

Unable to find deployment resources - org.jboss.test.securitymgr.test.WarPermissionsUnitTestCase ------------------------------------------------------------------------------------------------ Key: JBAS-3486 URL: http://jira.jboss.com/jira/browse/JBAS-3486 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Affects Versions: JBossAS-4.0.5.CR1 Reporter: Rajesh Rajasekaran Fix For: JBossAS-4.0.5.CR1 no protocol: /services/cruisecontrol/checkout/jboss-4.0-testsuite-sun-1.4/testsuite/output/lib/securitymgr/unpacked.war java.net.MalformedURLException: no protocol: /services/cruisecontrol/checkout/jboss-4.0-testsuite-sun-1.4/testsuite/output/lib/securitymgr/unpacked.war The testcase could not find the following resources it is trying to deploy: "securitymgr/unpacked.war" "securitymgr/packed.war" -- 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, 11 months

2
3
0 / 0

[JBoss JIRA] Commented: (JGRP-188) JGroups should not use System properties, because it's too restrictive

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-188?page=comments#action_12340936 ] Bela Ban commented on JGRP-188: ------------------------------- I don't think this will fly, as other systems such as JBoss use System.setProperty() *after* the VM has been started, and we have no way of intercepting this ! And we cannot force users to use GlobalConfigurator.setProperty(). I'm therefore rejecting this issue, if you have a solution to the above problem, please feel free to re-open the case. > JGroups should not use System properties, because it's too restrictive > ---------------------------------------------------------------------- > > Key: JGRP-188 > URL: http://jira.jboss.com/jira/browse/JGRP-188 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9.1, 2.2.9, 2.2.8 > Environment: all > Reporter: Robert Stevenson > Assigned To: Bela Ban > Priority: Minor > Fix For: 2.4 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > JGroups should not use System properties for configuration, it should instead use a Global Configurator class (singleton), similar to log4j; which just contains a Properties object. This would allow JGroups to be much easier to move around to different environments. For example : (Applet), which does not have access to easily change System properties, on a per applet basis. > This new class could have a mapping/conversion method to make the current -D command line options be put into this new Properties Configurator for backward compatibility -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JGRP-188) JGroups should not use System properties, because it's too restrictive

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-188?page=all ] Bela Ban resolved JGRP-188. --------------------------- Resolution: Done > JGroups should not use System properties, because it's too restrictive > ---------------------------------------------------------------------- > > Key: JGRP-188 > URL: http://jira.jboss.com/jira/browse/JGRP-188 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9.1, 2.2.9, 2.2.8 > Environment: all > Reporter: Robert Stevenson > Assigned To: Bela Ban > Priority: Minor > Fix For: 2.4 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > JGroups should not use System properties for configuration, it should instead use a Global Configurator class (singleton), similar to log4j; which just contains a Properties object. This would allow JGroups to be much easier to move around to different environments. For example : (Applet), which does not have access to easily change System properties, on a per applet basis. > This new class could have a mapping/conversion method to make the current -D command line options be put into this new Properties Configurator for backward compatibility -- 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, 11 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 August 2006