March 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMETA-266) Move VFSAdaptorUnitTestCase from ejb to common

by Brian Stansberry (JIRA)

Move VFSAdaptorUnitTestCase from ejb to common ---------------------------------------------- Key: JBMETA-266 URL: https://jira.jboss.org/jira/browse/JBMETA-266 Project: JBoss Metadata Issue Type: Task Security Level: Public (Everyone can see) Components: common, ejb Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: jboss-metadata-common-2.0.0-alpha-15, jboss-metadata-ejb-2.0.0-alpha-7 This test tests a class in common; has nothing to do w/ ejb except it happened to use a random persistence.xml from the old unified metadata projects as a test fixture. Having it in metadata-ejb has led to test failures not being picked up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1080) Add support for future tasks to RequestContext

by David Lloyd (JIRA)

Add support for future tasks to RequestContext ---------------------------------------------- Key: JBREM-1080 URL: https://jira.jboss.org/jira/browse/JBREM-1080 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: r3 api Reporter: David Lloyd Fix For: 3.1.0.Beta1 Right now, the RequestContext keeps track of tasks and threads being used to process a request. If all tasks complete and no reply is sent, it makes sure that the requesting party receives an exception indicating that a reply was never sent. However, if the request listener may wish interact with another framework which uses some asynchronous callback mechanism, from which a reply is to be sent. In this case, all tasks terminate but the reply might still be sent. To solve this problem, RequestContext needs a method which can wrap a Runnable (or similar) with some type of cancellable Runnable or task object, which can then be called by other frameworks as needed later on. The RequestContext wouldn't consider a request "dead" until all tasks completed and all such wrapped Runnables have also been completed or GC'd. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-1203) Streams via "remote"

by David Lloyd (JIRA)

Streams via "remote" -------------------- Key: JBREM-1203 URL: https://jira.jboss.org/jira/browse/JBREM-1203 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: r3 core: remote Reporter: David Lloyd Assignee: David Lloyd Fix For: 3.1.0.Beta2 The six stream types over "remote"/"remote+ssl". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1205) Provide a way for the client to specify an unmarshalling classloader for a request

by David Lloyd (JIRA)

Provide a way for the client to specify an unmarshalling classloader for a request ---------------------------------------------------------------------------------- Key: JBREM-1205 URL: https://jira.jboss.org/jira/browse/JBREM-1205 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: r3 core, r3 core: api, r3 core: remote Reporter: David Lloyd Assignee: David Lloyd Priority: Minor Fix For: 3.1.0.Beta2 It should be an optional parameter which defaults to the TCCL, and failing that, perhaps the caller's classloader. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1206) Address asymmetry between local & remote request & reply handlers

by David Lloyd (JIRA)

Address asymmetry between local & remote request & reply handlers ----------------------------------------------------------------- Key: JBREM-1206 URL: https://jira.jboss.org/jira/browse/JBREM-1206 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: r3 core, r3 core: api, r3 core: remote Reporter: David Lloyd Assignee: David Lloyd Fix For: 3.1.0.Beta2 The asymmetry between using a RequestHandler for local vs. remote request handlers has reached a breaking point with call by value and service classloader association. Introduce Local/Remote variants of RequestHandlers and ReplyHandlers which have a class loader as a property. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1207) Pass-by-value on "local:" protocol

by David Lloyd (JIRA)

Pass-by-value on "local:" protocol ---------------------------------- Key: JBREM-1207 URL: https://jira.jboss.org/jira/browse/JBREM-1207 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: r3 core, r3 core: api Reporter: David Lloyd Assignee: David Lloyd Fix For: 3.1.0.Beta2 Use the new JBMAR cloner interface. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-646) ConnectionTable problem after a while in 2 node cluster

by Martin Vecera (JIRA)

