March 2007 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1060) Documentation enhancement for themes (add JSF requestContextPath to example)

by Arjan van Bentem (JIRA)

Documentation enhancement for themes (add JSF requestContextPath to example) ---------------------------------------------------------------------------- Key: JBSEAM-1060 URL: http://jira.jboss.com/jira/browse/JBSEAM-1060 Project: JBoss Seam Issue Type: Feature Request Components: Documentation Affects Versions: 1.2.0.GA Environment: All Reporter: Arjan van Bentem Priority: Optional I know the following is actually JSF related: http://fisheye.jboss.com/browse/JBoss/jboss-seam/doc/reference/en/modules... shows the following example: <link href="#{theme.css}" rel="stylesheet" type="text/css" /> Maybe the following text can be added right below it: Or, when the page definition resides in some subdirectory: <link href="#{facesContext.externalContext.requestContextPath}/#{theme.css}" rel="stylesheet" type="text/css" /> So: <para> Or, when the page definition resides in some subdirectory: </para> <programlisting><![CDATA[ <link href="#{facesContext.externalContext.requestContextPath}/#{theme.css}" rel="stylesheet" type="text/css" /> ]]></programlisting> Furthermore, http://fisheye.jboss.com/browse/JBoss/jboss-seam/doc/reference/en/modules... shows css ../screen.css template template.xhtml while http://fisheye.jboss.com/browse/JBoss/jboss-seam/doc/reference/en/modules... refers to that last line using <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" template="#{theme.template}"> When this ui:composition is used in a page file that resides in a subdirectory (such as /admin) then the last line needs a leading slash. One could also add that leading slash to the property file. Again, this is a JSF issue. But when the template is not found then (in my world) one does not get any meaningful error message other than a Tomcat "The requested resource (xxx.seam) is not available" when JSF cannot find the template file (while the logs show that Seam is not having any trouble setting up the components as used in that page). This might be avoided by using the leading slash in the example: css ../screen.css template /template.xhtml So: <programlisting><![CDATA[css ../screen.css template /template.xhtml]]></programlisting> (I actually also wonder why the css refers to some relative path in this example, but an erroneous value would only yield a broken layout when the stylesheet is not found, and is much easier solved -- especially when knowing about facesContext.externalContext.requestContextPath). -- 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, 10 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1048) Documentation enhancement for injecting TaskInstance and ProcessInstance (add full package name)

by Arjan van Bentem (JIRA)

Documentation enhancement for injecting TaskInstance and ProcessInstance (add full package name) ------------------------------------------------------------------------------------------------ Key: JBSEAM-1048 URL: http://jira.jboss.com/jira/browse/JBSEAM-1048 Project: JBoss Seam Issue Type: Feature Request Components: Documentation Affects Versions: 1.2.0.GA Environment: All Reporter: Arjan van Bentem Priority: Optional This may be too obvious for some, but maybe, just maybe, the following needs some enhancements: http://fisheye.jboss.com/browse/JBoss/jboss-seam/doc/reference/en/modules... reads: @StartTask [...] The jBPM TaskInstance will be available in a request context variable named taskInstance. The jPBM ProcessInstance will be available in a request context variable named processInstance. (Of course, these objects are available for injection via @In.) Built-in Seam components TaskInstance and ProcessInstance exist, but in fact are not used here. Due to the @Unwrap in org.jboss.seam.core.TaskInstance and ProcessInstance one actually gets an org.jbpm.taskmgmt.exe.TaskInstance and an org.jbpm.graph.exe.ProcessInstance injected. The exception when the Java code expects a Seam component is in fact clear: java.lang.IllegalArgumentException: Could not set field value by reflection: TodoList.processInstance on: org.jboss.seam.example.todo.TodoList with value: class org.jbpm.graph.exe.ProcessInstance However, this error might be embedded in a long list of other exceptions. For example, when adding the injection to the TodoList example it will be the 5th embedded exception in a message that starts with "javax.servlet.ServletException: Cannot get value for expression '#{todoList.description}'". Fix: Maybe the text above could be changed to include the full package name (hoping that it will not change in the near future): The jBPM org.jbpm.taskmgmt.exe.TaskInstance will be available in a request context variable named taskInstance. The jBPM org.jbpm.graph.exe.ProcessInstance will be available in a request context variable named processInstance. (Of course, these objects are available for injection via @In.) The very same text applies to @BeginTask. When not changing the documentation then, as of now, at least JIRA will show a hit when searching for "injection AND ProcessInstance" ;-) -- 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, 10 months

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1005) Don't use conversationIsLongRunning by default

