June 2007 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1410) Make Microcontainer to use Tomcat-defined datasources

by Alex Savitsky (JIRA)

Make Microcontainer to use Tomcat-defined datasources ----------------------------------------------------- Key: JBSEAM-1410 URL: http://jira.jboss.com/jira/browse/JBSEAM-1410 Project: JBoss Seam Issue Type: Feature Request Components: Core Reporter: Alex Savitsky Currently, when deploying on Tomcat+Microcontainer stack, the only way to define a DataSource is to define it in jboss-beans.xml file, which is located INSIDE the deployed WAR. A common (and de-facto standard) requirement for production deployments is to let server admin to define the data source, so as not to expose production DB credentials to developers. This requires for the data source definition to be outside of the deployed WAR, either in Tomcat's server.xml file, or in META-INF/context.xml. It would be nice if there would be a way to use that external datasource, instead of defining it in jboss-beans.xml -- 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

17 years, 7 months

2
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Closed: (JBSEAM-295) Ability to setup UI components programmatically in SeamTest

by Gavin King (JIRA)

[ http://jira.jboss.com/jira/browse/JBSEAM-295?page=all ] Gavin King closed JBSEAM-295. ----------------------------- Resolution: Done Added a method to FacesMessages > Ability to setup UI components programmatically in SeamTest > ----------------------------------------------------------- > > Key: JBSEAM-295 > URL: http://jira.jboss.com/jira/browse/JBSEAM-295 > Project: JBoss Seam > Issue Type: Feature Request > Components: Test Harness > Affects Versions: 1.2.1.GA > Reporter: Christian Bauer > Assigned To: Gavin King > Priority: Minor > Fix For: 1.3.0.ALPHA > > > I'd like to test for the presence of a FacesMessage for a particular component: > FacesMessages.instance().add("verify", "Re-enter your password"); > And in SeamTest subclass: > assert getFacesContext().getMessages(???).hasNext(); // Msg for component > As I don't have a component tree in my Script(), the add() method didn't assign the message to a component, so the only way I can test this is with getMessages().hasNext(), instead of the more accurate getMessage(???component???).hasNext(). -- 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

17 years, 7 months

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1430) NoSuchElementException in Tomcat

by Christian Bauer (JIRA)

NoSuchElementException in Tomcat -------------------------------- Key: JBSEAM-1430 URL: http://jira.jboss.com/jira/browse/JBSEAM-1430 Project: JBoss Seam Issue Type: Bug Reporter: Christian Bauer Exception after CVS update from this weekend (difference before and after weekend): 10:31:06,643 DEBUG [Lifecycle] flushing server-side conversation context 10:31:06,643 DEBUG [Lifecycle] flushing session context 10:31:06,643 DEBUG [Lifecycle] destroying event context 10:31:06,643 ERROR [SeamPhaseListener] uncaught exception java.util.NoSuchElementException at org.apache.catalina.core.ApplicationHttpRequest$AttributeNamesEnumerator.nextElement(ApplicationHttpRequest.java:932) at com.sun.faces.context.BaseContextMap$BaseIterator.nextKey(ExternalContextImpl.java:642) at com.sun.faces.context.BaseContextMap$KeyIterator.next(ExternalContextImpl.java:684) at com.sun.faces.context.BaseContextMap$KeyIterator.next(ExternalContextImpl.java:668) at java.util.AbstractCollection.toArray(AbstractCollection.java:176) at org.jboss.seam.contexts.BasicContext.getNames(BasicContext.java:49) at org.jboss.seam.contexts.Contexts.destroy(Contexts.java:220) at org.jboss.seam.contexts.Lifecycle.flushAndDestroyContexts(Lifecycle.java:479) at org.jboss.seam.contexts.Lifecycle.endRequest(Lifecycle.java:328) at org.jboss.seam.jsf.AbstractSeamPhaseListener.afterRender(AbstractSeamPhaseListener.java:213) at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:110) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:280) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:144) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:293) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:469) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:403) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at org.tuckey.web.filters.urlrewrite.NormalRewrittenUrl.doRewrite(NormalRewrittenUrl.java:195) at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:159) at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:141) at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:90) at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:395) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:70) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:60) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:60) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:56) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:60) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:47) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:56) at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:127) at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:277) at org.jboss.seam.web.AbstractAjax4jsfFilter.doFilter(AbstractAjax4jsfFilter.java:35) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:56) at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:127) -- 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