ConnectionTable problem after a while in 2 node cluster ------------------------------------------------------- Key: JGRP-646 URL: http://jira.jboss.com/jira/browse/JGRP-646 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 SP4 Environment: Two physical machines both running RHEL5, Sun JVM 1.5.0_12, full SOA-P 4.2.0.IR8 based on EAP 4.3.0.GA (build: SVNTag=JBPAPP_4_3_0_GA date=200711291835), Orcale DB on a separate machine Reporter: Martin Vecera Assigned To: Bela Ban Reproducible: 100% 1. I took full IR8 and used dbinstall (https://svn.corp.jboss.com/repos/soa/trunk/qa/dbinstall/) for the 'all' configuration to use Oracle DB. 2. I unsecured jmx-service-invoker. 3. I copied the SOA-P to the second node. 4. I changed the server peer id on the both copies to be different. 5. I started the first node, it was successful. 6. I started the second node successfully as well. 7. I let it be for half an hour. 8. This appeared in the log files: Node 1: 2007-12-13 10:57:07,502 WARN [org.jgroups.blocks.ConnectionTable] peer closed connection, trying to re-send msg 2007-12-13 10:57:07,502 ERROR [org.jgroups.blocks.ConnectionTable] 2nd attempt to send data failed too Node 2: 2007-12-13 10:57:08,927 WARN [org.jgroups.blocks.ConnectionTable] peer closed connection, trying to re-send msg 2007-12-13 10:57:08,928 ERROR [org.jgroups.blocks.ConnectionTable] 2nd attempt to send data failed too It doesn't seem like there's anything related to the problems in the logs (no exceptions, no other JGroups related output...). -- 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

14 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (JBMETA-265) EE 6 module name concept in ear metadata

by Brian Stansberry (JIRA)

EE 6 module name concept in ear metadata ---------------------------------------- Key: JBMETA-265 URL: https://jira.jboss.org/jira/browse/JBMETA-265 Project: JBoss Metadata Issue Type: Sub-task Security Level: Public (Everyone can see) Components: ear Reporter: Brian Stansberry Assignee: Brian Stansberry Ear metadata portion of parent task. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMETA-264) EE 6 module-name concept in common metadata

by Brian Stansberry (JIRA)

EE 6 module-name concept in common metadata ------------------------------------------- Key: JBMETA-264 URL: https://jira.jboss.org/jira/browse/JBMETA-264 Project: JBoss Metadata Issue Type: Sub-task Security Level: Public (Everyone can see) Components: client Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: jboss-metadata-client 2.0.0-alpha-2 App client metadata portion of parent task. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-7195) On executing readonly query, WrappedConnection.checkTransactionStatus throws exception when transaction is marked for roll back

by jay xxx (JIRA)

On executing readonly query, WrappedConnection.checkTransactionStatus throws exception when transaction is marked for roll back ------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-7195 URL: https://jira.jboss.org/jira/browse/JBAS-7195 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.1.0.CR1, JBossAS-5.1.0.Beta1, JBossAS-5.0.1.GA, JBossAS-5.0.0.GA, JBossAS-5.0.0.CR2, JBossAS-4.2.3.GA Environment: linux/windows, jboss 4.2.3 onwards, jdk 1.5/1.6 Reporter: jay xxx Assignee: Jesper Pedersen Hi, When using jboss 4.2.3 with our app, we got an error of this sort (not exact): Cannot Execute query.....Transaction status marked rollback Caused by: jboss.util.NestedSQLException at ...WrappedConnection.checkTransactionStatus Scenario when the above error happens: a) User submits request from a web page b) A jta transaction is started in a filter c) From UI layer, transaction is propagated to service layer with "Propation Required" setting. d) Service layer throws an exception (validation) and transaction is [i]marked [/i]for rollback. Note that it is [i]marked [/i]for rollback and [i]not [/i]rolledback e) The ui layer now prepares the view which requires some db [i]queries[/i] to be executed. As soon as the first query is tried to be executed, the above exception is thrown. I tried the above same steps with jboss 4.2.1 and it works fine. On further probing, found that in jboss 4.2.3, there was a change made as part of: [url]https://jira.jboss.org/jira/browse/JBAS-5080[/url] [url]https://jira.jboss.org/jira/browse/JBAS-5083[/url] >From jira links above, intention seems to be to prevent update sqls from getting exectuted when transaction is marked for rollback. But looks like the code that was added does not discriminate between read-only and update sqls and prevents even a prepared statement from getting created - WrappedConnection.checkTransactionStatus throws an exception "cannot execute query" transaction marked for rollback. I believe that jca should discriminate between read only and update queries and should *allow* read only queries to go through when transaction is marked for rollback. These would allow the views to get generated in the same transaction. Ours is a 2-tier system (ui + service layer execute in the same jvm) and we are using Hibernate's recommended OpenSessionInViewPattern with one hib session+ one transaction per request. Anyone has any thoughts about this? Is it a legitimate concern? Else, the options before us are: a) refactor our code to have one hib session + 2 transactions (one for service layer and the other for the view). I believe even Jboss Seam does this. b) We have a roadmap to migrate to jboss 4.2.3 followed by jboss 5.1 within next 4 months. Then we'll have to ourselves change the Wrapped connection code to discriminate between read only and update queries. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

4
7
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2010