by Gavin King (JIRA)

Don't use conversationIsLongRunning by default ---------------------------------------------- Key: JBSEAM-1005 URL: http://jira.jboss.com/jira/browse/JBSEAM-1005 Project: JBoss Seam Issue Type: Task Components: Core Reporter: Gavin King Assigned To: Gavin King Fix For: 1.2.1.GA Now that we have conversation-required=true, conversationIsLongRunning is kinda superfluous. -- 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, 10 months

2
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-906) Support redirect component for navigation out of conversational scope

by Christian Bauer (JIRA)

Support redirect component for navigation out of conversational scope --------------------------------------------------------------------- Key: JBSEAM-906 URL: http://jira.jboss.com/jira/browse/JBSEAM-906 Project: JBoss Seam Issue Type: Feature Request Components: Core Reporter: Christian Bauer Priority: Minor It's about my favorite subject, the "history" or "cancel" button. Assume the following (RC == Root Conversation, NC == Nested Conversation): RC(1) -> NC(2) -> NC(3) I can render a Cancel button on each page in NC 2 and 3 with the action=#{conversation.endAndRedirect()} to get back to any parent NC or RC. I can not render a Cancel button on each page in RC, because there is no "parent view-id" we could redirect to. So my Cancel button on these pages has to call some logic I've written on my RC backing component. I propose to extend the Conversation.endAndRedirect() method with the following logic: - If called in a NC, do what it currently does. - If called in a RC, check if the 'redirect' component is present in RC, if yes, call 'redirect.execute()' If this would be available, I could completely control conversation navigation and the navigation history through nesting conversations (with s:link or pages.xml) and by ensuring that a RC has a prepared 'redirect' component when it is started. All Cancel buttons would be able to use action="#{conversation.endAndRedirect()}" and would either get the user "one up" in the conversation stack or "out" of conversational scope. -- 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, 10 months

2
19
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1086) Actions on navigation rules

by Gavin King (JIRA)

Actions on navigation rules --------------------------- Key: JBSEAM-1086 URL: http://jira.jboss.com/jira/browse/JBSEAM-1086 Project: JBoss Seam Issue Type: Feature Request Components: JSF Reporter: Gavin King Assigned To: Gavin King Fix For: 1.2.1.GA Christian wants to be able to add event listeners to rules, especially for handling redirection stuff, eg, see JBSEAM-906. -- 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, 10 months

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1128) Calling getPage outside of a JSF request causes NPE

by Mike Quilleash (JIRA)

Calling getPage outside of a JSF request causes NPE --------------------------------------------------- Key: JBSEAM-1128 URL: http://jira.jboss.com/jira/browse/JBSEAM-1128 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.1.6.GA Environment: Any Reporter: Mike Quilleash During Seam startup I have a component that scans installed components and programatically builds page entries (page actions etc). I use getPage() as this returns a new blank page if the. However calling getPage() outside of a JSF request throws NPE as Pages.getSuffix() calls FacesContext.getCurrentInstance().getExternalContext().getInitParameter(ViewHandler.DEFAULT_SUFFIX_PARAM_NAME); The check in my case is unnecessary (the comment mentions something about a bug in the JSF RI, I am using RI 1.2_02) as the view id already has the correct suffix. -- 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, 10 months

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1084) TaskSelector

by Gavin King (JIRA)

