Re: svn commit: r671015 - in /myfaces/tomahawk/trunk: core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java examples/simple/src/main/webapp/aliasBean.jsp
Hi!
Doesn't this change break backward compatibility completley?
The value of the alias= attribute now has to be defined differently,
instead of the el-expressesion just the name needs to be set.
Even if this change is logical to me, a new tomahawk release will break
any existing application using the aliasBean, no?
If so, I think this patch needs to be reverted unless we are going to
release a new major version of tomahawk.
Ciao,
Mario
[EMAIL PROTECTED] schrieb:
Author: lu4242
Date: Mon Jun 23 21:22:49 2008
New Revision: 671015
URL: http://svn.apache.org/viewvc?rev=671015view=rev
Log:
TOMAHAWK-790 Aliasbean warning/error when no EL expression in the alias property
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java?rev=671015r1=671014r2=671015view=diff
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
Mon Jun 23 21:22:49 2008
@@ -47,7 +47,7 @@
protected void setProperties(UIComponent component) {
super.setProperties(component);
-setStringProperty(component, alias, _alias);
+setValueBinding(component, alias, _alias);
setStringProperty(component, value, _valueExpression);
}
Modified: myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp?rev=671015r1=671014r2=671015view=diff
==
--- myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp
(original)
+++ myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp Mon
Jun 23 21:22:49 2008
@@ -45,7 +45,7 @@
h:form
h2aliasTest1/h2
-t:aliasBean alias=#{holder} value=#{aliasTest1}
+t:aliasBean alias=holder value=#{aliasTest1}
f:subview id=simulatedIncludedSubform1
%-- The next tags could be inserted by an %@ include or
jsp:include --%
h:outputLabel for=name value=Name :/
[jira] Commented: (TOMAHAWK-64) Allow t:htmlTag to support an attributes string.
[ https://issues.apache.org/jira/browse/TOMAHAWK-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607496#action_12607496 ] Christian Kaltepoth commented on TOMAHAWK-64: - Thank you very much for looking into the patch and applying it to tomahawk12. I'm sorry I didn't notice the problem of the broken example in htmlTag.jsp with core11. One last question just to clear things up: I am aware of the problem with HTML code and f:verbatim tags in the 1.1 spec. So it seems to me, that the original code in htmlTag.jsp isn't correct: t:htmlTag value=h1bh1/b tag./t:htmlTag As HTML code has to be surrounded by a f:verbatim tag, this code should look like this: t:htmlTag value=h1f:verbatimbh1/b tag./f:verbatim/t:htmlTag In this case my code works without issues. The version without f:verbatim tags seems to break, because the component was modified to render the children itself. Unfortunately the patch would certainly break existing JSF 1.1 pages that were build according to the old example. Allow t:htmlTag to support an attributes string. Key: TOMAHAWK-64 URL: https://issues.apache.org/jira/browse/TOMAHAWK-64 Project: MyFaces Tomahawk Issue Type: Bug Components: Html Tag Reporter: Michael Rimov Assignee: Leonardo Uribe Priority: Minor Fix For: 1.1.7-SNAPSHOT Attachments: htmltag_param_feature.patch I would really like to see t:htmlTag to allow html attributes to be passed into the html tag. A concrete example: td colspan=2 Hello World /td Would Ideally (to me) be converted to: t:htmlTag value=td attributes=colspan='2' h:outputText value=Hello World/ /t:htmlTag Thanks! :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1034) Warning page contains secure and nonsecure items on IE when using https
[ https://issues.apache.org/jira/browse/TOMAHAWK-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607509#action_12607509 ] Tomasz Bech commented on TOMAHAWK-1034: --- As I wrote, it is workaround. Some .js files which are used by inputSuggestBox are bundled in dojo part of tomahawk (inside jar) and loaded on demand. I found out, that loading those scripts 'on demand' causes the 'nonsecure' message in IE, but I couldn't find the reason - maybe a developer from dojo project should be contacted / can help - Leonardo, as a committer of tomahawk, can you ask someone from dojo to have a look on this issue?. The idea of workaround is to load those scripts directly from jsp page and there is no way to make THIS workaround as a patch inside tomahawk, it can only be applied in application .war file. Zip which is attached contains files, which should be put in .war and jsp page to be included in projects jsps. This is really unique component (I see no other which can be used instead), so it would be good to have a real PATCH. For now there is at least workaround. Warning page contains secure and nonsecure items on IE when using https --- Key: TOMAHAWK-1034 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1034 Project: MyFaces Tomahawk Issue Type: Bug Components: InputSuggestAjax Affects Versions: 1.1.6 Environment: IE 6, IE 7 Reporter: Vadim Fainshtein Attachments: inputSiggestBox-patch.zip TabbleSuggestAjax in IE with SSL pops up a warning message This page contains both secure and nonnsecure items. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1134) XmlMenuModel: action is interpreted as ValueExpression
XmlMenuModel: action is interpreted as ValueExpression
--
Key: TRINIDAD-1134
URL: https://issues.apache.org/jira/browse/TRINIDAD-1134
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Stephen Friedrich
An action set on an ItemNode is evaluated as a value expression.
Workround is to have a getter instead of an action-method-signature in the
backing bean:
public String getDoIt()
for an itemNode like this:
itemNode id=companies action=#{_companyList.doIt}
label=#{Output.COMPANIES} ...
See
http://www.nabble.com/-Trinidad--Bug-in-XMLMenuModel---ItemNode---tt12376683.html#a12376683
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[TRINIDAD] How to prevent input date component from showing dates before a given date
Hi, I have a requirement where I need to render the tr:inputDate component such= that on opening the calendar popup, dates before a certain date can't be s= elected.=C2=A0 How can this be brought about??? Dushyant Best Jokes, Best Friends, Best Food and more. Go to http://in.promos.yahoo.com/groups/bestofyahoo/
[jira] Commented: (TOMAHAWK-1266) t:stylesheet renders link to an empty page on tomcat-5.5.24 and above
[ https://issues.apache.org/jira/browse/TOMAHAWK-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607544#action_12607544 ] Simon Kitching commented on TOMAHAWK-1266: -- Ok, I've found the real cause of this issue. The AddResource.getResourceUri(context, Class, String, bool) method is designed specifically for serving resources out of the tomahawk jarfile *relative to a tomahawk component class*. So of course it only expects relative urls. It is really an abuse of this API to use it to serve resources out of the webapp root. Hence the problem. I'm working on a patch for this now. t:stylesheet renders link to an empty page on tomcat-5.5.24 and above - Key: TOMAHAWK-1266 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1266 Project: MyFaces Tomahawk Issue Type: Bug Components: Stylesheet Affects Versions: 1.1.5 Environment: linux, tomcat, myfaces-1.1.5, tomahawk-1.1.5 Reporter: Ronald Müller Assignee: Leonardo Uribe Fix For: 1.1.7-SNAPSHOT Attachments: stylesheet-patch.txt, StyleTest.war on tomcat-5.5.24 and above (also 6.0.x) t:stylesheet with filter-attribute set to 'true' renders a style-link that links to an empty page. without filtering everything works fine since t:stylesheet renders direct links to the css-files (not using the extension-filter). maybe this issue is related to the extension filter or it is a tomcat-issue only. since it definitely happens first time with tomcat-version 5.5.24. (5.0.x-5.5.23 working fine). i'll provide a minimal test-case as war-file. just deploy and request 'http://localhost:8080/StyleTest/styletest.faces'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [TRINIDAD] How to prevent input date component from showing dates before a given date
On Tue, Jun 24, 2008 at 2:20 AM, dushyant agarwal [EMAIL PROTECTED] wrote: Hi, I have a requirement where I need to render the tr:inputDate component such= that on opening the calendar popup, dates before a certain date can't be s= elected.=C2=A0 How can this be brought about??? This is not directly supported (meaning that the dates aren't selectable). But... we have a restriction validator for that. See the tag doc for the validator. -Matthias Dushyant Share files, take polls, and make new friends - all under one roof. Click here. -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Commented: (ORCHESTRA-18) Cannot get access-scoped beans from a servlet
[ https://issues.apache.org/jira/browse/ORCHESTRA-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607631#action_12607631 ] Simon Kitching commented on ORCHESTRA-18: - This issue should be fixed by the new SpringBasicFrameworkAdapter class available in Orchestra trunk (which will be in Orchestra 1.2). Cannot get access-scoped beans from a servlet - Key: ORCHESTRA-18 URL: https://issues.apache.org/jira/browse/ORCHESTRA-18 Project: MyFaces Orchestra Issue Type: Bug Affects Versions: 1.1 Reporter: Simon Kitching As reported by Stephan Frai: A servlet does this: ApplicationContext appContext = WebApplicationContextUtils.getWebApplicationContext(getServletContext()); PwdForgottenJSF pwdForgottenBean = (PwdForgottenJSF) appContext.getBean(pwdForgottenJSF); web.xml is set up to correctly map a BasicFrameworkAdapter to the current request. But when pwdForgottenJSF is access-scoped, then this occurs: SCHWERWIEGEND: Servlet.service() for servlet ControllerServlet threw exception java.lang.IllegalArgumentException: No AccessScopeManager found. at ...conversation.AccessScopeManager.getInstance(AccessScopeManager.java:97) at ...conversation.ConversationAccessLifetimeAspect.markAsAccessed(ConversationAccessLifetimeAspect.java:35) at ...conversation.spring.SpringConversationScope.notifyAccessConversation(SpringConversationScope.java:194) at conversation.spring.AbstractSpringOrchestraScope.getRealBean(AbstractSpringOrchestraScope.java:333) The problem is that the AccessScopeManager.getInstance method calls frameworkAdapter.getBean(), but a BasicFrameworkAdapter has no knowledge of Spring; it just looks up request/session/application scopes. A possible workaround is for the servlet to manually fetch the AccessScopeManager instance and store it in the request scope. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-22) Error creating bean with name 'org.apache.myfaces.orchestra.conversation.AccessScopeManager'
[ https://issues.apache.org/jira/browse/ORCHESTRA-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607632#action_12607632 ] Simon Kitching commented on ORCHESTRA-22: - This is using Orchestra in a Portlet. Orchestra does not yet support portlets. Error creating bean with name 'org.apache.myfaces.orchestra.conversation.AccessScopeManager' Key: ORCHESTRA-22 URL: https://issues.apache.org/jira/browse/ORCHESTRA-22 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.1 Environment: myfaces 1.1.5, myfaces-orchestra-core1.1, ascpectel-1.0-Snapshot,liferay portal 4.3.3 Reporter: Rashmi Hello, When I deploy the portal application in Liferay 4.3.3, I am getting the following exception: 2008-04-11 12:59:02,875 ERROR [org.apache.myfaces.lifecycle.PhaseListenerManager] - Exception in PhaseListener RENDER_RESPONSE(6) beforePhase. org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.myfaces.orchestra.conversation.AccessScopeManager': Scope 'request' is not active for the current thread; consider defining a scoped proxy for this bean if you intend to refer to it from a singleton; nested exception is java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request? If you are actually operating within a web request and still receive this message,your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request. Caused by: java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request? If you are actually operating within a web request and still receive this message,your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request. at org.springframework.web.context.request.RequestContextHolder.currentRequestAttributes(RequestContextHolder.java:102) at org.springframework.web.context.request.AbstractRequestAttributesScope.get(AbstractRequestAttributesScope.java:40) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160) at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:733) at org.springframework.web.jsf.DelegatingVariableResolver.resolveVariable(DelegatingVariableResolver.java:122) at org.apache.myfaces.orchestra.frameworkAdapter.jsf.JsfFrameworkAdapter.getBean(JsfFrameworkAdapter.java:174) at org.apache.myfaces.orchestra.conversation.AccessScopeManager.getInstance(AccessScopeManager.java:88) at org.apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener.beforePhase(AccessScopePhaseListener.java:91) at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:73) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:126) at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:397) at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:377) at de.seat.common.portlet.jsf.MyFacesFaceletPortlet.facesRender(MyFacesFaceletPortlet.java:156) at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:323) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:235) at javax.portlet.GenericPortlet.render(GenericPortlet.java:163) at de.seat.common.portlet.jsf.MyFacesFaceletPortlet.render(MyFacesFaceletPortlet.java:117) at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:691) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:594) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at
[jira] Issue Comment Edited: (ORCHESTRA-1) Use servlet 2.4
[
https://issues.apache.org/jira/browse/ORCHESTRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607635#action_12607635
]
skitching edited comment on ORCHESTRA-1 at 6/24/08 7:54 AM:
-
Fixed in 1.0 release
was (Author: skitching):
Fixed in 1.1 release
Use servlet 2.4
---
Key: ORCHESTRA-1
URL: https://issues.apache.org/jira/browse/ORCHESTRA-1
Project: MyFaces Orchestra
Issue Type: Bug
Components: Conversation
Affects Versions: 1.0
Environment: xp, spring 2.0.6, jsf-1.2 ri
Reporter: Dan Tran
Priority: Blocker
Fix For: 1.0
the current orchestra fails to start my app with 2.4 container.
Please change the poms to use servlet 2.4 and add this changes
---
core/src/main/java/org/apache/myfaces/orchestra/requestParameterProvider/RequestParameterResponseWrapper.java
(revision 562289)
+++
core/src/main/java/org/apache/myfaces/orchestra/requestParameterProvider/RequestParameterResponseWrapper.java
(working copy)
@@ -187,7 +187,7 @@
{
this.original.setContentType(string);
}
-
+
public void setBufferSize(int i)
{
this.original.setBufferSize(i);
@@ -227,4 +227,18 @@
{
return this.original.getLocale();
}
+
+ public String getContentType()
+ {
+ return this.original.getContentType();
+ }
+
+ public void setCharacterEncoding( String encoding )
+ {
+ this.original.setCharacterEncoding(encoding);
+ }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (ORCHESTRA-4) Clean up build files
[ https://issues.apache.org/jira/browse/ORCHESTRA-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Kitching reopened ORCHESTRA-4: Reopening as requested in comments Clean up build files Key: ORCHESTRA-4 URL: https://issues.apache.org/jira/browse/ORCHESTRA-4 Project: MyFaces Orchestra Issue Type: Improvement Affects Versions: 1.0 Environment: xp Reporter: Dan Tran Assignee: Mario Ivankovits Attachments: ORCHESTRA-4-2.patch, ORCHESTRA-4-3.patch, ORCHESTRA-4.diff the pom files can be cleanup based on the following facts: - core15 depends on core, therefore lots of core15's dependencies can be removed. There is no need to unpack orchestra-share either - Repositories: remove iblio repo can be removed, maven already includes repo1.maven.org/maven2 use faster java.net maven repo. Refactor repository to the root pom - remove unnessesary unpacking of orchestra-share classes in core since we build it from source any way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (ORCHESTRA-15) Orchestra in Portal Environment
[ https://issues.apache.org/jira/browse/ORCHESTRA-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Kitching reopened ORCHESTRA-15: - Reopening as there are still portlet-related issues with orchestra and this issue has useful information. Orchestra in Portal Environment --- Key: ORCHESTRA-15 URL: https://issues.apache.org/jira/browse/ORCHESTRA-15 Project: MyFaces Orchestra Issue Type: Bug Affects Versions: 1.0 Environment: myfaces1.1.5, liferay portal4.3.3, orchestra-core1.0, tomcat 5.5 Reporter: Rashmi Assignee: Mario Ivankovits Priority: Blocker Fix For: 1.1 Attachments: orchestraPortlet.zip, stacktrace.txt In the portlet environment ConversationManager is not getting initialized. The FrameworkAdapter.getCurrentInstance() is as well NULL. The part of the exception is as follows: Caused by: java.lang.NullPointerException at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:90) at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:76) at org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.getBean(AbstractSpringOrchestraScope.java:125) at org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.get(AbstractSpringOrchestraScope.java:117) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160) at org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:33) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.getTarget(Cglib2AopProxy.java:661) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:611) at de.seat.mitarbeiterinfo.view.mitarbeiterlist$$EnhancerByCGLIB$$4f90561b.getMitarbeiterListModel(generated) ... 125 more The filter is not working as expected in Portlet environment but works perfetly well in norman Servlet container. Can myfaces-portlet-bridge be used in someway to configure the filter to run in portlet environment? Thanks and Regards, Rashmi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Time for an Orchestra 1.2 release?
Hi All, I'm about to start working on a new Orchestra feature (basic dialog support). It therefore seems a good idea to get an Orchestra release out before I start messing with the trunk. In particular, there are two bugs which are fixed in trunk and would be good to have in an official release: * ORCHESTRA-21 Issue with weird urls (esp. ones created by Trinidad) * ORCHESTRA-23 (locking bug, triggered by ajax or double-click) There are also a couple of minor enhancements, but not much has really happened since the 1.1 release. As always, there is more we *could* do; there are a couple of open bug issues. But none of them are simple to tackle, so I'd rather get 1.2 out now and tackle the other issues (esp. portlets) at some later time. I've created a release branch in svn, and taken out a few things that are not completely baked in trunk. The resulting code is binary compatible with 1.1 except in one minor case that I don't think we need to worry about. But see the RELEASE-NOTES.txt file for details. Unless there are any objections, I'll create an RC in the next few days. Cheers, Simon
RE: Time for an Orchestra 1.2 release?
Simon, How much work is required to support portlets in Orchestra? ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info phone: +1 203-653-2989 fax: +1 203-653-2988 JSFOne [http://www.jsfone.com] September 4th-6th in Washington, DC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2008 11:46 AM To: MyFaces Development Subject: Time for an Orchestra 1.2 release? Hi All, I'm about to start working on a new Orchestra feature (basic dialog support). It therefore seems a good idea to get an Orchestra release out before I start messing with the trunk. In particular, there are two bugs which are fixed in trunk and would be good to have in an official release: * ORCHESTRA-21 Issue with weird urls (esp. ones created by Trinidad) * ORCHESTRA-23 (locking bug, triggered by ajax or double-click) There are also a couple of minor enhancements, but not much has really happened since the 1.1 release. As always, there is more we *could* do; there are a couple of open bug issues. But none of them are simple to tackle, so I'd rather get 1.2 out now and tackle the other issues (esp. portlets) at some later time. I've created a release branch in svn, and taken out a few things that are not completely baked in trunk. The resulting code is binary compatible with 1.1 except in one minor case that I don't think we need to worry about. But see the RELEASE-NOTES.txt file for details. Unless there are any objections, I'll create an RC in the next few days. Cheers, Simon
Re: Time for an Orchestra 1.2 release?
Hello Simon, On Tue, Jun 24, 2008 at 8:45 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi All, I'm about to start working on a new Orchestra feature (basic dialog support). It therefore seems a good idea to get an Orchestra release out before I start messing with the trunk. In particular, there are two bugs which are fixed in trunk and would be good to have in an official release: * ORCHESTRA-21 Issue with weird urls (esp. ones created by Trinidad) * ORCHESTRA-23 (locking bug, triggered by ajax or double-click) +1 There are also a couple of minor enhancements, but not much has really happened since the 1.1 release. As always, there is more we *could* do; there are a couple of open bug issues. But none of them are simple to tackle, so I'd rather get 1.2 out now and tackle the other issues (esp. portlets) at some later time. I've created a release branch in svn, and taken out a few things that are not completely baked in trunk. The resulting code is binary compatible with 1.1 except in one minor case that I don't think we need to worry about. But see the RELEASE-NOTES.txt file for details. Unless there are any objections, I'll create an RC in the next few days. sounds good to me! Greetings, Matthias Cheers, Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: svn commit: r671015 - in /myfaces/tomahawk/trunk: core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java examples/simple/src/main/webapp/aliasBean.jsp
Hi
Alias property only receive el expression. There was a mistake on a commit
the example page, which was reverted (sorry!). Alias never receive string
only values. The change applied throws an expression when alias=someString
instead alias=#{somebean}. Previously other non descriptive error is
thrown when alias=someString
regards
Leonardo Uribe
On Tue, Jun 24, 2008 at 1:50 AM, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Doesn't this change break backward compatibility completley?
The value of the alias= attribute now has to be defined differently,
instead of the el-expressesion just the name needs to be set.
Even if this change is logical to me, a new tomahawk release will break any
existing application using the aliasBean, no?
If so, I think this patch needs to be reverted unless we are going to
release a new major version of tomahawk.
Ciao,
Mario
[EMAIL PROTECTED] schrieb:
Author: lu4242
Date: Mon Jun 23 21:22:49 2008
New Revision: 671015
URL: http://svn.apache.org/viewvc?rev=671015view=rev
Log:
TOMAHAWK-790 Aliasbean warning/error when no EL expression in the alias
property
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java?rev=671015r1=671014r2=671015view=diff
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
Mon Jun 23 21:22:49 2008
@@ -47,7 +47,7 @@
protected void setProperties(UIComponent component) {
super.setProperties(component);
-setStringProperty(component, alias, _alias);
+setValueBinding(component, alias, _alias);
setStringProperty(component, value, _valueExpression);
}
Modified:
myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp?rev=671015r1=671014r2=671015view=diff
==
--- myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp
(original)
+++ myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp
Mon Jun 23 21:22:49 2008
@@ -45,7 +45,7 @@
h:form
h2aliasTest1/h2
-t:aliasBean alias=#{holder} value=#{aliasTest1}
+t:aliasBean alias=holder value=#{aliasTest1}
f:subview id=simulatedIncludedSubform1
%-- The next tags could be inserted by an %@ include or
jsp:include --%
h:outputLabel for=name value=Name :/
[jira] Commented: (MYFACES-1838) javax.crypto.BadPaddingException: Given final block not properly padded
[ https://issues.apache.org/jira/browse/MYFACES-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607688#action_12607688 ] Greg Lloyd commented on MYFACES-1838: - Is there any work around for this, maybe by disabling the encryption of the state etc? javax.crypto.BadPaddingException: Given final block not properly padded --- Key: MYFACES-1838 URL: https://issues.apache.org/jira/browse/MYFACES-1838 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.2 Reporter: Guy Bashan I keep getting this exception from time to time when moving between pages: javax.faces.FacesException: javax.crypto.BadPaddingException: Given final block not properly padded at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:373) at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:411) at org.apache.myfaces.shared_impl.util.StateUtils.decrypt(StateUtils.java:291) at org.apache.myfaces.shared_impl.util.StateUtils.reconstruct(StateUtils.java:240) at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getSavedState(HtmlResponseStateManager.java:184) at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getState(HtmlResponseStateManager.java:136) at org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:289) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:505) at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:85) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:148) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.vdo.admin.model.persistence.OpenSessionInViewFilterIC.doFilterInternal(OpenSessionInViewFilterIC.java:155) at com.vdo.admin.model.persistence.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:61) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147) 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:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) Caused by: javax.crypto.BadPaddingException: Given final block not properly padded at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..) at javax.crypto.Cipher.doFinal(DashoA13*..) at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:369) ... 30 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-1493) h:selectOneMenu should resolve non-string objects in the value property without a converter
[ https://issues.apache.org/jira/browse/MYFACES-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606998#action_12606998 ] keywan edited comment on MYFACES-1493 at 6/24/08 11:26 AM: --- i am sure thats a real bug, and should be solved imidiately. i analized and soleved the Problem. The value of the selectitem is should not need to be a string. A converter should not be needed for the value. I do not interprate the specification this way. I hope many people will vote for this issue. The renderer trys to use the value in the select items to render the value of the option tags - which is wrong! The values of the selectitems should stay on the server side. On client wie only need a way to reference the values. So what my renderer does is, it simply use numbers for rendering the value of the option tag, and that works grate. I like to share my render with u, that aceppt all all objets in the selectItem value. but its only testet for selectOneMenu. in the facesconfig i registered my renderer like this: render-kit renderer descriptionRenderer accepting objekts as value for select itmes/description component-familyjavax.faces.SelectOne/component-family renderer-typejavax.faces.Menu/renderer-type renderer-classjsf.MenuRenderer/renderer-class /renderer /render-kit I would be very glad if somone agree with me, test the render and give me some feedback. For me and my current Projekt its working fine, but in fact we only override the render for h:selectOneMenu, so i can fall back to t:selectOneMenu to get the old behavior. Don't hasitate to contact me. The render is attached. The reason i did not provide a real svn patch is, that it was not posible for me. i mixed up code from the util classes to get everthing work. so to make it good changes on the utilclasses would have made, and that could lead to sideeffects. Only somone who is verry familar with the code, can say which changes have to make at which file to avoid sideeffects. was (Author: keywan): i analized and soleved the Problem. The renderer trys to use the value in the select items to render the value of the option tags - which is wrong! Because the value of the selectitem is not need to be a string. Some people mean u just need a converter but that is not what the jsf spec says. So what we need is a renderer that simply use numbers for the value of the option tag. If like t share my render with u, that aceppt all all objets in the selectItem value. it only testet for selectOneMenu. You can find the current code on my german blog: http://art-of-software-engineering.blogspot.com/2008/06/selectonemenu-und-die.html in the facesconfig i registered my renderer: render-kit renderer descriptionRenderer accepting objekts as value for select itmes/description component-familyjavax.faces.SelectOne/component-family renderer-typejavax.faces.Menu/renderer-type renderer-classjsf.MenuRenderer/renderer-class /renderer /render-kit Here the comes the render. it would be nice if some on could provide a real patch(svn diff) so the pain will be gone in the next version of myfaces, ;-) i changed, and mixed up so much code, that i am not quit sure how to provied a good patch: package jsf; import java.io.IOException; import java.util.Arrays; import java.util.Iterator; import java.util.List; import javax.faces.component.UIComponent; import javax.faces.component.UISelectMany; import javax.faces.component.UISelectOne; import javax.faces.component.html.HtmlSelectManyMenu; import javax.faces.component.html.HtmlSelectOneMenu; import javax.faces.context.FacesContext; import javax.faces.context.ResponseWriter; import javax.faces.convert.Converter; import javax.faces.convert.ConverterException; import javax.faces.model.SelectItem; import javax.faces.model.SelectItemGroup; import org.apache.myfaces.shared_impl.component.EscapeCapable; import org.apache.myfaces.shared_impl.renderkit.JSFAttr; import org.apache.myfaces.shared_impl.renderkit.RendererUtils; import org.apache.myfaces.shared_impl.renderkit.html.HTML; import org.apache.myfaces.shared_impl.renderkit.html.HtmlRenderer; import org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils; /* * Licensed to the Apache Software Foundation (ASF) under one * or more contributor license agreements. See the NOTICE file * distributed with this work for additional information * regarding copyright ownership. The ASF licenses this file * to you under the Apache License, Version 2.0 (the * License); you may not use this file except in compliance * with the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, * software distributed under the License is distributed on an * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY * KIND, either
[jira] Commented: (TRINIDAD-1134) XmlMenuModel: action is interpreted as ValueExpression
[
https://issues.apache.org/jira/browse/TRINIDAD-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607730#action_12607730
]
Gary Kind commented on TRINIDAD-1134:
-
The action attribute, as per the spec, is supposed to contain an navigation
case outcome. Therefore, whatever you put in as its value should evaluate to
an outcome. Workaround would be to have your bean return a navigation outcome
string.
XmlMenuModel: action is interpreted as ValueExpression
--
Key: TRINIDAD-1134
URL: https://issues.apache.org/jira/browse/TRINIDAD-1134
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Stephen Friedrich
An action set on an ItemNode is evaluated as a value expression.
Workround is to have a getter instead of an action-method-signature in the
backing bean:
public String getDoIt()
for an itemNode like this:
itemNode id=companies action=#{_companyList.doIt}
label=#{Output.COMPANIES} ...
See
http://www.nabble.com/-Trinidad--Bug-in-XMLMenuModel---ItemNode---tt12376683.html#a12376683
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[VOTE] Upgrade sandbox converters and validators to tomahawk
Hi The following converters and validators are proposed to be moven from sandbox to tomahawk core: s:convertBoolean s:convertDateTime s:convertNumber s:validateCompareTo s:validateCSV s:validateISBN s:validateUrl In tomahawk core, the related files should be moved from sandbox/core to core. In tomahawk core12, a new dependency to myfaces-commons-converters 1.2.x and myfaces-commons-validators 1.2.x should be added, so the tomahawk core12 tld reference validators and converters from these projects. This introduce a change because the validatorId and converterId for this components changes (because this converters are defined on myfaces-commons) only on core12. If you want to see this change on tomahawk please vote. This was discussed positively before, but the times change and better to know what people think about it. Suggestions are welcome! regards Leonardo Uribe
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
+1 On Tue, Jun 24, 2008 at 2:45 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi The following converters and validators are proposed to be moven from sandbox to tomahawk core: s:convertBoolean s:convertDateTime s:convertNumber s:validateCompareTo s:validateCSV s:validateISBN s:validateUrl In tomahawk core, the related files should be moved from sandbox/core to core. In tomahawk core12, a new dependency to myfaces-commons-converters 1.2.x and myfaces-commons-validators 1.2.x should be added, so the tomahawk core12 tld reference validators and converters from these projects. This introduce a change because the validatorId and converterId for this components changes (because this converters are defined on myfaces-commons) only on core12. If you want to see this change on tomahawk please vote. This was discussed positively before, but the times change and better to know what people think about it. Suggestions are welcome! regards Leonardo Uribe
RE: Time for an Orchestra 1.2 release?
+1, we are waiting for this release, rather cutting our own release to pick up 2 mentioned bugs -D kito99 wrote: Simon, How much work is required to support portlets in Orchestra? ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info phone: +1 203-653-2989 fax: +1 203-653-2988 JSFOne [http://www.jsfone.com] September 4th-6th in Washington, DC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2008 11:46 AM To: MyFaces Development Subject: Time for an Orchestra 1.2 release? Hi All, I'm about to start working on a new Orchestra feature (basic dialog support). It therefore seems a good idea to get an Orchestra release out before I start messing with the trunk. In particular, there are two bugs which are fixed in trunk and would be good to have in an official release: * ORCHESTRA-21 Issue with weird urls (esp. ones created by Trinidad) * ORCHESTRA-23 (locking bug, triggered by ajax or double-click) There are also a couple of minor enhancements, but not much has really happened since the 1.1 release. As always, there is more we *could* do; there are a couple of open bug issues. But none of them are simple to tackle, so I'd rather get 1.2 out now and tackle the other issues (esp. portlets) at some later time. I've created a release branch in svn, and taken out a few things that are not completely baked in trunk. The resulting code is binary compatible with 1.1 except in one minor case that I don't think we need to worry about. But see the RELEASE-NOTES.txt file for details. Unless there are any objections, I'll create an RC in the next few days. Cheers, Simon -- View this message in context: http://www.nabble.com/Time-for-an-Orchestra-1.2-release--tp18093892p18098536.html Sent from the My Faces - Dev mailing list archive at Nabble.com.
CAPTCHA
Can someone help me figure out where the CAPTCHA tag disappeared to? I've tried tomahawk and sandbox latest builds and it's not in either. Thanks. Mike
Re: CAPTCHA
This component was upgraded from sandbox to tomahawk. On the latest code is here. regards Leonardo Uribe On Tue, Jun 24, 2008 at 2:52 PM, Michael Angelo [EMAIL PROTECTED] wrote: Can someone help me figure out where the CAPTCHA tag disappeared to? I've tried tomahawk and sandbox latest builds and it's not in either. Thanks. Mike
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Hi, converters should go into commons not into tomahawk. Why is this only planed for the 1.2 branch? Regards, Volker 2008/6/24 Leonardo Uribe [EMAIL PROTECTED]: Hi The following converters and validators are proposed to be moven from sandbox to tomahawk core: s:convertBoolean s:convertDateTime s:convertNumber s:validateCompareTo s:validateCSV s:validateISBN s:validateUrl In tomahawk core, the related files should be moved from sandbox/core to core. In tomahawk core12, a new dependency to myfaces-commons-converters 1.2.x and myfaces-commons-validators 1.2.x should be added, so the tomahawk core12 tld reference validators and converters from these projects. This introduce a change because the validatorId and converterId for this components changes (because this converters are defined on myfaces-commons) only on core12. If you want to see this change on tomahawk please vote. This was discussed positively before, but the times change and better to know what people think about it. Suggestions are welcome! regards Leonardo Uribe -- inexso - information exchange solutions GmbH Bismarckstraße 13 | 26122 Oldenburg Tel.: +49 441 4082 356 | FAX: +49 441 4082 355 | www.inexso.de
[jira] Updated: (MYFACES-1879) Problems with myfaces when java2 security is enabled
[
https://issues.apache.org/jira/browse/MYFACES-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Concini updated MYFACES-1879:
-
Status: Patch Available (was: Open)
Problems with myfaces when java2 security is enabled
Key: MYFACES-1879
URL: https://issues.apache.org/jira/browse/MYFACES-1879
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.3
Reporter: Michael Concini
When running MyFaces 1.2 on an application server with java2 security turned
on, a user can receive an AccessControlException from several locations
within the code, in some cases preventing the application from working in the
environment.
There are several places in the myfaces code that should be updated to
include a doPriv when java2 security is on. Specifically in locations where
the code is executing a call to
Thread.currentThread().getContextClassLoader(), as well as in the
JspStateManagerImpl's deserializeView() method.
for example (in the classloader case):
if (System.getSecurityManager() != null) {
try {
Object cl = AccessController.doPrivileged(new
PrivilegedExceptionAction() {
public Object run() throws
PrivilegedActionException {
return
Thread.currentThread().getContextClassLoader();
}
});
return (ClassLoader) cl;
} catch (PrivilegedActionException pae) {
throw new FacesException(pae);
}
}else{
return Thread.currentThread().getContextClassLoader();
}
If its agreed that the change should be implemented, I'd be happy to perform
the changes myself and supply a patch. I also thought that it might make
sense to, at least for the ClassLoader lookup, create a method in ClassUtils
called getContextClassloader that could be called elsewhere for efficiency's
sake.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1283) dataScroller encounters javascript error and stops working when including tomahawk-sandbox jar
[
https://issues.apache.org/jira/browse/TOMAHAWK-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607749#action_12607749
]
Leonardo Uribe commented on TOMAHAWK-1283:
--
Thanks for the zipped test, it helps a lot.
I have tried the problem and it seems to be related to the myfaces api and impl
version you are using (1.1.3).
With myfaces core 1.1.5 no errors found using tomahawk 1.1.6
With tomahawk-1.1.7-SNAPSHOT it is necessary to define the extensions filter or
disable the check for this configuration. Again no errors found, but we have to
do some enhancements to the hierarchy of HtmlDataScroller (inherit from UIPanel
instead ext.HtmlPanelGroup).
Try with myfaces core 1.1.5 and let us know what happen, so we can close this
issue as invalid.
Thanks for your help.
dataScroller encounters javascript error and stops working when including
tomahawk-sandbox jar
--
Key: TOMAHAWK-1283
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1283
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Data Scroller
Affects Versions: 1.1.6
Environment: Windows XP
Tomcat 5.5
Reporter: Christina Sickelco
Assignee: Hazem Saleh
Attachments: JSFSandbox.zip
I have a simple dataTable and dataScroller, which works fine, until I include
the tomahawk-sandbox-1.1.6.jar or tomahawk-sandbox-1.1.6-SNAPSHOT or
tomahawk-sandbox-1.1.7-SNAPSHOT jars. As soon as I include one of those,
clicking on the different page numbers in the datascroller stops working and
I see the following javascript error:
Error: document.forms._idJsp0.elements['_idJsp0:scrollerForNamesTable'] has
no properties
Source File: http://localhost:8080/JSFSandbox/test.faces
Line: 1
The tomahawk-sandbox-1.1.6.jar was downloaded from
http://repo1.maven.org/maven2/org/apache/myfaces/tomahawk/tomahawk-sandbox/.
The snapshot jars were downloaded from:
http://people.apache.org/maven-snapshot-repository/org/apache/myfaces/tomahawk/tomahawk-sandbox/
Here is what my JSP page looks like:
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f %
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h %
%@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t%
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
html
head
titleTest Program/title
meta http-equiv=pragma content=no-cache
meta http-equiv=cache-control content=no-cache
meta http-equiv=expires content=0
/head
body
f:view
h:form
h:panelGrid columns=1
t:dataTable
id=namesTable
forceId=true
value=#{testBean.names}
var=nameBean
preserveDataModel=false
rowClasses=oddTableRow,evenTableRow
varDetailToggler=detailToggler
preserveSort=true
renderedIfEmpty=false
rows=2
t:column defaultSorted=true
sortable=true
f:facet name=header
h:outputText
value=Name style=font-size:10pt;/
/f:facet
h:outputText
style=width:8em;text-align:left;
value=#{nameBean.name}/
/t:column
/t:dataTable
/h:panelGrid
%-- Pager --%
h:panelGroup
style=background-color:#c2c1a3;width=100%;text-align:center;
t:dataScroller
id=scrollerForNamesTable
for=namesTable
fastStep=1
pageCountVar=pageCount
pageIndexVar=pageIndex
styleClass=scroller
paginator=true
paginatorMaxPages=9
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
On Tue, Jun 24, 2008 at 3:05 PM, Volker Weber [EMAIL PROTECTED] wrote: Hi, converters should go into commons not into tomahawk. Why is this only planed for the 1.2 branch? That is the hidden reason why I request a vote for this. All validators and converters should be on myfaces-commons. Almost all comes from tomahawk or sandbox (EnumConverter and DateRestrictValidator available only on commons). Tomahawk has some validators defined on core: t:validateCreditCard t:validateEmail t:validateEqual t:validateRegExpr This validators right now are defined on myfaces-commons. One question is if tomahawk core12 should have validators or converters defined on its tld(but use the commons jar code), since the plan is that all validators and converters should be on myfaces-commons. Other question after answer the first is what should happen on core branch: deprecate the actual defined validators and remove it from core12, but where should be the sandbox converters and validators? or maybe define it on commons jsf11 branch, move all validators and converters from tomahawk and release a myfaces-commons- 1.1.0? . This is why before I proposed a discussion a vote about myfaces-commons layout. There are many alternatives we can do on this topic, but we need to be precise about what to do. The only thing clear is that myfaces commons jsf11 branch should be used for backports only. The vote proposed is my humble opinion about what to do, but if there are better ideas about what to do is the right time to say it. Suggestions are welcome regards Leonardo Uribe Regards, Volker 2008/6/24 Leonardo Uribe [EMAIL PROTECTED]: Hi The following converters and validators are proposed to be moven from sandbox to tomahawk core: s:convertBoolean s:convertDateTime s:convertNumber s:validateCompareTo s:validateCSV s:validateISBN s:validateUrl In tomahawk core, the related files should be moved from sandbox/core to core. In tomahawk core12, a new dependency to myfaces-commons-converters 1.2.x and myfaces-commons-validators 1.2.x should be added, so the tomahawk core12 tld reference validators and converters from these projects. This introduce a change because the validatorId and converterId for this components changes (because this converters are defined on myfaces-commons) only on core12. If you want to see this change on tomahawk please vote. This was discussed positively before, but the times change and better to know what people think about it. Suggestions are welcome! regards Leonardo Uribe -- inexso - information exchange solutions GmbH Bismarckstraße 13 | 26122 Oldenburg Tel.: +49 441 4082 356 | FAX: +49 441 4082 355 | www.inexso.de
[jira] Updated: (ORCHESTRA-17) RequestParameterFacesContextFactory only works with HttpServletResponse
[
https://issues.apache.org/jira/browse/ORCHESTRA-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Huemer updated ORCHESTRA-17:
-
Status: Patch Available (was: Reopened)
RequestParameterFacesContextFactory only works with HttpServletResponse
---
Key: ORCHESTRA-17
URL: https://issues.apache.org/jira/browse/ORCHESTRA-17
Project: MyFaces Orchestra
Issue Type: Bug
Components: RequestParameterProvider
Affects Versions: 1.0, 1.1
Environment: Liferay Portlet Container
Reporter: Martin Marinschek
The following snippet wrongly casts to HttpServletResponse, therefore
portlet-environments will not work:
if (response instanceof HttpServletResponse)
{
HttpServletRequest httpServletRequest = (HttpServletRequest)
request;
// Wrap this request only if something else (eg a
RequestParameterServletFilter) has not already wrapped it.
if
(!Boolean.TRUE.equals(httpServletRequest.getAttribute(RequestParameterServletFilter.REQUEST_PARAM_FILTER_CALLED)))
{
I will commit a solution very soon.
regards,
Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-17) RequestParameterFacesContextFactory only works with HttpServletResponse
[
https://issues.apache.org/jira/browse/ORCHESTRA-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607762#action_12607762
]
Bernhard Huemer commented on ORCHESTRA-17:
--
I've created a patch that is similiar to the one Martin has provided a while
ago but I've extended it a little bit as it is unlike the previous version now
compatible with both JSF 1.1 and JSF 1.2 (thanks to a small hack). Even
though I could commit it myself I'd like someone else to review it (Simon or
Mario?). I've already tested it with Apache Pluto and the JSR-301 Portlet
Bridge.
RequestParameterFacesContextFactory only works with HttpServletResponse
---
Key: ORCHESTRA-17
URL: https://issues.apache.org/jira/browse/ORCHESTRA-17
Project: MyFaces Orchestra
Issue Type: Bug
Components: RequestParameterProvider
Affects Versions: 1.0, 1.1
Environment: Liferay Portlet Container
Reporter: Martin Marinschek
Attachments: ORCHESTRA-17.patch
The following snippet wrongly casts to HttpServletResponse, therefore
portlet-environments will not work:
if (response instanceof HttpServletResponse)
{
HttpServletRequest httpServletRequest = (HttpServletRequest)
request;
// Wrap this request only if something else (eg a
RequestParameterServletFilter) has not already wrapped it.
if
(!Boolean.TRUE.equals(httpServletRequest.getAttribute(RequestParameterServletFilter.REQUEST_PARAM_FILTER_CALLED)))
{
I will commit a solution very soon.
regards,
Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1289) HtmlDataScroller should inherit UIPanel instead HtmlPanelGroup
HtmlDataScroller should inherit UIPanel instead HtmlPanelGroup -- Key: TOMAHAWK-1289 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1289 Project: MyFaces Tomahawk Issue Type: Bug Components: Data Scroller Reporter: Leonardo Uribe Assignee: Leonardo Uribe dataScroller has this definitions: * @JSFJspProperty name = onkeydown tagExcluded = true * @JSFJspProperty name = onkeypress tagExcluded = true * @JSFJspProperty name = onkeyup tagExcluded = true * @JSFJspProperty name = onmousedown tagExcluded = true * @JSFJspProperty name = onmousemove tagExcluded = true * @JSFJspProperty name = onmouseout tagExcluded = true * @JSFJspProperty name = onmouseover tagExcluded = true * @JSFJspProperty name = onmouseup tagExcluded = true suggesting that this component should not inherit from HtmlPanelGroup (here are defined this properties). It is more OO friendly to extends from UIPanel, remove the previous annotations and add the missing properties annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
CAPTCHA Missing
I downloaded tomahawk 1.1.6 and 1.1.7 today. I looked in the TLD and added to my build path in MyEclipse. The code assist shows all t: tags and CAPTCHA is not there.
[jira] Commented: (TOMAHAWK-1014) HTMLInputDate ignores custom converters
[ https://issues.apache.org/jira/browse/TOMAHAWK-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607783#action_12607783 ] Leonardo Uribe commented on TOMAHAWK-1014: -- Allow define custom converter on inputDate requires rewrite some parts of the component (specially its decode method, and all related to UserData inner class and usage). Maybe it's better to let is as open and try to rewrite its code when we have some free time. (My priority right now is clean the issue stack of tomahawk solving as many issues as I can, so we can do a good release). HTMLInputDate ignores custom converters --- Key: TOMAHAWK-1014 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1014 Project: MyFaces Tomahawk Issue Type: Bug Components: Date Affects Versions: 1.1.5 Reporter: Steven Gollery Assignee: Leonardo Uribe Fix For: 1.1.7-SNAPSHOT Setting a custom converter on HTMLInputDate fails. HTMLDateRenderer.getConvertedValue does not use the converter from the component, but instead uses UserData.parse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-887) Duplicate Client-Id
[ https://issues.apache.org/jira/browse/TOMAHAWK-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607792#action_12607792 ] Leonardo Uribe commented on TOMAHAWK-887: - I cannot reproduce this error. Is this still valid? Duplicate Client-Id --- Key: TOMAHAWK-887 URL: https://issues.apache.org/jira/browse/TOMAHAWK-887 Project: MyFaces Tomahawk Issue Type: Bug Components: Data Scroller Affects Versions: 1.1.5-SNAPSHOT Reporter: nikolaos georgosoulos Attachments: HtmlDataScrollerRenderer.java The datascroller component returns the following error when it is part of a portlet in page and the user leaves the page and returns. The 1.1.5 snapshot is being used so the datascroller works fine as long as the user stays in the portal page with the scroller. When user leaves the page and returns back to it the error occurs. As portal Jetspeed 2 is being used. the Tomahawk bridge is used for bridging portal and portlet of JSF that extend the MyFacesGenericPortlet class without any real implementation (just super.doView()). Myfaces implementation is 1.1.4. Myfaces impl 1.1.5 does not cooperate well with Tomahawk bridge (bufferedStream errors) and the portals-bridge-jsf simply discards any passed parameters from the processAction to the renderPage phases. I only mention these in order to prove there is none known alternative. javax.portlet.PortletException at jp.sf.pal.facesresponse.FacesResponseFilter.renderFilter(FacesResponseFilter.java:81) at org.apache.portals.bridges.portletfilter.PortletFilterChain.renderFilter(PortletFilterChain.java:114) at org.apache.portals.bridges.portletfilter.FilterPortlet.render(FilterPortlet.java:141) at org.apache.jetspeed.factory.JetspeedPortletInstance.render(JetspeedPortletInstance.java:102) at org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:230) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510) at org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:213) at org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:125) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119) at org.apache.jetspeed.container.JetspeedPortletContainerWrapper.renderPortlet(JetspeedPortletContainerWrapper.java:120) at org.apache.jetspeed.aggregator.impl.RenderingJobImpl.execute(RenderingJobImpl.java:120) at org.apache.jetspeed.aggregator.impl.PortletRendererImpl.renderNow(PortletRendererImpl.java:110) at org.apache.jetspeed.aggregator.impl.PageAggregatorImpl.aggregateAndRender(PageAggregatorImpl.java:199) at org.apache.jetspeed.aggregator.impl.PageAggregatorImpl.aggregateAndRender(PageAggregatorImpl.java:182) at org.apache.jetspeed.aggregator.impl.PageAggregatorImpl.build(PageAggregatorImpl.java:106) at org.apache.jetspeed.aggregator.AggregatorValve.invoke(AggregatorValve.java:48) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:203) at org.apache.jetspeed.pipeline.valve.impl.ActionValveImpl.invoke(ActionValveImpl.java:132) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:203) at org.apache.jetspeed.container.ContainerValve.invoke(ContainerValve.java:76) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:203) at org.apache.jetspeed.decoration.DecorationValve.invoke(DecorationValve.java:100) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:203) at org.apache.jetspeed.profiler.impl.ProfilerValveImpl.invoke(ProfilerValveImpl.java:179) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:203) at org.apache.jetspeed.security.impl.LoginValidationValveImpl.invoke(LoginValidationValveImpl.java:143) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:203) at
[jira] Commented: (TOMAHAWK-1180) Datascroller not rendering links correctly when javascript-detection on
[ https://issues.apache.org/jira/browse/TOMAHAWK-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607797#action_12607797 ] Leonardo Uribe commented on TOMAHAWK-1180: -- h:commandLink or t:commandLink requires javascript to work, so t:dataScroller works only if javascript is enabled. There is a discussion about how to enhance commandLink (see MYFACES-1692) only if MYFACES-1692 is solved, this issue could be solved. Datascroller not rendering links correctly when javascript-detection on --- Key: TOMAHAWK-1180 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1180 Project: MyFaces Tomahawk Issue Type: Bug Components: Data Scroller Affects Versions: 1.1.6 Reporter: HARSHNA PATEL Assignee: Hazem Saleh When javascript-detect is set to true in the web.xml and javascript disabled in the browser - the links rendered in the datascroller do not work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
CAPTCHA missing!
You are obviously a busy man and I hate to keep bugging you with this. If I am wrong I am going to feel like an idiot. I cannot find CAPTCHA in either of the libraries (sandbox or tomahawk). Please help!! I really need this tonight! Thanks a lot!!
Re: CAPTCHA missing!
Please look at: http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/tomahawk/tomahawk/1.1.7-SNAPSHOT/tomahawk-1.1.7-SNAPSHOT.jar checking the file META-INF/tomahawk.tld captcha is here regards Leonardo Uribe On Tue, Jun 24, 2008 at 7:16 PM, Michael Angelo [EMAIL PROTECTED] wrote: You are obviously a busy man and I hate to keep bugging you with this. If I am wrong I am going to feel like an idiot. I cannot find CAPTCHA in either of the libraries (sandbox or tomahawk). Please help!! I really need this tonight! Thanks a lot!!
CAPTCHA missing
The location that you provided for me did in fact download a version of the jar file that had CAPTCHA. The tomahawk.tld date/time stamp in that .jar file is 6/18/2008. The date/time stamp from the one I downloaded from the link below is 1/8/2008. http://people.apache.org/builds/myfaces/nightly/tomahawk-1.1.7-SNAPSHOT-bin.zip Where is the version that you sent to me located? It's not the same as the nightly build link from myfaces.apache.org. Thanks
Re: CAPTCHA missing
Why not doing a check out of the source? If it is that urgent, that should be ok to try.. -M On Tue, Jun 24, 2008 at 7:11 PM, Michael Angelo [EMAIL PROTECTED] wrote: The location that you provided for me did in fact download a version of the jar file that had CAPTCHA. The tomahawk.tld date/time stamp in that .jar file is 6/18/2008. The date/time stamp from the one I downloaded from the link below is 1/8/2008. http://people.apache.org/builds/myfaces/nightly/tomahawk-1.1.7-SNAPSHOT-bin.zip Where is the version that you sent to me located? It's not the same as the nightly build link from myfaces.apache.org. Thanks -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
On Tue, Jun 24, 2008 at 1:52 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 3:05 PM, Volker Weber [EMAIL PROTECTED] wrote: Hi, converters should go into commons not into tomahawk. +1 Why is this only planed for the 1.2 branch? That is the hidden reason why I request a vote for this. All validators and converters should be on myfaces-commons. Almost all comes from tomahawk or sandbox (EnumConverter and DateRestrictValidator available only on commons). Tomahawk has some validators defined on core: t:validateCreditCard t:validateEmail t:validateEqual t:validateRegExpr let's move them over... This validators right now are defined on myfaces-commons. One question is if tomahawk core12 should have validators or converters defined on its tld(but use the commons jar code), since the plan is that all validators and converters should be on myfaces-commons. why not ? Just make it a RT dependency, and we are fine. Other question after answer the first is what should happen on core branch: deprecate the actual defined validators and remove it from core12, but where should be the sandbox converters and validators? or maybe define it on commons jsf11 branch, move all validators and converters from tomahawk and release a myfaces-commons- 1.1.0? . This is why before I proposed a discussion a vote about myfaces-commons layout. There are many alternatives we can do on this topic, but we need to be precise about what to do. The only thing clear is that myfaces commons jsf11 branch should be used for backports only. well, if folks like to add stuff, why not? The vote proposed is my humble opinion about what to do, but if there are better ideas about what to do is the right time to say it. Suggestions are welcome seriously, we are adding more and more and more to myfaces... it get's kinda jakarta like. It's hard to keep track of all the things. bad signal ? -Matthias regards Leonardo Uribe Regards, Volker 2008/6/24 Leonardo Uribe [EMAIL PROTECTED]: Hi The following converters and validators are proposed to be moven from sandbox to tomahawk core: s:convertBoolean s:convertDateTime s:convertNumber s:validateCompareTo s:validateCSV s:validateISBN s:validateUrl In tomahawk core, the related files should be moved from sandbox/core to core. In tomahawk core12, a new dependency to myfaces-commons-converters 1.2.x and myfaces-commons-validators 1.2.x should be added, so the tomahawk core12 tld reference validators and converters from these projects. This introduce a change because the validatorId and converterId for this components changes (because this converters are defined on myfaces-commons) only on core12. If you want to see this change on tomahawk please vote. This was discussed positively before, but the times change and better to know what people think about it. Suggestions are welcome! regards Leonardo Uribe -- inexso - information exchange solutions GmbH Bismarckstraße 13 | 26122 Oldenburg Tel.: +49 441 4082 356 | FAX: +49 441 4082 355 | www.inexso.de -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Commented: (TOMAHAWK-922) JSF-1.2: JspTilesViewHandlerImpl
[ https://issues.apache.org/jira/browse/TOMAHAWK-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607842#action_12607842 ] Leonardo Uribe commented on TOMAHAWK-922: - I have committed on core12 the changes suggested for JspTilesTwoViewHandlerImpl. The problem with this handler is the changes done in ViewHandler interface between 1.1 and 1.2. This code unfortunately does not work with jsf ri 1.2, because not everything could be delegated (renderTilesView). I have tested myfaces-example-tiles example inside tomahawk examples module, using the following command mvn -Djsf=12 -Dtomahawk=12 clean jetty:run and the proposed solution works well. This works with myfaces 1.2.4-SNAPSHOT (latest code) and tomahawk12 1.1.7-SNAPSHOT (latest code) suggestions, patches, updates and everything you want to contribute are welcome! JSF-1.2: JspTilesViewHandlerImpl Key: TOMAHAWK-922 URL: https://issues.apache.org/jira/browse/TOMAHAWK-922 Project: MyFaces Tomahawk Issue Type: Bug Components: Tiles Affects Versions: 1.1.5-SNAPSHOT Environment: MyFaces Tomahawk SVN HEAD + JSF-1.2_03 (Reference implementation) + JDK-1.5.0_11 + Tomcat-6.0.10 Reporter: Jesper Pedersen The JspTilesViewHandlerImpl doesn't work under JSF-1.2 (RI) as it doesn't deliver any output. Steps: 1) Get myfaces-example-tiles-1.1.5-SNAPSHOT.war 2) Replace MyFaces-Core with JSF-1.2 (RI) in WEB-INF/lib 3) Deploy on Tomcat-6.0.10 4) Go to http://localhost:8080/myfaces-example-tiles-1.1.5-SNAPSHOT/ Generated HTML: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN head meta http-equiv=Content-Type content=text/html;CHARSET=iso-8859-1 / titleMyfaces - Tiles/title link rel=stylesheet type=text/css href=css/tiles.css / /head /html Basically I'm unable to use Tomahawk under JSF-1.2 currently, so any pointers on how to fix this issue or to provide more information would be great. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1129) Server-side validation does not work when using Sun JSF implementation
[ https://issues.apache.org/jira/browse/TRINIDAD-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved TRINIDAD-1129. -- Resolution: Fixed Server-side validation does not work when using Sun JSF implementation -- Key: TRINIDAD-1129 URL: https://issues.apache.org/jira/browse/TRINIDAD-1129 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.8-core Reporter: Stephen Friedrich Assignee: Matthias Weßendorf Fix For: 1.0.9-core, 1.2.9-core Attachments: test.war tr:validateLength (and very probably other Trinidad validator also) do not validate anything on the server side at all. Trinidad's org.apache.myfaces.trinidad.validator.LengthValidator is a subclass of javax.faces.validator.LengthValidator. Trinidad's validate() method first delegates to the super class and if no validation exception occurs there, it does nothing. However the JSF base class never validates anything because the minimum and maximum fields do not have their values restored. It seems that the Trinidad way of handling state saving conflicts with mojarra's expectations. (Using mojarra 1.2_08) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
