April 2009 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2292) Resources from resource servlet can't be re-rendered

by Christian Bauer (JIRA)

Resources from resource servlet can't be re-rendered ---------------------------------------------------- Key: JBSEAM-2292 URL: http://jira.jboss.com/jira/browse/JBSEAM-2292 Project: JBoss Seam Issue Type: Bug Components: JSF Reporter: Christian Bauer Found this after using the captcha: <div class="input"> <a:region> <s:validateAll> <h:graphicImage value="/seam/resource/captcha" style="vertical-align:text-bottom;"/> <h:inputText tabindex="1" size="6" maxlength="6" required="true" id="verifyCaptcha" value="#{captcha.response}"> <a:support status="#{statusId}" event="onblur" reRender="verifyCaptchaEntry"/> </h:inputText> </s:validateAll> </a:region> </div> This is a re-rendered s:decorate form field, so that onblur we get a new challenge (if the captcha repsonse was wrong). However, the graphicImage is not reloaded from the server, the browser caches it. To prevent browser caching, this is a quick hack: <div class="input"> <a:region> <s:validateAll> <h:graphicImage value="/seam/resource/captcha?nocache=#{wiki:generateRandomNumber()}" style="vertical-align:text-bottom;"/> <h:inputText tabindex="1" size="6" maxlength="6" required="true" id="verifyCaptcha" value="#{captcha.response}"> <a:support status="#{statusId}" event="onblur" reRender="verifyCaptchaEntry"/> </h:inputText> </s:validateAll> </a:region> </div> -- 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

15 years, 2 months

3
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3401) Translating Seam into your own language (pt-BR)

by Ricardo Martinelli Oliveira (JIRA)

Translating Seam into your own language (pt-BR) ----------------------------------------------- Key: JBSEAM-3401 URL: https://jira.jboss.org/jira/browse/JBSEAM-3401 Project: Seam Issue Type: Feature Request Components: Documentation Translation Reporter: Ricardo Martinelli Oliveira I would like to begin the process of translating Seam into Portuguese. (pt-BR) Language: Portuguese Locale: Brazil -- 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

15 years, 2 months

4
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1712) Allow options for SMPC per Nested Conversation

by Andy Gibson (JIRA)

Allow options for SMPC per Nested Conversation ---------------------------------------------- Key: JBSEAM-1712 URL: http://jira.jboss.com/jira/browse/JBSEAM-1712 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 2.0.0.BETA1 Environment: Windows XP, Seam 2.0 Beta, JBoss 4.2 Reporter: Andy Gibson I'd like to request the option to specify that a nested conversation gets it's own entity manager instance as opposed to sharing it with it's parent conversation and other nested conversations. The problem with nested conversations is that you can't actually use them to edit multiple entities since when you flush the PC, you flush it for all conversations. This makes nested conversations only really useful for browsing data, and creating new top level conversation to edit items to isolate the flushes. The only alternative is to use a non-Seam managed PC, and make use of the "PC per stateful bean" rule to map a single PC to a single backing bean, but you lose the benefits of a seam managed PC. What might be nice is something like : @Begin(nested=true, newPC=true) and <begin-conversation nested="true" newPC="true"/> which would indicate that this new nested conversation gets it's own entity manager instance. The attribute would be ignored if this wasn't a nested conversation, and obviously, by default, the attribute is set to false, and a shared PC would be used in the nested conversation in such cases. I'm already using one PC per conversation by using top level conversations to edit items, I'd just like to use one PC per nested conversation (where applicable) to get the benefits of nested conversations. There are a couple of posts in the forums where I've touched on some of my problems with this issue : http://www.jboss.com/index.html?module=bb&op=viewtopic&t=111681 http://www.jboss.com/index.html?module=bb&op=viewtopic&t=111384 http://www.jboss.com/index.html?module=bb&op=viewtopic&t=113362 -- 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

15 years, 2 months

7
9
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1498) inject JBoss service EJB with @In

by koen handekyn (JIRA)

