April 2007 - seam-issues - Jboss List Archives

[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-1142) Improve Seam deployment/scanning speed

by Mike Quilleash (JIRA)

Improve Seam deployment/scanning speed -------------------------------------- Key: JBSEAM-1142 URL: http://jira.jboss.com/jira/browse/JBSEAM-1142 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 1.1.6.GA Environment: Any Reporter: Mike Quilleash Currently the Seam component scanning takes prohibitively long in development when scanning a large project. My project has several thousand java files of which <1% are Seam components. For a Tomcat deployment changing from explicitly specifying the components to using the Seam scanning increases the startup time from 25 seconds to 50 seconds. Most of the 25 seconds is building a hibernate session factory. A possible enhancement would be to allow restriction of the packages that will be scanned via something in the components.xml. e.g. <scanning-config> <include-package name="com.xxx.web.seam.component"/> </scanning-config> Without this present behaviour is default. With it, it will only scan specified packages. Current workaround would be to package into separate jars but that's not always possible esp in development. -- 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

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1218) Make LocalDispatcher not dependent on javax.ejb.Timer

by Michael Youngstrom (JIRA)

Make LocalDispatcher not dependent on javax.ejb.Timer ----------------------------------------------------- Key: JBSEAM-1218 URL: http://jira.jboss.com/jira/browse/JBSEAM-1218 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 1.2.1.GA Reporter: Michael Youngstrom Priority: Minor Fix For: 1.3.0.BETA1 I'm attempting to create a port of the @Asynchronous annotation for Spring. (JBSEAM-1217) It would appear the correct way to do this would be to create a Spring Dispatcher component that would override the core Dispatcher component. However, the LocalDispatcher Interface is dependent on javax.ejb.Timer I can probably wrap my spring dispatch implementation into the javax.ejb.Timer but it would be nice if a seam version of javax.ejb.Timer were created so that the j2ee.jar would not be required for users who wish to use @Asynchronous under a web container. -- 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

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1144) Make org.jboss.seam.util.Transactions a seam component

by Michael Youngstrom (JIRA)

Make org.jboss.seam.util.Transactions a seam component ------------------------------------------------------ Key: JBSEAM-1144 URL: http://jira.jboss.com/jira/browse/JBSEAM-1144 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 1.2.1.GA Reporter: Michael Youngstrom Fix For: 1.3.0.BETA1 I know this is probably a loaded issue but please hear me out. :) It would be nice if org.jboss.seam.util.Transactions was replaced with a Seam Component just like everything else in Seam. This would allow for pluggable Transaction Management providers and pave the way for support for Spring Managed Transactions, JPA Local Transactions, and true Hibernate Local Transactions. This will allow Seam applications to run without a dependency on microcontainer in tomcat and allow for tighter Framework integration with spring and others. I would personally be more than willing to do the work of making the an initial JTATransaction component(s) as a replacement for org.jboss.seam.util.Transactions and would also create a SpringTransaction component as a proof of concept for extending the Transaction component. One problem I can see off hand is we may have to interact with a transaction in some places where a Seam ApplicationContext is not available. However, I wonder if confining Seam transactions to a seam call might help simplify matters anyway? For example transaction cleanup could take place in the @Destroy of the transaction component instead of in the ExceptionFilter? Also, this wouldn't be looked at as a JTA replacement but rather a service abstraction. Just like any other java webapp if you're using enterprise services such as EJBs or JCA JTA would be required. if you're running on tomcat or some other simple web container a resource local transaction manager (Spring's abstraction, JPA's, or Hibernate's) can be used. I'm sure there are tons of other problems I'm not looking at but worst case scenario this issue would be a great place to document them and to refer rejected feature requests. (for example JBSEAM-1118) What do you think? Mike -- 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

5
24
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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues April 2007