[JBoss JIRA] Commented: (JBSEAM-4543) seam-gen should not use resources:// for things that are in web/view content
by Jay Balunas (JIRA)
[ https://jira.jboss.org/jira/browse/JBSEAM-4543?page=com.atlassian.jira.pl... ]
Jay Balunas commented on JBSEAM-4543:
-------------------------------------
Apparently I got knocked off the cool guy list, and am not on the Seam dev list for the jira project. This means I can't move the jira. Dan - can you please move this?
PS: And add me to the seam dev permission in JBSEAM ;-)
> seam-gen should not use resources:// for things that are in web/view content
> ----------------------------------------------------------------------------
>
> Key: JBSEAM-4543
> URL: https://jira.jboss.org/jira/browse/JBSEAM-4543
> Project: Seam
> Issue Type: Bug
> Components: Tools
> Affects Versions: 2.1.2.GA, 2.2.0.GA
> Environment: winxp x86, jdk6, jboss5
> Reporter: Jacques Lemire
> Assignee: Dan Allen
> Priority: Blocker
> Fix For: 2.2.1.CR1
>
>
> seam-gen templates are using resource:// for things that are not on the classpath (currently build.xml hacks around this by duplicating the .xcss files in the war)
> Original description:
> In projects generated through "File" -> "New" -> "Seam web project", the facelets template "layout/template.xhtml" contains the following component in the "head" section:
> layout/template.xhtml:
> <a:loadStyle src="resource:///stylesheet/theme.xcss"/>
> This component, from a4j should transform the "richfaces templatable css" (xcss) file into a real CSS file and render as a <link> tag containing an a4j resource url. In projects created from the command-line seam-gen script, the output is as expected:
> <link class='user' rel='stylesheet' type='text/css' href='/testxcss/a4j/s/3_2_2.SR1stylesheet/theme.xcss/DATB/eAFrvajdHLp8hjQAEgwDtA__' />
> However, using jboss tools, I get:
> <link class='user' rel='stylesheet' type='text/css' href='/SeamThemeTest/stylesheet/theme.xcss' />
> This version does not work, however, as the xcss file is returned to the browser as is.
> By looking at the differences between the seam-gen project and the jbosstools project, i noticed the following section of the build.xml ant file generated by seam-gen:
> <copy todir="${war.dir}/WEB-INF/classes">
> <fileset dir="${basedir}/resources">
> <include name="**/*.xcss"/>
> </fileset>
> <!-- move XCSS into classpath for now
> loading from web context only works in JBoss AS 4 -->
> <fileset dir="${basedir}/view">
> <include name="**/*.xcss"/>
> </fileset>
> </copy>
> This step is not done by jbosstools (3.1.0), and indeed, by doing a quick web search, I fell on the following jira: https://jira.jboss.org/jira/browse/JBAS-6034, which states that:
> > [...] that would work in 4.2.x but not in jboss5 where the root of the war is no longer a part of the war's classpath (and never should have been!)
> Please fix it as soon as possible, as this problem affects any generated site and is pretty difficult to debug. On the other hand, it should be very easy to fix.
--
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
14 years, 4 months
[JBoss JIRA] Commented: (JBSEAM-4543) seam-gen should not use resources:// for things that are in web/view content
by Jay Balunas (JIRA)
[ https://jira.jboss.org/jira/browse/JBSEAM-4543?page=com.atlassian.jira.pl... ]
Jay Balunas commented on JBSEAM-4543:
-------------------------------------
I believe Alex has already created a fix for this and checked it into the RichFaces 3.3.X branch.
I will move this jira to RF and assign to Alex for resolution.
> seam-gen should not use resources:// for things that are in web/view content
> ----------------------------------------------------------------------------
>
> Key: JBSEAM-4543
> URL: https://jira.jboss.org/jira/browse/JBSEAM-4543
> Project: Seam
> Issue Type: Bug
> Components: Tools
> Affects Versions: 2.1.2.GA, 2.2.0.GA
> Environment: winxp x86, jdk6, jboss5
> Reporter: Jacques Lemire
> Assignee: Dan Allen
> Priority: Blocker
> Fix For: 2.2.1.CR1
>
>
> seam-gen templates are using resource:// for things that are not on the classpath (currently build.xml hacks around this by duplicating the .xcss files in the war)
> Original description:
> In projects generated through "File" -> "New" -> "Seam web project", the facelets template "layout/template.xhtml" contains the following component in the "head" section:
> layout/template.xhtml:
> <a:loadStyle src="resource:///stylesheet/theme.xcss"/>
> This component, from a4j should transform the "richfaces templatable css" (xcss) file into a real CSS file and render as a <link> tag containing an a4j resource url. In projects created from the command-line seam-gen script, the output is as expected:
> <link class='user' rel='stylesheet' type='text/css' href='/testxcss/a4j/s/3_2_2.SR1stylesheet/theme.xcss/DATB/eAFrvajdHLp8hjQAEgwDtA__' />
> However, using jboss tools, I get:
> <link class='user' rel='stylesheet' type='text/css' href='/SeamThemeTest/stylesheet/theme.xcss' />
> This version does not work, however, as the xcss file is returned to the browser as is.
> By looking at the differences between the seam-gen project and the jbosstools project, i noticed the following section of the build.xml ant file generated by seam-gen:
> <copy todir="${war.dir}/WEB-INF/classes">
> <fileset dir="${basedir}/resources">
> <include name="**/*.xcss"/>
> </fileset>
> <!-- move XCSS into classpath for now
> loading from web context only works in JBoss AS 4 -->
> <fileset dir="${basedir}/view">
> <include name="**/*.xcss"/>
> </fileset>
> </copy>
> This step is not done by jbosstools (3.1.0), and indeed, by doing a quick web search, I fell on the following jira: https://jira.jboss.org/jira/browse/JBAS-6034, which states that:
> > [...] that would work in 4.2.x but not in jboss5 where the root of the war is no longer a part of the war's classpath (and never should have been!)
> Please fix it as soon as possible, as this problem affects any generated site and is pretty difficult to debug. On the other hand, it should be very easy to fix.
--
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
14 years, 4 months
[JBoss JIRA] Commented: (JBSEAM-4543) seam-gen should not use resources:// for things that are in web/view content
by Dan Allen (JIRA)
[ https://jira.jboss.org/jira/browse/JBSEAM-4543?page=com.atlassian.jira.pl... ]
Dan Allen commented on JBSEAM-4543:
-----------------------------------
Thanks Marek.
The behavior of resource:// now comes full circle in my head. I was always confused as to why resource:// worked from the web context in AS 4 but not AS 5. Originally, I had thought that RichFaces was just being aggressive in seeking out the resource. But now I understand that it was all accidental that it worked in the first place. This makes so much more sense now.
> seam-gen should not use resources:// for things that are in web/view content
> ----------------------------------------------------------------------------
>
> Key: JBSEAM-4543
> URL: https://jira.jboss.org/jira/browse/JBSEAM-4543
> Project: Seam
> Issue Type: Bug
> Components: Tools
> Affects Versions: 2.1.2.GA, 2.2.0.GA
> Environment: winxp x86, jdk6, jboss5
> Reporter: Jacques Lemire
> Assignee: Dan Allen
> Priority: Blocker
> Fix For: 2.2.1.CR1
>
>
> seam-gen templates are using resource:// for things that are not on the classpath (currently build.xml hacks around this by duplicating the .xcss files in the war)
> Original description:
> In projects generated through "File" -> "New" -> "Seam web project", the facelets template "layout/template.xhtml" contains the following component in the "head" section:
> layout/template.xhtml:
> <a:loadStyle src="resource:///stylesheet/theme.xcss"/>
> This component, from a4j should transform the "richfaces templatable css" (xcss) file into a real CSS file and render as a <link> tag containing an a4j resource url. In projects created from the command-line seam-gen script, the output is as expected:
> <link class='user' rel='stylesheet' type='text/css' href='/testxcss/a4j/s/3_2_2.SR1stylesheet/theme.xcss/DATB/eAFrvajdHLp8hjQAEgwDtA__' />
> However, using jboss tools, I get:
> <link class='user' rel='stylesheet' type='text/css' href='/SeamThemeTest/stylesheet/theme.xcss' />
> This version does not work, however, as the xcss file is returned to the browser as is.
> By looking at the differences between the seam-gen project and the jbosstools project, i noticed the following section of the build.xml ant file generated by seam-gen:
> <copy todir="${war.dir}/WEB-INF/classes">
> <fileset dir="${basedir}/resources">
> <include name="**/*.xcss"/>
> </fileset>
> <!-- move XCSS into classpath for now
> loading from web context only works in JBoss AS 4 -->
> <fileset dir="${basedir}/view">
> <include name="**/*.xcss"/>
> </fileset>
> </copy>
> This step is not done by jbosstools (3.1.0), and indeed, by doing a quick web search, I fell on the following jira: https://jira.jboss.org/jira/browse/JBAS-6034, which states that:
> > [...] that would work in 4.2.x but not in jboss5 where the root of the war is no longer a part of the war's classpath (and never should have been!)
> Please fix it as soon as possible, as this problem affects any generated site and is pretty difficult to debug. On the other hand, it should be very easy to fix.
--
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
14 years, 4 months
[JBoss JIRA] Resolved: (JBSEAM-4543) seam-gen should not use resources:// for things that are in web/view content
by Marek Novotny (JIRA)
[ https://jira.jboss.org/jira/browse/JBSEAM-4543?page=com.atlassian.jira.pl... ]
Marek Novotny resolved JBSEAM-4543.
-----------------------------------
Resolution: Done
I have changed path to richfaces xcss stylesheet in template.xhtml.
> seam-gen should not use resources:// for things that are in web/view content
> ----------------------------------------------------------------------------
>
> Key: JBSEAM-4543
> URL: https://jira.jboss.org/jira/browse/JBSEAM-4543
> Project: Seam
> Issue Type: Bug
> Components: Tools
> Affects Versions: 2.1.2.GA, 2.2.0.GA
> Environment: winxp x86, jdk6, jboss5
> Reporter: Jacques Lemire
> Assignee: Dan Allen
> Priority: Blocker
> Fix For: 2.2.1.CR1
>
>
> seam-gen templates are using resource:// for things that are not on the classpath (currently build.xml hacks around this by duplicating the .xcss files in the war)
> Original description:
> In projects generated through "File" -> "New" -> "Seam web project", the facelets template "layout/template.xhtml" contains the following component in the "head" section:
> layout/template.xhtml:
> <a:loadStyle src="resource:///stylesheet/theme.xcss"/>
> This component, from a4j should transform the "richfaces templatable css" (xcss) file into a real CSS file and render as a <link> tag containing an a4j resource url. In projects created from the command-line seam-gen script, the output is as expected:
> <link class='user' rel='stylesheet' type='text/css' href='/testxcss/a4j/s/3_2_2.SR1stylesheet/theme.xcss/DATB/eAFrvajdHLp8hjQAEgwDtA__' />
> However, using jboss tools, I get:
> <link class='user' rel='stylesheet' type='text/css' href='/SeamThemeTest/stylesheet/theme.xcss' />
> This version does not work, however, as the xcss file is returned to the browser as is.
> By looking at the differences between the seam-gen project and the jbosstools project, i noticed the following section of the build.xml ant file generated by seam-gen:
> <copy todir="${war.dir}/WEB-INF/classes">
> <fileset dir="${basedir}/resources">
> <include name="**/*.xcss"/>
> </fileset>
> <!-- move XCSS into classpath for now
> loading from web context only works in JBoss AS 4 -->
> <fileset dir="${basedir}/view">
> <include name="**/*.xcss"/>
> </fileset>
> </copy>
> This step is not done by jbosstools (3.1.0), and indeed, by doing a quick web search, I fell on the following jira: https://jira.jboss.org/jira/browse/JBAS-6034, which states that:
> > [...] that would work in 4.2.x but not in jboss5 where the root of the war is no longer a part of the war's classpath (and never should have been!)
> Please fix it as soon as possible, as this problem affects any generated site and is pretty difficult to debug. On the other hand, it should be very easy to fix.
--
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
14 years, 4 months
[JBoss JIRA] Created: (JBSEAM-4548) Internationalization doesn't translate in the right language
by Wojciech Kupiec (JIRA)
Internationalization doesn't translate in the right language
------------------------------------------------------------
Key: JBSEAM-4548
URL: https://jira.jboss.org/jira/browse/JBSEAM-4548
Project: Seam
Issue Type: Bug
Affects Versions: 2.1.2.GA
Environment: Linux; jboss-4.2.2.GA; i386
Reporter: Wojciech Kupiec
The problem is that Messages.instance().get('') returns translation in wrong language in some circumstances.
To observe the bug do the following:
1. Make a component like this one:
@Name("TranslationTest")
@Scope(ScopeType.APPLICATION)
@AutoCreate
public class TranslationTest {
@Asynchronous
@Transactional
public void scheduler(@Expiration Date when, @IntervalDuration Long interval) {
System.out.print("Translated text is: #0 ".replace("#0", Messages.instance().get("validator.email")));
}
}
2. make an instance of the component when org.jboss.seam.postInitialization occures and set up the timer:
@Observer("org.jboss.seam.postInitialization")
public void postInitialization(){
TranslationTest tt= (TranslationTest) Component.getInstance(TranslationTest.class, true);
tt.scheduler(new Date(), 10000L);
}
Messages.instance().get("validator.email") will always return translation in english no matter what are your default locale settings.
--
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
14 years, 4 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3113) Seambay example gets into a looping condition when entering bids
by Jay Balunas (JIRA)
Seambay example gets into a looping condition when entering bids
----------------------------------------------------------------
Key: JBSEAM-3113
URL: http://jira.jboss.com/jira/browse/JBSEAM-3113
Project: Seam
Issue Type: Bug
Components: Examples
Affects Versions: 2.0.3.CR1
Reporter: Jay Balunas
Priority: Minor
>From JBSEAM-2956 I can now place bids on the camera with out an exception, but it does not seem to take. When I confirm the bid it keeps telling me to set my maximum bid. Even when valid it does not take it.. You seam to end up in a loop of some kind. A similar thing happens on the other auctions - when you enter a bid it is taken, but if you check the value of the bid it had not changed from the original amount. If you then try to bid again you end up in the same loop.
Also with all auctions if you don't enter a value or one that is not valid (emptry, characters, etc..) get seam debug page with this error:
13:58:58,868 ERROR [ExceptionFilter] exception root cause
javax.faces.FacesException: #{bidAction.updateBid}: java.lang.NumberFormatException: empty String
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:107)
at javax.faces.component.UICommand.broadcast(UICommand.java:383)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:447)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
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.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:164)
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:406)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
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.LoggingFilter.doFilter(LoggingFilter.java:58)
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.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.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)
Caused by: javax.faces.el.EvaluationException: java.lang.NumberFormatException: empty String
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:91)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:91)
... 45 more
Caused by: java.lang.NumberFormatException: empty String
at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:994)
at java.lang.Double.parseDouble(Double.java:482)
at org.jboss.seam.example.seambay.BidAction.updateBid(BidAction.java:58)
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.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:46)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.persistence.ManagedEntityIdentityInterceptor.aroundInvoke(ManagedEntityIdentityInterceptor.java:48)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:31)
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:107)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
at org.jboss.seam.example.seambay.BidAction_$$_javassist_10.updateBid(BidAction_$$_javassist_10.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.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:342)
at org.jboss.el.parser.AstPropertySuffix.invoke(AstPropertySuffix.java:58)
at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at com.sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:68)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:77)
... 46 more
--
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
14 years, 4 months