inject JBoss service EJB with @In --------------------------------- Key: JBSEAM-1498 URL: http://jira.jboss.com/jira/browse/JBSEAM-1498 Project: JBoss Seam Issue Type: Feature Request Components: EJB3 Reporter: koen handekyn Priority: Minor to inject a Service EJB into a seam component, for consistency it would certainly be very nice to be able to inject it within SEAM with @In and optionally adding an @Name attribute to the service class. it would be more consistent and shorter than the standard jboss approach (below) private GlobalConfigurationMBean globalConfiguration; @Depends ("upr:service=globalConfiguration") public void setGlobalConfiguration(final GlobalConfigurationMBean globalConfiguration) { this.globalConfiguration = globalConfiguration; } -- 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

15 years, 2 months

3
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1707) @Destroy method on APPLICATION scope bean throws IllegalState(no context) at server stop time

by Frits Jalvingh (JIRA)

@Destroy method on APPLICATION scope bean throws IllegalState(no context) at server stop time --------------------------------------------------------------------------------------------- Key: JBSEAM-1707 URL: http://jira.jboss.com/jira/browse/JBSEAM-1707 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 2.0.0.BETA1 Environment: Tomcat 6.0.10, JavaBean mode, Hibernate 3.2.3, HBEM 3.3.1 Reporter: Frits Jalvingh I have a bean defined as follows: @Name("initBean") @Startup() @Scope(ScopeType.APPLICATION) public class InitBean { containing a method: @Destroy public void destroy() { Builder.getInstance().terminate(); BuildBot.getInstance().stop(); } It is meant to shutdown some daemons when the server stops. When the server stops I get an exception: 01:15:39,703 WARN [Component] Exception calling component @Destroy method: initBean java.lang.IllegalStateException: no event context active at org.jboss.seam.web.ServletContexts.instance(ServletContexts.java:40) at org.jboss.seam.web.Parameters.getRequestParameters(Parameters.java:39) at org.jboss.seam.faces.Parameters.getRequestParameters(Parameters.java:64) at org.jboss.seam.Component.injectParameters(Component.java:1334) at org.jboss.seam.Component.inject(Component.java:1304) at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:45) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:42) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:106) at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:151) at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:87) at to.etc.saram.beans.InitBean_$$_javassist_0.destroy(InitBean_$$_javassist_0.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 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:21) at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:124) at org.jboss.seam.Component.callComponentMethod(Component.java:1957) at org.jboss.seam.Component.callDestroyMethod(Component.java:1888) at org.jboss.seam.Component.destroy(Component.java:1217) at org.jboss.seam.contexts.Contexts.destroy(Contexts.java:251) at org.jboss.seam.contexts.Lifecycle.endApplication(Lifecycle.java:52) at org.jboss.seam.contexts.ServletLifecycle.endApplication(ServletLifecycle.java:121) at org.jboss.seam.servlet.SeamListener.contextDestroyed(SeamListener.java:39) at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3866) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4502) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1068) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1068) at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:448) at org.apache.catalina.core.StandardService.stop(StandardService.java:510) at org.apache.catalina.core.StandardServer.stop(StandardServer.java:744) at org.apache.catalina.startup.Catalina.stop(Catalina.java:602) at org.apache.catalina.startup.Catalina.start(Catalina.java:577) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) which seems to be caused by the bean Injector trying to access the request context which of course is no longer there. The bean contains only a single injected thingy which is the entityManager. -- 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

15 years, 2 months

4
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1879) Magic mime type detection support

by Christian Bauer (JIRA)

Magic mime type detection support --------------------------------- Key: JBSEAM-1879 URL: http://jira.jboss.com/jira/browse/JBSEAM-1879 Project: JBoss Seam Issue Type: Feature Request Components: Core Reporter: Christian Bauer Priority: Minor A component I can call to find out what mime type a particular byte[] or ByteInputStream is. The only existing solution in Java is http://sourceforge.net/projects/jmimemagic/ but it's basically an unmaintained half-working pile of junk. It's interesting that nobody ever build a simple port of file(1), which you get on every unix box, together with a fantastic (/etc/magic or /usr/share/file/magic on the Mac) database of magic bytes found in file headers. We should just take that database (or the source database from which it is generated) and write our own file(1) for Seam. Search for "mime magic java" with Google and you see why it's needed. Try "file myfile.foo" on every unix box (well, younger than 10 years) and you see how it works. -- 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

15 years, 3 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2369) Embedding custom fonts (TrueType, etc...) to the generated PDF file

by Victor Arabadzhiyski (JIRA)

