[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2658) s:defaultAction only works 1 submit
by Susanne Jarl (JIRA)
s:defaultAction only works 1 submit
-----------------------------------
Key: JBSEAM-2658
URL: http://jira.jboss.com/jira/browse/JBSEAM-2658
Project: JBoss Seam
Issue Type: Bug
Affects Versions: 2.0.1.GA
Environment: JBoss 4.2.2, RichFaces 3.1.4, Firefox 2.0.0.12, Windows XP
Reporter: Susanne Jarl
I use the s:defaultAction and it works the first time i hit enter, but if the inputtextfield is not validated and/or I get an error message, and then hit enter in the inputtextfield again it does not work. But if I click the submitbutton instead the second time it works. So there is a difference between clicking the button and hit enter the second time.
This is my code:
<h:form>
<s:validateAll>
<h:panelGrid columns="2">
<h:outputLabel value="#{messages['programkey.writePin']}:" for="pinCode" title="#{messages['handin.pinCode.title']}" />
<s:decorate for="pinCode">
<h:inputSecret id="pinCode" label="#{messages['programkey.writePin']}" value="#{agentHandler.pinCode}" size="4" required="true" />
<h:message for="pinCode" styleClass="errorMessage" />
</s:decorate>
<a4j:commandButton action="#{handin.handin}" value="#{messages['generic.button.ok']}" reRender="pollForProgrammingResult, pinCodePanel, feedbackPanel">
<s:defaultAction/>
</a4j:commandButton>
<s:button value="#{messages['generic.button.cancel']}" onclick="Richfaces.hideModalPanel('programModalPanel')"/>
</h:panelGrid>
</s:validateAll>
</h:form>
I have this form in a RichFaces modal panel.
--
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, 2 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-633) remoting extension in handling exceptions on client side
by Nico Gau (JIRA)
remoting extension in handling exceptions on client side
--------------------------------------------------------
Key: JBSEAM-633
URL: http://jira.jboss.com/jira/browse/JBSEAM-633
Project: JBoss Seam
Issue Type: Patch
Components: Remoting
Affects Versions: 1.1.0.GA
Reporter: Nico Gau
Priority: Optional
Hi all,
I don't really know what JIRA is by the way, so hopefully nobody is upset by this post. I first mailed Gavin but he told me I should put it in JIRA.
I currently work on a project which uses Seam Remoting directly and I didn't find a neat way in handling errors on the client side as Exceptions are not propagated to it. Therefore I changed Seam to transmit all exceptions which can be handled in the javascript part via another callback. E.g.:
Seam.Component.getInstance('userManager').currentUser(function(user) {
alert("user: " + user);
},
function(ex) {
alert("exception occured: " + ex.getMessage());
});
As the exception handler is optional, the change would not brake any client code. If you are interested in the change, you can reach me at heinzbeinz AT googlemail.com
--
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, 2 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3753) SeamResourceBundle.getBundle(String baseName) fails to return correct message based on Locale
by Samuel Mendenhall (JIRA)
SeamResourceBundle.getBundle(String baseName) fails to return correct message based on Locale
---------------------------------------------------------------------------------------------
Key: JBSEAM-3753
URL: https://jira.jboss.org/jira/browse/JBSEAM-3753
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.1.CR1, 2.0.3.CR1, 2.0.2.SP1
Reporter: Samuel Mendenhall
When specifying the Locale directly, everything works as expected, when not, the default locale is used, which is incorrect. Ex.
log.info("SeamResourceBundle.getBundle w/o passing Local: " + SeamResourceBundle.getBundle("ECISConfig").getString("ecis.hello"));
log.info("SeamResourceBundle.getBundle w passing Local: " + SeamResourceBundle.getBundle("ECISConfig", LocaleSelector.instance().getLocale()).getString("ecis.hello"));
Produces:
15:08:45,438 INFO [TestAction] SeamResourceBundle.getBundle w/o passing Local: Hello from ECISConfig_en.properties
15:08:45,439 INFO [TestAction] SeamResourceBundle.getBundle w passing Local: Hello from ECISConfig_en_US_tmwa.properties
When both should be saying "Hello from ECISConfig_en_US_tmwa.properties" because the locale and resource bundle are defined in components.xml as:
<international:locale-selector locale-string="en_US_tmwa" />
<core:resource-loader>
<core:bundle-names>
<value>messages</value>
<value>ECISConfig</value>
</core:bundle-names>
</core:resource-loader>
--
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
17 years, 2 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3566) Conversation.isLongRunning() causes NPE
by Nikolay Elenkov (JIRA)
Conversation.isLongRunning() causes NPE
---------------------------------------
Key: JBSEAM-3566
URL: https://jira.jboss.org/jira/browse/JBSEAM-3566
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.3.CR1
Environment: JBoss 4.2.2, Seam 2.0.3.CR1
Reporter: Nikolay Elenkov
I have a couple of methods that log conversation start/end for debugging purposes in may app.
The code is pretty simple:
@Observer(value = "org.jboss.seam.beginConversation")
public void onConversationStart() {
log.debug("CONVERSATION Started");
Conversation c = Conversation.instance();
log.debug(String.format("id: %s; isLongRunning %s; viewId: %s",
c.getId(), c.isLongRunning(), c.getViewId()));
}
Most of the time that works OK, but I get an occasional NPE, seems to happen when
you access the app right after JBoss has started. Here is the trace:
Caused by: java.lang.NullPointerException
at org.jboss.seam.core.Manager.isReallyLongRunningConversation(Manager.java:230)
at org.jboss.seam.core.Conversation.isLongRunning(Conversation.java:308)
at myapp.LoggerBean.onConversationEnd(LoggerBean.java:145)
--
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
17 years, 2 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3595) Concurrent problem with BasicContext
by Jonah Lee (JIRA)
Concurrent problem with BasicContext
------------------------------------
Key: JBSEAM-3595
URL: https://jira.jboss.org/jira/browse/JBSEAM-3595
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.2.SP1
Reporter: Jonah Lee
When I run concurrent test for my SEAM application with 10 concurrent users, I got the error below and my application still run.
2008-10-20 14:59:39,162 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/csms]] Session event listener threw exception
java.lang.ArrayIndexOutOfBoundsException: 195
at org.jboss.seam.contexts.BasicContext.getNames(BasicContext.java:60)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:270)
at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:191)
at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:124)
at org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:44)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002)
at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962)
at org.jboss.seam.contexts.BasicContext.get(BasicContext.java:48)
at org.jboss.seam.Component.getInstance(Component.java:1854)
at org.jboss.seam.Component.getInstance(Component.java:1832)
at org.jboss.seam.web.Session.getInstance(Session.java:122)
at org.jboss.seam.contexts.FacesLifecycle.beginRequest(FacesLifecycle.java:54)
at org.jboss.seam.jsf.SeamPhaseListener.beforeRestoreView(SeamPhaseListener.java:377)
at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:137)
at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:114)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:222)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:154)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:260)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:366)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:493)
at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
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:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
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:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
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
17 years, 2 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1788) s:graphicImage fails to transform GIF images
by henrik lindberg (JIRA)
s:graphicImage fails to transform GIF images
--------------------------------------------
Key: JBSEAM-1788
URL: http://jira.jboss.com/jira/browse/JBSEAM-1788
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0.BETA1
Environment: windows xp, JDK 1.6.0
Reporter: henrik lindberg
The org.jboss.seam.ui.graphicImage.Image class fails to rescale GIF images.
This is caused by the use of BICUBIC INTERPOLATION not working for GIF images.
I see three solutions (tested in similar code in one of my servlets that suffered from the same problem):
- Use this rendering hint (in use now)
g2d.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BICUBIC);
but then change the format name to "png" when writing with image IO
- Use this rendering hint
g2d.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR);
and render as "gif"
- Use NEAREST_NEIGHBOR if image is written as a GIF, and BICUBIC otherwise.
The combination INTERPOLATION_BICUBIC (as well as INTERPOLATION_LINEAR) simply does not work if the image is written with ImageIO in "gif" format.
The result is all white pixels.
--
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, 2 months