July 2010 - seam-issues - Jboss List Archives

[JBoss JIRA] Created: (JBSEAM-4512) BPM task does not rollback

by Jason E (JIRA)

BPM task does not rollback -------------------------- Key: JBSEAM-4512 URL: https://jira.jboss.org/jira/browse/JBSEAM-4512 Project: Seam Issue Type: Bug Components: BPM Affects Versions: 2.2.0.GA Environment: Testing this on Windows XP. Deploying to JBoss AS 4.2.2 Reporter: Jason E I have made a simple change to the ShipAction.java class in the dvdstore example that ships with Seam. Here is the change //@EndTask public String ship() { order.ship(track); TaskInstance ti = ManagedJbpmContext.instance().getTaskInstance(taskInstance.getId()); taskInstance.end(); if(true) throw new RuntimeException("TESTING"); return "admin"; } I commented out the end task annotation and I am ending the task via the TaskInstance API. When I throw the Runtime exception the changes to the ORDERS entity bean (i.e. updating the tracking number) rolls back. The problem is that the task instance change (i.e. ending the task) does not rollback. It appears that jBPM is flushing its changes in another db transaction. This seems like a bug since I would expect the ending of my task to also rollback. This seems like the desired behavior. This was the only change I made to the dvdstore example that ships with Seam 2.2.0.GA so it should be easy to reproduce. Thanks! Jason -- 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

12 years, 4 months

7
18
0 / 0

[JBoss JIRA] Created: (SEAMINTL-7) Rewrite Messages API along the lines of JBoss Logging 3

by Ken Finnigan (JIRA)

Rewrite Messages API along the lines of JBoss Logging 3 ------------------------------------------------------- Key: SEAMINTL-7 URL: https://jira.jboss.org/browse/SEAMINTL-7 Project: Seam i18n Issue Type: Feature Request Components: Messages Affects Versions: 3.0.0.Alpha1 Reporter: Ken Finnigan Fix For: 3.0.0.Alpha2 Rewrite messages API along the lines of JBoss Logging 3 to be consistent with the logging approach once the switch from slf4j is made to JBoss Logging 3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

7
37
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2764) Factory method does not create objects properly

by Bogdan Minciu (JIRA)

Factory method does not create objects properly ----------------------------------------------- Key: JBSEAM-2764 URL: http://jira.jboss.com/jira/browse/JBSEAM-2764 Project: JBoss Seam Issue Type: Bug Components: EJB3 Affects Versions: 2.0.1.GA Reporter: Bogdan Minciu Hello, It seems that my @Factory method is recognizing the created objects only in its command block. I have this class: @Stateful @Name("xtw") @Scope(ScopeType.SESSION) @AutoCreate public class XTextSessionWrapper implements LocalXTextSessionWrapper { ... @In(required=false, create=true) @Out private XLanguage activeLanguage; public String getText(String identifier) { log.info("getText(1): identifier= #0, activeLanguage= #1", identifier, getActiveLanguage()); XTextEntry xte = xTextEntryDAO.findXTextEntry(identifier, getActiveLanguage()); log.info("getText(2): identifier= #0, activeLanguage= #1", identifier, getActiveLanguage()); xte.getXtext(); } @Factory(value="activeLanguage", autoCreate=true) public void initActiveLanguage() { XLanguage xl = xLanguageDAO.findXLanguageByIdentifier("ro"); log.info("initActiveLanguage(1): activeLanguage initialized to #0", xl.getIdentifier()); setActiveLanguage(xl); log.info("initActiveLanguage(1): activeLanguage initialized to #0", getActiveLanguage().getIdentifier()); } public XLanguage getActiveLanguage() { return activeLanguage; } public void setActiveLanguage(XLanguage activeLanguage) { this.activeLanguage = activeLanguage; } ... } And i am calling the getText() method. The method calling is as expected: 1. the injected activeLanguage is detecting that it has a null value, 2. the initActiveLanguage() factory method is called 3. then the getText() method is continuing its execution. But, the problem is that when the application exists the @Factory method block, the created objects: activeLanguage is lost and reported again as null. Here is the output: 12:43:48,203 INFO [XTextSessionWrapper] initActiveLanguage(1): activeLanguage initialized to ro 12:43:48,203 INFO [XTextSessionWrapper] initActiveLanguage(1): activeLanguage initialized to ro 12:43:48,703 INFO [XTextSessionWrapper] initActiveLanguage(1): activeLanguage initialized to ro 12:43:48,703 INFO [XTextSessionWrapper] initActiveLanguage(1): activeLanguage initialized to ro 12:43:48,703 INFO [XTextSessionWrapper] getText(1): identifier= com.brit.xcms.cms.Category.12.name, activeLanguage= null 12:43:49,234 INFO [XTextSessionWrapper] getText(2): identifier= com.brit.xcms.cms.Category.12.name, activeLanguage= null Where did I went wrong? Why is the activeLanguage factoried value lost when i leave the initActiveLanguage() 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

12 years, 4 months

3
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4070) Remove restriction that seam-debug.jar must be loaded by the same classloader as jsf-facelets.jar