TaskSelector ------------ Key: JBSEAM-1084 URL: http://jira.jboss.com/jira/browse/JBSEAM-1084 Project: JBoss Seam Issue Type: Feature Request Components: BPM Reporter: Gavin King Assigned To: Gavin King Priority: Minor Fix For: 1.2.1.GA Built-in component for starting tasks and redirecting to specific task view from the main task 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

18 years, 10 months

1
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1023) Looking up a filtered SMPC in non-faces servlet throws NPE

by Christian Bauer (JIRA)

Looking up a filtered SMPC in non-faces servlet throws NPE ---------------------------------------------------------- Key: JBSEAM-1023 URL: http://jira.jboss.com/jira/browse/JBSEAM-1023 Project: JBoss Seam Issue Type: Bug Components: Core Reporter: Christian Bauer Priority: Minor My servlet does: EntityManager em = ((EntityManager)org.jboss.seam.Component.getInstance("entityManager")); em.joinTransaction(); file = (!"".equals(id)) ? em.find(File.class, Long.parseLong(id)) : null; This worked OK, but after I enabled this filter: <core:filter name="accessLevelFilter"> <core:name>accessLevelFilter</core:name> <core:parameters> <key>currentAccessLevel</key> <value>#{currentAccessLevel}</value> </core:parameters> </core:filter> <core:managed-persistence-context name="entityManager" auto-create="true" entity-manager-factory="#{wikiEntityManagerFactory}"> <core:filters><value>#{accessLevelFilter}</value></core:filters> </core:managed-persistence-context> It fails with: Caused by: java.lang.NullPointerException: facesContext at org.apache.myfaces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:379) at org.jboss.seam.core.Expressions$1.getValue(Expressions.java:57) at org.jboss.seam.persistence.HibernatePersistenceProvider.enableFilter(HibernatePersistenceProvider.java:60) at org.jboss.seam.core.ManagedPersistenceContext.initEntityManager(ManagedPersistenceContext.java:85) at org.jboss.seam.core.ManagedPersistenceContext.getEntityManager(ManagedPersistenceContext.java:105) at sun.reflect.GeneratedMethodAccessor1775.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.seam.util.Reflections.invoke(Reflections.java:18) at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:121) at org.jboss.seam.Component.callComponentMethod(Component.java:1834) at org.jboss.seam.Component.unwrap(Component.java:1860) at org.jboss.seam.Component.getInstance(Component.java:1657) at org.jboss.seam.Component.getInstance(Component.java:1610) at org.jboss.seam.Component.getInstance(Component.java:1604) at org.jboss.seam.wiki.core.ui.FileServlet.doGet(FileServlet.java:70) The expression "#{currentAccessLevel}" can either be resolved to a variable in the SESSION context or to a factory method on one of my components. -- 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, 10 months

3
11
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-743) HTTP BASIC and DIGEST authentication

by Gavin King (JIRA)

HTTP BASIC and DIGEST authentication ------------------------------------ Key: JBSEAM-743 URL: http://jira.jboss.com/jira/browse/JBSEAM-743 Project: JBoss Seam Issue Type: Feature Request Components: Security Reporter: Gavin King Assigned To: Shane Bryzak Priority: Minor Fix For: 1.1.5.GA Find some way to support these awful things. Probably have to parse headers ourselves. Just copy paste some code from Tomcat or Acegi or whatever (whichever is the least obfuscated and over-designed). -- 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, 10 months

4
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-802) Support for code coverage (emma) in Seam-gen projects

by Mariusz Smykula (JIRA)

Support for code coverage (emma) in Seam-gen projects ----------------------------------------------------- Key: JBSEAM-802 URL: http://jira.jboss.com/jira/browse/JBSEAM-802 Project: JBoss Seam Issue Type: Feature Request Affects Versions: 1.1.6.GA Reporter: Mariusz Smykula This can be very helpful for developers using seam-gen :) -- 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, 10 months

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues March 2007