July 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3399) Transaction timeout fires too late

by tbech (JIRA)

Transaction timeout fires too late ---------------------------------- Key: JBAS-3399 URL: http://jira.jboss.com/jira/browse/JBAS-3399 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Manager Affects Versions: JBossAS-4.0.3 SP1 Reporter: tbech Assigned To: Adrian Brock Priority: Minor Transaction timeout is fired in the 'commit' probably. It is far too late in order to really limit the transaction. Scenario: - do long job in transaction (CMT); - job is finished; - commit; - timeout exception is thrown; Doesn't matter what timeout is set, server does whole job (few hours even) and at the end throws exception. Shouldn't container: a) throw an error after timeout b) stop the called EJB method ??? -- 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

2
4
0 / 0

[JBoss JIRA] Created: (JBSEAM-308) DataModel instance changes even though the backing list did not when using PAGE scope

by Chris Rudd (JIRA)

DataModel instance changes even though the backing list did not when using PAGE scope ------------------------------------------------------------------------------------- Key: JBSEAM-308 URL: http://jira.jboss.com/jira/browse/JBSEAM-308 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.0.1, 1.0, 1.0 beta 2, 1.0 beta 1, 1.1 Reporter: Chris Rudd The outjectDataModel code attempts to determine if the value changed and therefore needs to be re outjected. When not using PAGE scope this works fine. When PAGE scope is used it always reports dirty, which causes the value to be outjected. The issue is that if the backing value didnt change, it still gets re-wrapped and outjected instead of just re-outjected. I noticed this when working with an @DataModel, the UIData components im using cache the DataModel to ensure that it doesnt change between the updateValues and the invokeApplication phases. So hwat ends up happening is that in the updateValues phase a property gets set on my component, causing the datamodel to be re-outjected, since the UIData has already cached the original value, it never picks up the "new" one. When I get to the invokeApplication phase and it calls an action method on the component the datamodel that the UIData updated the rowIndex on isnt the same one that seam pulls the rowIndex from to inject the @DataModelSelection. I propose the following fix to the 1.0.0 GA code ( removed PAGE scope check from dirty assignment, added else clause to if(dirty) ): private void outjectDataModelList(String name, Object list, ScopeType scope, DataBinder wrapper) { Context context = getDataModelContext(scope); Object existingDataModel = context.get(name); boolean dirty = existingDataModel == null || !wrapper.getWrappedData(existingDataModel).equals(list); //TODO: delegate to the wrapper to determine equality if ( dirty ) { if ( list != null ) { context.set( name, wrapper.wrap(list) ); } else { context.remove( name ); } } // If page scope, outject the existingDataModel even if there was no change else if( scope==ScopeType.PAGE ) { context.set( name, existingDataModel ); } } -- 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

2
3
0 / 0

[JBoss JIRA] Created: (JBSEAM-313) <s:validateAll> + facelets user tag

by Denis Karpov (JIRA)

<s:validateAll> + facelets user tag ----------------------------------- Key: JBSEAM-313 URL: http://jira.jboss.com/jira/browse/JBSEAM-313 Project: JBoss Seam Issue Type: Bug Components: Core Environment: jBoss 4.0.4.GA Seam 1.0.1.GA Reporter: Denis Karpov ================================================= *.xhtml file: -------------------- ..... <s:validateAll> <clv:edit id="edit" label="Test editable" value="#{test.obj.code}"/>  </s:validateAll> ..... ================================================== tag file: ----------------- .... <ui:component xmlns="http://www.w3.org/1999/xhtml" xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html"> <input id="#{id}" type="text" jsfc="h:inputText" value="#{value}"/>  </ui:component> .... ================================================= Look at value=#{value} Validation framework now can not process such binding that concerns facelets templateing. In attachment you will find simple working project. Just uncomment  and you will get exception. Exception: 19:07:19,921 ERROR [[Faces Servlet]] Servlet.service() for servlet Faces Servlet threw exception java.lang.RuntimeException: not an attribute value binding: #{value} at org.jboss.seam.ui.ModelValidator.validate(ModelValidator.java:30) at javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:157) at javax.faces.component.UIInput.validateValue(UIInput.java:312) at javax.faces.component.UIInput.validate(UIInput.java:353) at javax.faces.component.UIInput.processValidators(UIInput.java:183) at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624) at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624) at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624) at javax.faces.component.UIForm.processValidators(UIForm.java:70) at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624) at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:146) at org.apache.myfaces.lifecycle.LifecycleImpl.processValidations(LifecycleImpl.java:262) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) -- 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

2
2
0 / 0

[JBoss JIRA] Created: (JBSEAM-323) NPE when calling WebRemote method returning interface

by Michael Steiner (JIRA)

NPE when calling WebRemote method returning interface ------------------------------------------------------- Key: JBSEAM-323 URL: http://jira.jboss.com/jira/browse/JBSEAM-323 Project: JBoss Seam Issue Type: Bug Components: Remoting Affects Versions: 1.1 Reporter: Michael Steiner Priority: Minor InterfaceGenerator calls c = c.getSuperclass(); for interaces it is null than calls !c.equals(Object.class) and this throws NullPointerException. -- 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