17 years, 7 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1366) SeamApplicationMessageBundle doesn't follow ResourceBundle contract

by Michael Youngstrom (JIRA)

SeamApplicationMessageBundle doesn't follow ResourceBundle contract ------------------------------------------------------------------- Key: JBSEAM-1366 URL: http://jira.jboss.com/jira/browse/JBSEAM-1366 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.3.0.ALPHA Reporter: Michael Youngstrom Fix For: 1.3.0.ALPHA SeamApplicationMessageBundle is backed by the Messages component. This is fine except if a that does not exist is specified then Messages will return the key as the value. This works great for Messages but it can cause problems for SeamApplicationMessageBundle. Many existing JSF components have an algorithm similar to this to display messages and other component text: 1. Get faces-config specified bunleName 2. Try to get value from resource bundle of specified bundleName 3. Catch MissingResourceException 4. Try component built in resource bundle for default message. Since SeamApplication returns "org.jboss.seam.jsf.SeamApplicationMessageBundle" by default if there is no user specified message-bundle in the faces-config this could cause some problems. Is it possible for SeamApplicationMessageBundle to throw MissingResourceException if the key is not found in Messages instead of simply returning what Messages returns which is the key itself? 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

17 years, 7 months

3
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-295) Ability to setup UI components programmatically in SeamTest

by Gavin King (JIRA)

[ http://jira.jboss.com/jira/browse/JBSEAM-295?page=all ] Gavin King updated JBSEAM-295: ------------------------------ Component/s: Test Harness (was: Core) (was: JSF) Fix Version/s: 1.3.0.ALPHA Affects Version/s: 1.2.1.GA (was: 1.0.1) Assignee: Gavin King > Ability to setup UI components programmatically in SeamTest > ----------------------------------------------------------- > > Key: JBSEAM-295 > URL: http://jira.jboss.com/jira/browse/JBSEAM-295 > Project: JBoss Seam > Issue Type: Feature Request > Components: Test Harness > Affects Versions: 1.2.1.GA > Reporter: Christian Bauer > Assigned To: Gavin King > Priority: Minor > Fix For: 1.3.0.ALPHA > > > I'd like to test for the presence of a FacesMessage for a particular component: > FacesMessages.instance().add("verify", "Re-enter your password"); > And in SeamTest subclass: > assert getFacesContext().getMessages(???).hasNext(); // Msg for component > As I don't have a component tree in my Script(), the add() method didn't assign the message to a component, so the only way I can test this is with getMessages().hasNext(), instead of the more accurate getMessage(???component???).hasNext(). -- 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

17 years, 7 months

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-255) Let SeamTest test components inside the container, but outside JSF lifecycle

by Gavin King (JIRA)

[ http://jira.jboss.com/jira/browse/JBSEAM-255?page=all ] Gavin King updated JBSEAM-255: ------------------------------ Component/s: Test Harness (was: Core) Fix Version/s: 1.3.0.ALPHA > Let SeamTest test components inside the container, but outside JSF lifecycle > ---------------------------------------------------------------------------- > > Key: JBSEAM-255 > URL: http://jira.jboss.com/jira/browse/JBSEAM-255 > Project: JBoss Seam > Issue Type: Feature Request > Components: Test Harness > Reporter: Gavin King > Assigned To: Gavin King > Priority: Critical > Fix For: 1.3.0.ALPHA > > -- 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

17 years, 7 months

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1418) Add an annotation for UIComponent implementations

by Mike Quilleash (JIRA)

Add an annotation for UIComponent implementations ------------------------------------------------- Key: JBSEAM-1418 URL: http://jira.jboss.com/jira/browse/JBSEAM-1418 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 1.2.1.GA Environment: Any Reporter: Mike Quilleash At the moment I have a wonderfully long list of component definitions in my faces-config.xml. In the same vein as @Converter and @Validator a @UIComponent annotation would be nice. Something like: This <component> <component-type>com.xxx.faces.HtmlInputInteger</component-type> <component-class>com.xxx.faces.component.html.c</component-class> </component> becoming @Name( "com.xxx.faces.HtmlInputInteger" ) @UIComponent // component type defaults to @Name public class HtmlInputInteger extends UIComponent { } -- 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

