March 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBPM-527) merge jbpm.db back into jbpm

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-527?page=all ] Tom Baeyens closed JBPM-527. ---------------------------- Fix Version/s: (was: jBPM jPDL 3.2) Resolution: Rejected > merge jbpm.db back into jbpm > ---------------------------- > > Key: JBPM-527 > URL: http://jira.jboss.com/jira/browse/JBPM-527 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > > maintaining the db-driver-libs in the db is not really maintainable. i think it would be better if we create scripts that are able to > 1) fetch the driver from a download site and store them in a local repository > 2) generate scripts > 3) execute test suite > this seems better maintainable. and also the size would be drastically reduced because we don't distribute the drivers. hence, the jbpm.db project can be merged into jbpm.3 -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-901) change to JTA transaction configuration

by Tom Baeyens (JIRA)

change to JTA transaction configuration --------------------------------------- Key: JBPM-901 URL: http://jira.jboss.com/jira/browse/JBPM-901 Project: JBoss jBPM Issue Type: Task Components: Core Engine Reporter: Tom Baeyens Assigned To: Tom Baeyens Fix For: jBPM jPDL 3.2 change from CMT to JTA transaction configuration to enable both the EJBs and the webapp to leverage the same JbpmConfiguration. For this I created a new persistence service called JtaDbPersistenceService. It verifies that there is an active UserTransaction during the JbpmContext block. If not, one is created and ended in the jbpmContext.close. So now in the EJBs (CMT) there is already a transaction in progress and the JtaDbPersistenceService will not do anything. For the webapp, there will not be a user transaction and hence JtaDbPersistenceService will begin and end the user transaction. This approach was needed because hibernate doesn't support beginning and ending of user transaction. regards, tom. -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Commented: (JBAS-1098) Foreign key violation during cascade delete