by Stuart Douglas (JIRA)

Remove restriction that seam-debug.jar must be loaded by the same classloader as jsf-facelets.jar ------------------------------------------------------------------------------------------------- Key: JBSEAM-4070 URL: https://jira.jboss.org/jira/browse/JBSEAM-4070 Project: Seam Issue Type: Patch Reporter: Stuart Douglas Attachments: statewriter-patch.diff If seam-debug.jar and jsf-facelets.jar are not in the same classloader a redirect loop occurs when the debug page is displayed. I have changed the StateWriterControl class to use reflection to access StateWriter. This also mean the StateWriterControl can be moved out of com.sun.facelets and into an org.jboss.seam package. -- 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

12 years, 6 months

5
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4185) ViewExpiredException is printed in the log even if i set log="false"

by Adrian Mitev (JIRA)

ViewExpiredException is printed in the log even if i set log="false" -------------------------------------------------------------------- Key: JBSEAM-4185 URL: https://jira.jboss.org/jira/browse/JBSEAM-4185 Project: Seam Issue Type: Bug Components: JSF Integration Affects Versions: 2.1.2.CR1 Reporter: Adrian Mitev Attachments: exception.txt See exception.txt for the stacktrace. This is what i have in pages.xml <exception class="javax.faces.application.ViewExpiredException" log="false"> <redirect view-id="/common/error.xhtml"> <message>#{messages.sessionTimeout}</message> </redirect> </exception> and the redirect is performed but i still see the exception in the log -- 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

12 years, 6 months

5
13
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2697) Add attribute to s:link tag to make creation of magic dataModelSelection URL parameter optional

by Wolfgang Schwendt (JIRA)

Add attribute to s:link tag to make creation of magic dataModelSelection URL parameter optional ----------------------------------------------------------------------------------------------- Key: JBSEAM-2697 URL: http://jira.jboss.com/jira/browse/JBSEAM-2697 Project: JBoss Seam Issue Type: Feature Request Components: JSF Controls Affects Versions: 2.0.1.GA Reporter: Wolfgang Schwendt Priority: Minor When an s:link component (org.jboss.seam.ui.component.UILink) is placed into a h:dataTable backed by a javax.faces.model.DataModel, the s:link automatically generates the magic token for the magic "dataModelSelection" parameter regardless of whether the latter is really needed or not. This can generate ugly URLs. The following example is particulary ugly: http://127.0.0.1:8080/seminaris/seminarDetails.seam?seminarId=2&dataModel... Without the "dataModelSelection" parameter, the URL would look much cleaner: http://127.0.0.1:8080/seminaris/seminarDetails.seam?semId=2 So my question: Couldn't we make the "dataModelSelection" parameter optional? (For example, by adding an attribute to the s:link tag). Btw: I'm aware that org.jboss.seam.ui.component.UISeamCommandBase.getUrl() is the culprit that triggers inclusion of the the dataModelSelection parameter, so I know how to remove the dataModelSelection parameter generation, but it would be nice if also the officially released Seam version allowed the deactivation of the magic token generation. Further, no magic token is generated if a UIDataTable is supplied by a normal List rather than a DataModel (cf. UISeamCommandBase.getSelection() ), but unfortunately there can be cases where it makes sense to supply the table data as DataModel rather than normal List. -- 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

12 years, 7 months

3
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4428) <s:decorate> tag gives a "[renderkit] 'for' attribute cannot be null" message when no EditableValueHolder is found

by Julien Kronegg (JIRA)

<s:decorate> tag gives a "[renderkit] 'for' attribute cannot be null" message when no EditableValueHolder is found ------------------------------------------------------------------------------------------------------------------ Key: JBSEAM-4428 URL: https://jira.jboss.org/jira/browse/JBSEAM-4428 Project: Seam Issue Type: Bug Affects Versions: 2.1.2.GA Environment: Seam 2.1.2.GA, http://fisheye.jboss.org/browse/Seam/branches/community/Seam_2_1/ui/src/m..., http://fisheye.jboss.org/browse/Seam/branches/community/Seam_2_1/ui/src/m... Reporter: Julien Kronegg Priority: Minor When a field is decorated using <s:decorate> with the default Seam template "edit.xhtml" on content without EditableValueHolder (i.e. editable elements such as <h:inputText>), the following warning is issued: WARN [renderkit] 'for' attribute cannot be null This occurs for example on the following code snippet: <s:decorate id="char" template="edit.xhtml"> <ui:define name="label">Characters Left:</ui:define> <h:outputText id="charLeft" value="#{smsClass.charLeft}"/> </s:decorate> The Seam edit.xhtml template is the following: <ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xmlns:s="http://jboss.com/products/seam/taglib"> <div class="prop"> <s:label styleClass="name #{invalid?'errors':''}"> <ui:insert name="label"/> <s:span styleClass="required" rendered="#{required}">*</s:span> </s:label> <span class="value #{invalid?'errors':''}"> <s:validateAll> <ui:insert/> </s:validateAll> </span> <span class="error"> <h:graphicImage value="/img/error.gif" rendered="#{invalid}" styleClass="errors"/> <s:message styleClass="errors"/> </span> </div> </ui:composition> This is caused by org.jboss.seam.ui.component.UIDecorate which gets the 'for' id by looking at the first available EditableValueHolder. When there is no such element, the 'for' id is null, hence the warning message (probably issued by the org.jboss.seam.ui.component.UIMessage parent class javax.faces.component.html.HtmlMessage). The warning message is very anonying and give no useful information on what is going wrong: this kind of messages takes a lot of time to track and makes a big impact on the developper productivity. The UIDecorate class should either: 1) display no error message (by either attaching the s:message tag to the s:decorate itself, or by avoid rendering the s:message) 2) display a more meaningfull message such as "No editable component found to attach the message in the decorate with id=xxx" (maybe to be combined with solution 1). -- 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