Embedding custom fonts (TrueType, etc...) to the generated PDF file ------------------------------------------------------------------- Key: JBSEAM-2369 URL: http://jira.jboss.com/jira/browse/JBSEAM-2369 Project: JBoss Seam Issue Type: Feature Request Components: PDF Environment: jboss-4.2.0.GA Reporter: Victor Arabadzhiyski Using the information from the iText book and some forums I was able to generate PDF file with cyrillic content (by embedding the corresponding cyrillic-enabled font, because the default ones do not have such support). However, when I tried to generate the same PDF from JBoss Seam PDF, I found that there is no way to embed custom fonts in the PDF file from Seam and after PDF generation, the cyrillic content is simply missing (ignored?!) in the resulting PDF file. I think this will be nice multilingual feature for Seam -- 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

15 years, 3 months

3
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3963) Reverse engineering Event database table results in Home class that will not compile

by Bruce Link (JIRA)

Reverse engineering Event database table results in Home class that will not compile ------------------------------------------------------------------------------------ Key: JBSEAM-3963 URL: https://jira.jboss.org/jira/browse/JBSEAM-3963 Project: Seam Issue Type: Bug Affects Versions: 2.1.1.GA Environment: WIndows XP, MYSQL 5 database Reporter: Bruce Link Database has tables XUSER and EVENT. EVENT has a foreign key to XUSER. seam generate-entities generates a XuserHome.java file with accessor public List<Event> getEvents(); resulting in compiler error: [javac] c:\apps\projects\infosys211\src\hot\ca\bcit\infosys\session\XuserHome.java:54: getEvents() in ca.bcit.infosys.session.XuserHome cannot override getEvents() in org.jboss.seam.framework.Controller; attempting to use incompatible return type [javac] found : java.util.List<ca.bcit.infosys.model.Event> [javac] required: org.jboss.seam.core.Events [javac] public List<Event> getEvents() { [javac] ^ -- 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

15 years, 3 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2637) JIRA links

by Pete Muir (JIRA)

JIRA links ---------- Key: JBSEAM-2637 URL: http://jira.jboss.com/jira/browse/JBSEAM-2637 Project: JBoss Seam Issue Type: Feature Request Components: Wiki Reporter: Pete Muir Assigned To: Christian Bauer Priority: Optional Currently when you do [=>jbseam://1752] (which is a nice feature) it renders the link text the same, rather than the standard format of JBSEAM-1752 - is there anyway we can fix this? Or are we just going to use the newer format? -- 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

15 years, 3 months

4
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3721) Seam Remoting Callback not set before server response comes back

by Paul Chan (JIRA)

Seam Remoting Callback not set before server response comes back ---------------------------------------------------------------- Key: JBSEAM-3721 URL: https://jira.jboss.org/jira/browse/JBSEAM-3721 Project: Seam Issue Type: Bug Components: Remoting Affects Versions: 2.1.0.SP1, 2.1.0.GA Environment: XP SP3, VMWARE 3.5i ESX, 2GB RAM, DualCore AMD 3800+ Reporter: Paul Chan Assignee: Shane Bryzak Original Issue =========== I tracked the issue down to one line of javascript code in remote.js req.onreadystatechange = function() {}; The following thread discusses the problem is with an old version of the JScript.dll 5.6.0.8820 which is the same version I've got on a laptop here. http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/69... One solution is to upgrade JScript.dll to 5.6.0.8831 http://www.microsoft.com/technet/security/bulletin/ms06-023.mspx Or we can do what they did in GWT which is to move the req.onreadystatechange out of the scope of the current function window.setTimeout(function() { req.onreadystatechange = function() {}; }, 0 ); Problem found with the above fix ============================ I have found a bug in this fix. If the server response comes back before the "window.setTimeout(xxx,0) expires, it will drop it. >From reading the javascript specs, the minimum timeout value is actually around 25ms. Anything smaller than that, it gets rounded up. Also, using timer to set response callback are inherently flawed IMO. There's always going to be some sort of race condition. This problem seems to happen on internet explorer, and safari. Firebox doesn't seem to have a problem with it though. I discovered this problem when I set a break point on the incoming request processing code on the server. If the breakpoint is inserted, everything is good. But when I removed the breakpoint, the problem appears again. -- 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

15 years, 3 months

6
18
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues April 2009