17 years, 7 months

4
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1298) UIDecorate ignores programmatic faces messages

by Christian Bauer (JIRA)

UIDecorate ignores programmatic faces messages ---------------------------------------------- Key: JBSEAM-1298 URL: http://jira.jboss.com/jira/browse/JBSEAM-1298 Project: JBoss Seam Issue Type: Bug Components: Core Reporter: Christian Bauer <s:decorate id="usernameDecorate" template="includes/formFieldDecorate.xhtml"> <ui:define name="label">Username</ui:define> <h:inputText tabindex="4" size="16" maxlength="16" required="true" id="username" value="#{userHome.instance.username}"> <a:support event="onblur" action="#{userHome.validateUsername}" reRender="usernameDecorate"/> </h:inputText> </s:decorate> The userHome.validateUsername() method: User foundUser = userDAO.findUser(getInstance().getUsername(), false, false); if ( foundUser != null && foundUser != getInstance() ) { facesMessages.addToControlFromResourceBundleOrDefault( "username", FacesMessage.SEVERITY_ERROR, getMessageKeyPrefix() + "usernameExists", "A user with that name already exists." ); return false; } return true; (This is actually wrapped again, the validateUsername() method returns void.) The decoration is not rendered as invalid. If I remove the identifier of the input field, a global message is correctly displayed. -- 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

17 years, 7 months

2
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1160) EMF implicit lookup/resolve precedence

by Christian Bauer (JIRA)

EMF implicit lookup/resolve precedence -------------------------------------- Key: JBSEAM-1160 URL: http://jira.jboss.com/jira/browse/JBSEAM-1160 Project: JBoss Seam Issue Type: Feature Request Components: Core Reporter: Christian Bauer Currently impossible to use WAR deployment and Unit testing. Only way to configure it is as follows: <core:managed-persistence-context name="entityManager" auto-create="true" entity-manager-factory="#{wikiEntityManagerFactory}" persistence-unit-jndi-name="java:/EntityManagerFactories/wiki"> </core:managed-persistence-context> <core:entity-manager-factory installed="@seamPersistenceUnit@" name="wikiEntityManagerFactory" persistence-unit-name="wiki"/> <core:ejb installed="@embeddedEjb@"/> So either the EMF is started by Seam during WAR deployment (seamPersistenceUnit) and available as a component instance in application scope, or the EMF is deployed by the E-EJB3 container and bound to JNDI with the magic JBoss configuration property in persistence.xml. The managed-persistence-context now needs to access the EMF polymorphically, no matter where it is bound. If you try the above code, you will see that the entity-manager-factory attribute always has precedence, and if it resolves to null, you get an NPE. Instead, the JNDI lookup should be attempted. -- 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

17 years, 7 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1168) Attempting to configure parent conversation id parameter throws exception

by Mike Quilleash (JIRA)

Attempting to configure parent conversation id parameter throws exception ------------------------------------------------------------------------- Key: JBSEAM-1168 URL: http://jira.jboss.com/jira/browse/JBSEAM-1168 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.1.6.GA Environment: Any Reporter: Mike Quilleash Defining this (note this is what the xsd defines) <core:manager conversation-timeout="5000" conversation-id-parameter="cid" conversation-is-long-running-parameter="clr" parent-conversation-id-parameter="pcid"/> Throw the following: java.lang.IllegalArgumentException: no such setter method: org.jboss.seam.core.Manager.parentConversationIdParameter at org.jboss.seam.util.Reflections.getSetterMethod(Reflections.java:198) at org.jboss.seam.Component.initInitializers(Component.java:375) at org.jboss.seam.Component.<init>(Component.java:266) at org.jboss.seam.Component.<init>(Component.java:207) at org.jboss.seam.init.Initialization.addComponent(Initialization.java:781) at org.jboss.seam.init.Initialization.addComponents(Initialization.java:690) at org.jboss.seam.init.Initialization.init(Initialization.java:451) at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:33) As Manager.setParentConversationIdParameter() is protected, not public. -- 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

17 years, 7 months

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues June 2007