12 years, 7 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4072) JUnit 4 version of SeamTest

by Dan Allen (JIRA)

JUnit 4 version of SeamTest --------------------------- Key: JBSEAM-4072 URL: https://jira.jboss.org/jira/browse/JBSEAM-4072 Project: Seam Issue Type: Feature Request Affects Versions: 2.1.1.GA Reporter: Dan Allen Fix For: The future NetBeans still lacks a good plugin for TestNG and arguably JUnit 4 is still better supported in IDEs overall. Therefore, it would be nice if Seam would provide a base test class for JUnit 4. Since JUnit 4 has parallel support for tests being declared through the use of annotations, it should be fairly straightforward to support both test frameworks. Better yet, someone has already done the work. Please see http://bernard.labno.pl/?action=seamtest4junit -- 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

12 years, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (JBSEAM-4621) Page Navigation exception after upgrading to JSF 2.0

by Sheng Gu (JIRA)

Page Navigation exception after upgrading to JSF 2.0 ---------------------------------------------------- Key: JBSEAM-4621 URL: https://jira.jboss.org/jira/browse/JBSEAM-4621 Project: Seam Issue Type: Bug Components: Core Affects Versions: 2.2.1.CR1 Environment: Seam 2.2.1.CR1 + JSF 2.0 Sun Reporter: Sheng Gu Priority: Blocker Fix For: 2.2.1.CR2 Hi there, After upgrading to JSF2.0, I got the following exceptions. The login.xhtml and login.page.xml codes are listed as follows: login.xhtml: <h:commandButton value="LOGIN" action="#{identity.login}"/> <h:commandButton value="SIGN UP!" action="register" immediate="true"/> login.page.xml: <?xml version="1.0" encoding="UTF-8"?> <page xmlns="http://jboss.com/products/seam/pages" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://jboss.com/products/seam/pages http://jboss.com/products/seam/pages-2.2.xsd"> <end-conversation before-redirect="true" root="true"/> <navigation from-action="#{identity.login}"> <rule if="#{identity.loggedIn}"> <end-conversation before-redirect="true" root="true"/> <redirect view-id="/home.xhtml" /> </rule> </navigation> <navigation from-action="register"> <begin-conversation join="false"/> <redirect view-id="/register.xhtml" /> </navigation> </page> java.lang.IllegalStateException at org.apache.catalina.connector.ResponseFacade.sendRedirect(ResponseFacade.java:435) at org.jboss.seam.mock.MockExternalContext.redirect(MockExternalContext.java:528) at org.jboss.seam.faces.FacesManager.redirect(FacesManager.java:220) at org.jboss.seam.faces.FacesManager.redirect(FacesManager.java:185) at org.jboss.seam.faces.Navigator.redirect(Navigator.java:55) at org.jboss.seam.faces.Navigator.redirect(Navigator.java:42) at org.jboss.seam.exception.RedirectHandler.handle(RedirectHandler.java:51) at org.jboss.seam.exception.Exceptions.handle(Exceptions.java:76) at org.jboss.seam.web.ExceptionFilter.endWebRequestAfterException(ExceptionFilter.java:114) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:70) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595) -- 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

12 years, 9 months

4
10
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2896) component set for generating excel documents

by Dan Allen (JIRA)

component set for generating excel documents -------------------------------------------- Key: JBSEAM-2896 URL: http://jira.jboss.com/jira/browse/JBSEAM-2896 Project: Seam Issue Type: Feature Request Components: JSF Controls Affects Versions: 2.1.0.A1, 2.0.2.CR1, 2.0.1.GA Reporter: Dan Allen Fix For: 2.1.x We should mirror the functionality of creating PDF documents from Facelets templates and create a component set that generates excel documents. There are two approaches we can take. One approach is to use POI to build the document structure and then export it. The second approach is to build an XML document that Excel can understand. Technically there is no reason to actually produce a binary Excel document as long as we can feed something that Excel knows how to convert. Regular CSV support would be nice too, but I always find that to be such a cop out. Creating this module shouldn't be too technically challenging since most of the infrastructure has been set up already when creating the PDF components. In fact, i would start by working in that module and then split it out into another JAR. Some resource links: http://www.codeproject.com/KB/office/excelxmllibrary.aspx http://xelem.sourceforge.net/ -- 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

12 years, 9 months

5
27
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues July 2010