3
5
0 / 0

[JBoss JIRA] Created: (JBSEAM-309) Debug page throws LIE when viewing entity bean with lazy collection

by Christian Bauer (JIRA)

Debug page throws LIE when viewing entity bean with lazy collection ------------------------------------------------------------------- Key: JBSEAM-309 URL: http://jira.jboss.com/jira/browse/JBSEAM-309 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.0.1 Reporter: Christian Bauer Priority: Minor When I click on my logged in user variable in the Session context on the Seam debug page I get a LIE for a lazy collection in that user entity bean instance. -- 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

2
1
0 / 0

[JBoss JIRA] Created: (JBSEAM-312) seam dvd example - confirm.xhtml, order.totalAmount have to be currentOrder.totalAmount

by Torsten Krah (JIRA)

seam dvd example - confirm.xhtml, order.totalAmount have to be currentOrder.totalAmount --------------------------------------------------------------------------------------- Key: JBSEAM-312 URL: http://jira.jboss.com/jira/browse/JBSEAM-312 Project: JBoss Seam Issue Type: Bug Components: Examples Affects Versions: 1.0.1 Environment: JBoss 4.0.4 AS - Sun JDK 1.5.07 Reporter: Torsten Krah Priority: Trivial In confirm.xhtml the el expression for totalamount needs to be currentOrder.totalAmount, not order.totalAmount. kind regards Torsten -- 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

2
1
0 / 0

[JBoss JIRA] Created: (JBSEAM-319) s:link does not work after JBoss restart

by Chris Hane (JIRA)

s:link does not work after JBoss restart ---------------------------------------- Key: JBSEAM-319 URL: http://jira.jboss.com/jira/browse/JBSEAM-319 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.1 Environment: jboss jems 4.0.4 seam 1.1 Reporter: Chris Hane On a results screen I use the s:link tag in a table. The results screen is generated from a SFSB with ScopeType.EVENT. When the user clicks on the <s:link /> action, a new screen opens up from another SFSB with ScopeType.CONVERSATION. This works great until JBoss is restarted. Once restarted, the view action (below) on an existing results screen returns the results.xhtml screen without any records and does not seem to call the SFSB editor.view that I expected. See the thread for the full description. -- 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

2
2
0 / 0

[JBoss JIRA] Created: (JBSEAM-315) No control over the process definition when using components "taskInstanceListForType" & "pooledTaskInstanceList"

by Aravind Kumar (JIRA)

No control over the process definition when using components "taskInstanceListForType" & "pooledTaskInstanceList" ----------------------------------------------------------------------------------------------------------------- Key: JBSEAM-315 URL: http://jira.jboss.com/jira/browse/JBSEAM-315 Project: JBoss Seam Issue Type: Bug Components: BPM Affects Versions: 1.0.1 Reporter: Aravind Kumar There may be multiple Business Processes running in the same application. with CreateProcess annotation we can instantiate process instance for a particular process definition. "taskInstanceListForType" & "pooledTaskInstanceList" components relies on TaskMgmtSession.java of JBPM to pull out the taskinstances that the current user is authorized to see. But theres no control over the precess definition. -- 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

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-695) PojoCache transaction rollback has limitation under certain transaction context

by Ben Wang (JIRA)

PojoCache transaction rollback has limitation under certain transaction context ------------------------------------------------------------------------------- Key: JBCACHE-695 URL: http://jira.jboss.com/jira/browse/JBCACHE-695 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Priority: Minor Fix For: POJOCache Currently PojoCache supports transaction rollback. For instance, cache.attach(id, pojo); is transactional even if there is no user transaction. However, with user transaction, tx.begin(); cache.attach(id, pojo); pojo.setAge(20); tx.rollback(); the replication is rollbacked but the in-memory copy is not, e.g., pojo.getAge() == 20. There is a workaround if you are using transaction by yourself: // Just make sure this one succeeds first. tx.begin(); cache.attach(id, pojo); tx.commit(); // All subsquent field update will be transactional then. tx.begin(); pojo.setAge(20); tx.rollback(); -- 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

1
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-435) PointToPoint delivery with multiple consumers and selectors is broken

by Tim Fox (JIRA)

PointToPoint delivery with multiple consumers and selectors is broken --------------------------------------------------------------------- Key: JBMESSAGING-435 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-435 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.0.1.CR3 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.0.2 The temporary "hack" fix put in to address JBMESSAGING-275 also breaks point to point delivery. If there is a queue with multiple competing consumers with different selectors. If a messages doesn't match the first consumer but does match the second consumer, because it is "arrested" in the first consumer, then the point to point router does not try it with the second consumer. Instead of "hacking the hack" we should fix all of this properly when we do JBMESSAGING-275 -- 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

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2006