by Alexey Loubyansky (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1098?page=comments#action_12356021 ] Alexey Loubyansky commented on JBAS-1098: ----------------------------------------- It is rejected because setting foreign keys to null before cascade-delete was the intended behavior in the original implementation. And now we don't invest in CMP2.x anymore. The batch-cascade-delete does work with multiple levels. > Foreign key violation during cascade delete > ------------------------------------------- > > Key: JBAS-1098 > URL: http://jira.jboss.com/jira/browse/JBAS-1098 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CMP service > Affects Versions: JBossAS-3.2.6 Final > Reporter: SourceForge User > Assigned To: Alexey Loubyansky > Fix For: No Release > > > SourceForge Submitter: sflexus . > JBoss 3.2.5, JDK 1.4.2_04, Linux. > I have CMP Entity Customer and CMP entity Album with > the following relationships: > 1) 1 Customer has Many Albums > 2) 1 Customer has 1 Album "Inbox" > 3) 1 Customer has 1 Album "Private" > 4) 1 Customer has 1 Album "Recycle Bin" > So basically there are 3 Albums each of which has double > relationship to Customer, both 1-1 and 1-M > Relationship (1) has cascade-delete on Album side, so if > customer is deleted, all his albums should be deleted. > Relationships (2)-(4) has NO cascade-delete setting, > since (1) should be enough, as it references ALL > customer's albums, including those referenced in (2)-(4). > There are other entities related to Customer in the > application, but they seem non-important (at first sight). > If I try to remove Customer instance, I get foreigh key > violation in the database. All foreign keys were created > by JBoss itself. I have attached TRACE-level log. What > happens is that all 3 albums (inbox, private and recycle > bin, their IDs are 162, 163 and 164) are scheduled for > cascade delete, but only the one with ID=164 is updated > to set its CMR column to NULL before issuing DELETE > FROM Customer SQL. The foreign key fk_album_owner > which is being violated corresponds to relation (1) "1 > Customer has Many Albums". > The interesting thing is that if I redeploy the application > and issue remove again, it completes normally! Looks like > it depends on some cache state. > Two files are attached. First one demonstrates foreign > key violation, second one demonstrates success deletion > after application is redeployed. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-168) Message tests derive from MessageTestBase

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-168?page=all ] Ovidiu Feodorov updated JBMESSAGING-168: ---------------------------------------- Fix Version/s: Unscheduled (was: 1.2.1) > Message tests derive from MessageTestBase > ----------------------------------------- > > Key: JBMESSAGING-168 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-168 > Project: JBoss Messaging > Issue Type: Bug > Components: Tests and Performance > Reporter: Tim Fox > Priority: Minor > Fix For: Unscheduled > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > The jms message tests, e.g. JMSExpirationHeaderTest inherit from MessageTest. > Therefore all the tests in MessageTest are being re-run for each of the subtypes. > The hierarchchy of tests is overly complex and confusing. > We have messagetest, messagetestbase, jmstest, messagingtestcase...... (!) > The structure should be flattened and simplified to aid comprehension. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-196) Port JBossMQ XIL2 support to Messaging

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-196?page=all ] Ovidiu Feodorov updated JBMESSAGING-196: ---------------------------------------- Fix Version/s: Unscheduled (was: 1.2.1) > Port JBossMQ XIL2 support to Messaging > -------------------------------------- > > Key: JBMESSAGING-196 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-196 > Project: JBoss Messaging > Issue Type: Task > Components: JMS Remoting > Reporter: John Fawcett > Priority: Optional > Fix For: Unscheduled > > -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-180) Improve message priority algorithm

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-180?page=all ] Ovidiu Feodorov updated JBMESSAGING-180: ---------------------------------------- Fix Version/s: Unscheduled (was: 1.2.1) > Improve message priority algorithm > ---------------------------------- > > Key: JBMESSAGING-180 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-180 > Project: JBoss Messaging > Issue Type: Task > Components: Messaging Core > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: Unscheduled > > Original Estimate: 3 days > Remaining Estimate: 3 days > > The current message priority strategy is very crude and always delivers higher priority messages first if they exist. > This can cause starvation of lower priority messages. > The algorithm should be improved to prevent starvation. > It may be an idea to make the algorithm pluggable using the strategy pattern. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-379) Split large messages into fragments

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-379?page=all ] Ovidiu Feodorov updated JBMESSAGING-379: ---------------------------------------- Fix Version/s: Unscheduled (was: 1.2.1) > Split large messages into fragments > ----------------------------------- > > Key: JBMESSAGING-379 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-379 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: Unscheduled > > Original Estimate: 3 days > Remaining Estimate: 3 days > > An alternative way of dealing with very large messages than using a streamed body, is to automatically split large messages into many small fragments and send each in it's own message. These can be automatically re-assembled at the receiver. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-383) Modify jboss-head build script to include Messaging instead of JBossMQ in the "default" configuration

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-383?page=all ] Ovidiu Feodorov updated JBMESSAGING-383: ---------------------------------------- Fix Version/s: Unscheduled (was: 1.2.1) > Modify jboss-head build script to include Messaging instead of JBossMQ in the "default" configuration > ----------------------------------------------------------------------------------------------------- > > Key: JBMESSAGING-383 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-383 > Project: JBoss Messaging > Issue Type: Sub-task > Components: AS Integration > Reporter: Ovidiu Feodorov > Assigned To: Ovidiu Feodorov > Priority: Critical > Fix For: Unscheduled > > > Make sure JBossMQ still works as an alternate JMS provider -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-324) Set JMSRedelivered on recovery

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-324?page=all ] Ovidiu Feodorov updated JBMESSAGING-324: ---------------------------------------- Fix Version/s: Unscheduled (was: 1.2.1) > Set JMSRedelivered on recovery > ------------------------------ > > Key: JBMESSAGING-324 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-324 > Project: JBoss Messaging > Issue Type: Bug > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: Unscheduled > > Original Estimate: 2 days > Remaining Estimate: 2 days > > After recovery or server restart messages aren't being delivered with JMSRedlivered=true -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-177) Server-side message persistence/caching should be done by an AOP interceptor

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-177?page=all ] Ovidiu Feodorov updated JBMESSAGING-177: ---------------------------------------- Fix Version/s: Unscheduled (was: 1.2.1) > Server-side message persistence/caching should be done by an AOP interceptor > ---------------------------------------------------------------------------- > > Key: JBMESSAGING-177 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-177 > Project: JBoss Messaging > Issue Type: Task > Components: AOP Support > Reporter: Ovidiu Feodorov > Assigned To: Ovidiu Feodorov > Fix For: Unscheduled > > -- 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, 2 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 March 2007