Re: tomahawk/src/test has dependencies on MyFaces Impl
For properly testing against both APIs and IMPLs, we'd need to have the RI be 1) maven2-nized 2) with a compatible license. Now, license issues have been resolved for most of the licenses we deal with. Was the CDDL amongst the libraries we may deliver binaries with? I do believe so... regards, Martin On 3/20/06, Craig McClanahan [EMAIL PROTECTED] wrote: (Coming back from London after a couple of days out of touch, so this might be old news, but ...) On 3/17/06, Dennis Byrne [EMAIL PROTECTED] wrote: One -- you're actually limiting or biasing the test coverage for this particular test because you're testing against a particular implementation rather than a more abstract mock object. Yes, this is an argument that is as old as QA itself ;) And it would be exactly the same if the tests were using a MyFaces-specific mock object :-). The point is that you *cannot* test the behavior of many JSF related objects without more than a pure abstract implementation of the mock objects. I'm sure that is true in most scenarios that use mock objects for a testing strategy, but it is clearly true here. Want proof? You wouldn't believe how many times the Shale test framework had to flesh out implementations of abstract methods (that used to just throw UnsupportedOperationException) before the framework was actually usable in testing MyFaces components :-). Two -- by requiring impl to be a dependency for the test code, you allow the possibility of unintentionally using impl classes in the non-test code. As long as impl is scoped as test in the pom.xml for tomahawk, I don't see how maven would allow one of us to compile the non-test code. +1. In order to test components correctly, it is vital that the compile-time and runtime classpaths for the tests include the API jar file and the test framework, but *not* the impl classes. HOWEVER ... this condition is merely necessary but not sufficient. That is because JSF has quite a lot of implementation functionality built in to the API classes as well, so you could still end up with unintended dependencies on the MyFaces API classes. A robust testing strategy for components would execute against both (a) MyFaces API + Test Framework, and (b) JSF RI + Test Framework. Along with, of course, runtime tests against both API+IMPL combinations. Another observation is that end-users cannot download, build, test Tomahawk without MyFaces impl. Since Tomahawk is supposed to be JSF-implementation independent, it's contrary to our stated goal to require a specific implementation for testing or development. Obviously we want people to use tomahawk w/out myFaces impl. If you would like to make it possible for them to test tomahawk w/out impl than more power to you. I think this is taking it too far and we will never get a pat on the back for this. Isn't this the basic motivation behind migrating to a shared or commons artifact that both the MyFaces impl and the components can depend on, without creating a mutual dependency? (But that only deals with part of the problem, as the previous response paragraph describes.) Dennis Byrne Craig -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
ResponseWriter Question
I noticed in the ResponseWriter:
public void writeText(char cbuf[], int off, int len)
throws IOException
{
if(cbuf == null)
throw new NullPointerException(cbuf name must not be null);
if(cbuf.length off + len)
throw new IndexOutOfBoundsException((off + len) +
+ cbuf.length);
closeStartTagIfNecessary();
if(isScriptOrStyle())
{
String strValue = new String(cbuf, off, len);
_writer.write(UnicodeEncoder.encode(strValue, false, false));
} else
if(isTextarea())
{
String strValue = new String(cbuf, off, len);
_writer.write(HTMLEncoder.encode(strValue, false, false));
} else
{
String strValue = new String(cbuf, off, len);
_writer.write(HTMLEncoder.encode(strValue, true, true));
}
}
In the last case:
HTMLEncoder.encode(strValue, true, true)
Why would you want to tell the HTMLEncoder to write out a line break in
this case and this case only?
Adam and I are trying to get Facelets to go pure ResponseWriter for all
encode events, but this little quirk causes pages to render with lots of
breaks in MyFaces (this doesn't happen in the RI).
--
Jacob Hookom - Minneapolis
JSF-EG, JSF-RI, EL, Facelets
[jira] Created: (TOMAHAWK-203) Triggering of JavaScript with JSCookMenu broken.
Triggering of JavaScript with JSCookMenu broken. Key: TOMAHAWK-203 URL: http://issues.apache.org/jira/browse/TOMAHAWK-203 Project: MyFaces Tomahawk Type: Bug Components: JS Cook Menu Reporter: Felix Röthenbacher Priority: Minor Triggering of a JavaScript function from JSCookMenu is broken. The parsing of the given link is not correct as the structure of the id string seems to have changed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-202) Triggering of JavaScript with JSCookMenu broken.
Triggering of JavaScript with JSCookMenu broken. Key: TOMAHAWK-202 URL: http://issues.apache.org/jira/browse/TOMAHAWK-202 Project: MyFaces Tomahawk Type: Bug Components: JS Cook Menu Reporter: Felix Röthenbacher Priority: Minor Triggering of a JavaScript function from JSCookMenu is broken. The parsing of the given link is not correct as the structure of the id string seems to have changed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TOMAHAWK-203) Triggering of JavaScript with JSCookMenu broken.
[ http://issues.apache.org/jira/browse/TOMAHAWK-203?page=all ] Felix Röthenbacher updated TOMAHAWK-203: Triggering of JavaScript with JSCookMenu broken. Key: TOMAHAWK-203 URL: http://issues.apache.org/jira/browse/TOMAHAWK-203 Project: MyFaces Tomahawk Type: Bug Components: JS Cook Menu Reporter: Felix Röthenbacher Priority: Minor Triggering of a JavaScript function from JSCookMenu is broken. The parsing of the given link is not correct as the structure of the id string seems to have changed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOBAGO-45) UITree looses config when rerendering view
UITree looses config when rerendering view -- Key: TOBAGO-45 URL: http://issues.apache.org/jira/browse/TOBAGO-45 Project: MyFaces Tobago Type: Bug Reporter: Volker Weber Assigned to: Volker Weber Fix For: 1.0.7 The local tree attributes are not stored/restored in UITree -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-187) ClassCastException using panelTabbedPane in nightly build
[
http://issues.apache.org/jira/browse/TOMAHAWK-187?page=comments#action_12371057
]
Roland Schaal commented on TOMAHAWK-187:
Mike,
thanks a lot for your support!
The patch you have provided works perfectly with and without
serverSideTabSwitch!
Roland
ClassCastException using panelTabbedPane in nightly build
-
Key: TOMAHAWK-187
URL: http://issues.apache.org/jira/browse/TOMAHAWK-187
Project: MyFaces Tomahawk
Type: Bug
Components: Tabbed Pane
Versions: 1.1.2-SNAPSHOT
Reporter: Roland Schaal
Assignee: Mike Kienenberger
Attachments: HtmlPanelTabbedPane.java, HtmlPanelTabbedPane.java.patch.txt
Hello,
When using
serverSideTabSwitch=true
I get the following ClassCastException:
java.lang.ClassCastException
at
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane.isClientSide(HtmlPanelTabbedPane.java:142)
at
org.apache.myfaces.custom.tabbedpane.HtmlTabbedPaneRenderer.encodeEnd(HtmlTabbedPaneRenderer.java:92)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:442)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChildren(RendererUtils.java:419)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:75)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:442)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:216)
...
Looking at the code of HtmlPanelTabbedPane it seems to me that they try to
cast a String- into a Boolean-object, which causes the exception:
public boolean isClientSide(){
Boolean serverSideTabSwitch =
(Boolean)getAttributes().get(serverSideTabSwitch);
return serverSideTabSwitch != null ? !serverSideTabSwitch.booleanValue() :
true;
}
Regards,
Roland Schaal
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-67) inputCaledar incorrectly working with CSS
[ http://issues.apache.org/jira/browse/TOMAHAWK-67?page=comments#action_12371059 ] Boris Kovalenko commented on TOMAHAWK-67: - Have looked at current code. theme.css is used for dropdown calendar at the time present, isn't? And what regarding my problem - I think that a elements should be populated with class=dayCellClass to override global a style definition. Are You agree or my CSS knowlegde is not enough? Or even we should create styles like td.dayCellCalass etc and let the user to override it? inputCaledar incorrectly working with CSS - Key: TOMAHAWK-67 URL: http://issues.apache.org/jira/browse/TOMAHAWK-67 Project: MyFaces Tomahawk Type: Bug Components: Calendar Environment: Any system, Resin 3.0.14, JDK 1.4.2, Mozilla Firefox, IE Reporter: Boris Kovalenko Assignee: Martin Marinschek Priority: Minor Attachments: calendar.diff, calendar.diff, calendar.diff For weekRowClass inputCalendar renders tr class=weekRowClass. But if in css is special class for td defined it overrides tr. My suggestion is to remove class in tr element and use it with td elements. Same problems if a class is defined - so dayCellClass also is useless. So, I attached the small diff to fix this issues. May somebody review and approve (or not :) it? Also I have an idea to introduce maySelectInFuture feature. If it is true (default behavior) - we allowing selections of future days else we don't. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-204) JspTilesViewHandlerImpl create view for CSS external files (link/link) and it causes problem in forms containing input elements with non-ascii caracters entered
JspTilesViewHandlerImpl create view for CSS external files (link/link) and it causes problem in forms containing input elements with non-ascii caracters entered Key: TOMAHAWK-204 URL: http://issues.apache.org/jira/browse/TOMAHAWK-204 Project: MyFaces Tomahawk Type: Bug Components: Tiles Versions: 1.1.1 Environment: Linux, MyFaces 1.1.1, JDK 1.5, Tomcat 5.5 Reporter: Philippe Daucourt Fix For: 1.1.1 Strangely, JspTilesViewHandler tries to create a view for CSS external file (link/link). This behavior causes a problem with InputForm and InputText with non-ascii caracters entered (éàè for example). For example, if I enter bébé I get bébé after postback of the form. If I delete my external link for my CSS, everything works fine. I'm quite sure it is not an encoding problem. I have tried to use accept and enctyp for the form. I have set the encoding of my JSP (%@ page contentType=text/html;charset=UTF-8 language=java %) and I have set the html head with content-type (meta HTTP-EQUIV=Content-Type CONTENT=text/html;charset=UTF-8/) but without any success. Only the deletion of the external CSS works to solve the problem. Below is the logging output (first with CSS, second without CSS) First call: 2006-03-20 11:59:59 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspStateManagerImpl - No tree structure state found in client request 2006-03-20 11:59:59 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspViewHandlerImpl - Created view /test1.jsp 2006-03-20 11:59:59 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - JspTilesViewHandlerImpl init 2006-03-20 11:59:59 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - Reading tiles definitions 2006-03-20 12:00:00 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - Dispatching to /mainLayout.jsp 2006-03-20 12:00:04 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspStateManagerImpl - No tree structure state found in client request 2006-03-20 12:00:04 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspViewHandlerImpl - Created view /css/default.css 2006-03-20 12:00:04 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - Dispatching to /css/default.css Postback: 2006-03-20 12:00:10 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspStateManagerImpl - Tree structure restored from client request 2006-03-20 12:00:10 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - Dispatching to /mainLayout.jsp 2006-03-20 12:00:10 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspStateManagerImpl - No tree structure state found in client request 2006-03-20 12:00:10 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspViewHandlerImpl - Created view /css/default.css 2006-03-20 12:00:10 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - Dispatching to /css/default.css First call: 2006-03-20 11:58:10 [http-8084-Processor20] DEBUG org.apache.myfaces.application.jsp.JspStateManagerImpl - No tree structure state found in client request 2006-03-20 11:58:10 [http-8084-Processor20] DEBUG org.apache.myfaces.application.jsp.JspViewHandlerImpl - Created view /test1.jsp 2006-03-20 11:58:10 [http-8084-Processor20] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - Dispatching to /mainLayout.jsp Postback: 2006-03-20 11:58:15 [http-8084-Processor20] DEBUG org.apache.myfaces.application.jsp.JspStateManagerImpl - Tree structure restored from client request 2006-03-20 11:58:15 [http-8084-Processor20] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - Dispatching to /mainLayout.jsp -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-45) UITree looses config when rerendering view
[ http://issues.apache.org/jira/browse/TOBAGO-45?page=all ] Volker Weber resolved TOBAGO-45: Resolution: Fixed add values to saveState()/restoreState() UITree looses config when rerendering view -- Key: TOBAGO-45 URL: http://issues.apache.org/jira/browse/TOBAGO-45 Project: MyFaces Tobago Type: Bug Reporter: Volker Weber Assignee: Volker Weber Fix For: 1.0.7 The local tree attributes are not stored/restored in UITree -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TOBAGO-45) UITree looses config when rerendering view
[ http://issues.apache.org/jira/browse/TOBAGO-45?page=all ] Volker Weber closed TOBAGO-45: -- UITree looses config when rerendering view -- Key: TOBAGO-45 URL: http://issues.apache.org/jira/browse/TOBAGO-45 Project: MyFaces Tobago Type: Bug Reporter: Volker Weber Assignee: Volker Weber Fix For: 1.0.7 The local tree attributes are not stored/restored in UITree -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TOMAHAWK-187) ClassCastException using panelTabbedPane in nightly build
[ http://issues.apache.org/jira/browse/TOMAHAWK-187?page=all ]
Roland Schaal updated TOMAHAWK-187:
---
ClassCastException using panelTabbedPane in nightly build
-
Key: TOMAHAWK-187
URL: http://issues.apache.org/jira/browse/TOMAHAWK-187
Project: MyFaces Tomahawk
Type: Bug
Components: Tabbed Pane
Versions: 1.1.2-SNAPSHOT
Reporter: Roland Schaal
Assignee: Mike Kienenberger
Attachments: HtmlPanelTabbedPane.java, HtmlPanelTabbedPane.java.patch.txt
Hello,
When using
serverSideTabSwitch=true
I get the following ClassCastException:
java.lang.ClassCastException
at
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane.isClientSide(HtmlPanelTabbedPane.java:142)
at
org.apache.myfaces.custom.tabbedpane.HtmlTabbedPaneRenderer.encodeEnd(HtmlTabbedPaneRenderer.java:92)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:442)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChildren(RendererUtils.java:419)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:75)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:442)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:216)
...
Looking at the code of HtmlPanelTabbedPane it seems to me that they try to
cast a String- into a Boolean-object, which causes the exception:
public boolean isClientSide(){
Boolean serverSideTabSwitch =
(Boolean)getAttributes().get(serverSideTabSwitch);
return serverSideTabSwitch != null ? !serverSideTabSwitch.booleanValue() :
true;
}
Regards,
Roland Schaal
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (TOMAHAWK-204) JspTilesViewHandlerImpl create view for CSS external files (link/link) and it causes problem in forms containing input elements with non-ascii caracters entered
[ http://issues.apache.org/jira/browse/TOMAHAWK-204?page=all ] Philippe Daucourt resolved TOMAHAWK-204: - Resolution: Fixed It is not a problem of MyFaces. The problem occurs when an external resource (css or image) is declared without a trailing / (context relative resource). For example, in my case: link rel=stylesheet href=css/default.css type=text/css/ When you use url-mapping /faces/* for JSP to be handled by Faces Servlet, the url for my CSS become during runtime /myContext/faces/css/default.css. So, the CSS is handled by Faces Servlet and it's normal that JspTilesViewHandlerImpl receives it and tries to create a view. I have resolved my problem using trailing / for all my external resources. JspTilesViewHandlerImpl create view for CSS external files (link/link) and it causes problem in forms containing input elements with non-ascii caracters entered Key: TOMAHAWK-204 URL: http://issues.apache.org/jira/browse/TOMAHAWK-204 Project: MyFaces Tomahawk Type: Bug Components: Tiles Versions: 1.1.1 Environment: Linux, MyFaces 1.1.1, JDK 1.5, Tomcat 5.5 Reporter: Philippe Daucourt Fix For: 1.1.1 Strangely, JspTilesViewHandler tries to create a view for CSS external file (link/link). This behavior causes a problem with InputForm and InputText with non-ascii caracters entered (éàè for example). For example, if I enter bébé I get bébé after postback of the form. If I delete my external link for my CSS, everything works fine. I'm quite sure it is not an encoding problem. I have tried to use accept and enctyp for the form. I have set the encoding of my JSP (%@ page contentType=text/html;charset=UTF-8 language=java %) and I have set the html head with content-type (meta HTTP-EQUIV=Content-Type CONTENT=text/html;charset=UTF-8/) but without any success. Only the deletion of the external CSS works to solve the problem. Below is the logging output (first with CSS, second without CSS) First call: 2006-03-20 11:59:59 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspStateManagerImpl - No tree structure state found in client request 2006-03-20 11:59:59 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspViewHandlerImpl - Created view /test1.jsp 2006-03-20 11:59:59 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - JspTilesViewHandlerImpl init 2006-03-20 11:59:59 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - Reading tiles definitions 2006-03-20 12:00:00 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - Dispatching to /mainLayout.jsp 2006-03-20 12:00:04 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspStateManagerImpl - No tree structure state found in client request 2006-03-20 12:00:04 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspViewHandlerImpl - Created view /css/default.css 2006-03-20 12:00:04 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - Dispatching to /css/default.css Postback: 2006-03-20 12:00:10 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspStateManagerImpl - Tree structure restored from client request 2006-03-20 12:00:10 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - Dispatching to /mainLayout.jsp 2006-03-20 12:00:10 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspStateManagerImpl - No tree structure state found in client request 2006-03-20 12:00:10 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspViewHandlerImpl - Created view /css/default.css 2006-03-20 12:00:10 [http-8084-Processor22] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - Dispatching to /css/default.css First call: 2006-03-20 11:58:10 [http-8084-Processor20] DEBUG org.apache.myfaces.application.jsp.JspStateManagerImpl - No tree structure state found in client request 2006-03-20 11:58:10 [http-8084-Processor20] DEBUG org.apache.myfaces.application.jsp.JspViewHandlerImpl - Created view /test1.jsp 2006-03-20 11:58:10 [http-8084-Processor20] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - Dispatching to /mainLayout.jsp Postback: 2006-03-20 11:58:15 [http-8084-Processor20] DEBUG org.apache.myfaces.application.jsp.JspStateManagerImpl - Tree structure restored from client request 2006-03-20 11:58:15 [http-8084-Processor20] DEBUG org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl - Dispatching to /mainLayout.jsp -- This message is automatically generated by
[jira] Commented: (MYFACES-1163) JBoss classloading fails if myfaces jars installed in tomcat
[ http://issues.apache.org/jira/browse/MYFACES-1163?page=comments#action_12371085 ] Stan Silvert commented on MYFACES-1163: --- Hello Cristi, Please keep each jira task confined to a single issue. Also, have you asked about this on the MyFaces user forum or the Seam forum? Do you have a test case that reproduces the problem? Do you have a proposed fix? Any or all of these things will help you get your problem resolved much faster. I doubt that anyone has time to do the research for you on this, but if all else fails you can open a new jira task for it. Regards, Stan JBoss classloading fails if myfaces jars installed in tomcat Key: MYFACES-1163 URL: http://issues.apache.org/jira/browse/MYFACES-1163 Project: MyFaces Core Type: Bug Versions: 1.1.2, 1.1.2-SNAPSHOT, 1.1.3-SNAPSHOT Environment: JBoss 4.0.4RC1 myfaces-1.1.3-SNAPSHOT Reporter: Ingo Massen Assignee: Stan Silvert Cannot use Myfaces jars installed in JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/jsf-libs as they do not use the correct WebappClassloader but instead an UCL3 classloader. This is because myfaces use the following line in StateUtils.getAsObject ObjectInputStream s = new ObjectInputStream(input); instead of import org.apache.myfaces.shared.util.MyFacesObjectInputStream; ObjectInputStream s = new MyFacesObjectInputStream(input); The same applies to JspStateManagerImpl.deserializeView(). ObjectInputStream uses Class.forName instead of Thread.currentThread().getContextClassLoader() as the ClassUtils implementation that MyFacesObjectInputStream uses does. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1163) JBoss classloading fails if myfaces jars installed in tomcat
[ http://issues.apache.org/jira/browse/MYFACES-1163?page=comments#action_12371086 ] Stan Silvert commented on MYFACES-1163: --- Back to the issue at hand, Ingo has reported to me that all Seam examples are working with the latest fix. Also, he says that his own application is now working. Dennis, are you still seeing a problem? Maybe you and Ingo can get together to see what is different about your environments? Stan JBoss classloading fails if myfaces jars installed in tomcat Key: MYFACES-1163 URL: http://issues.apache.org/jira/browse/MYFACES-1163 Project: MyFaces Core Type: Bug Versions: 1.1.2, 1.1.2-SNAPSHOT, 1.1.3-SNAPSHOT Environment: JBoss 4.0.4RC1 myfaces-1.1.3-SNAPSHOT Reporter: Ingo Massen Assignee: Stan Silvert Cannot use Myfaces jars installed in JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/jsf-libs as they do not use the correct WebappClassloader but instead an UCL3 classloader. This is because myfaces use the following line in StateUtils.getAsObject ObjectInputStream s = new ObjectInputStream(input); instead of import org.apache.myfaces.shared.util.MyFacesObjectInputStream; ObjectInputStream s = new MyFacesObjectInputStream(input); The same applies to JspStateManagerImpl.deserializeView(). ObjectInputStream uses Class.forName instead of Thread.currentThread().getContextClassLoader() as the ClassUtils implementation that MyFacesObjectInputStream uses does. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-205) inputCalendar Popup positioned incorrectly in scrollable div
inputCalendar Popup positioned incorrectly in scrollable div Key: TOMAHAWK-205 URL: http://issues.apache.org/jira/browse/TOMAHAWK-205 Project: MyFaces Tomahawk Type: Bug Components: Calendar Versions: 1.1.2-SNAPSHOT Reporter: Geoffrey Longo The popup for the inputCalendar is positioned relative to the body of the page, not the containing div. Therefore, a calendar that is inside a scrollable div (overflow: auto) may not be positioned correctly if the containing div's left and top positons are not the same as the body. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: tomahawk/src/test has dependencies on MyFaces Impl
On 3/20/06, Martin Marinschek [EMAIL PROTECTED] wrote: For properly testing against both APIs and IMPLs, we'd need to have the RI be1) maven2-nized2) with a compatible license.Now, license issues have been resolved for most of the licenses wedeal with. Was the CDDL amongst the libraries we may deliver binaries with? I do believe so...Yes, per the current proposal for compatible licenses that is currently being discussed in Apache's licensing mailing lists.On the other hand, is *distribution* really a requirement? Or just the ability to automatically download from a Maven-compatible repository without any click-through licenses? That's possible today for the 1.2 JSF RI (which should ideally be added to the testing matrix I listed earlier, since the 1.2 spec is nearing final release) ... working on it for 1.1. regards,MartinCraig
[jira] Resolved: (TOBAGO-4) remove UILabledInputLayout
[ http://issues.apache.org/jira/browse/TOBAGO-4?page=all ] Bernd Bohmann resolved TOBAGO-4: Resolution: Fixed remove UILabledInputLayout -- Key: TOBAGO-4 URL: http://issues.apache.org/jira/browse/TOBAGO-4 Project: MyFaces Tobago Type: Sub-task Reporter: Udo Schnurpfeil Assignee: Bernd Bohmann Priority: Minor Fix For: 1.0.7 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TOBAGO-4) remove UILabledInputLayout
[ http://issues.apache.org/jira/browse/TOBAGO-4?page=all ] Bernd Bohmann closed TOBAGO-4: -- remove UILabledInputLayout -- Key: TOBAGO-4 URL: http://issues.apache.org/jira/browse/TOBAGO-4 Project: MyFaces Tobago Type: Sub-task Reporter: Udo Schnurpfeil Assignee: Bernd Bohmann Priority: Minor Fix For: 1.0.7 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-1157) EvaluationException gets swallowed in ValueBindingImpl and UIInput
[ http://issues.apache.org/jira/browse/MYFACES-1157?page=all ] Jurgen Lust updated MYFACES-1157: - Resolution: Fixed patch applied EvaluationException gets swallowed in ValueBindingImpl and UIInput -- Key: MYFACES-1157 URL: http://issues.apache.org/jira/browse/MYFACES-1157 Project: MyFaces Core Type: Improvement Components: General Versions: 1.1.1, 1.1.2-SNAPSHOT, 1.1.2 Environment: all Reporter: Jurgen Lust Assignee: Jurgen Lust Priority: Minor Attachments: evaluation-api.patch, evaluation-impl.patch During model update, when an Exception is thrown in the setValue method of the PropertyResolverImpl, it is wrapped in an EvaluationException, which is then caught in the ValueBindingImpl, and again wrapped in another EvaluationException, which is finally caught in the UIInput, where a generic error FacesMessage is rendered to the browser. This could be cleaner, and differs from the way it is done in the Sun RI. The Sun RI does the following: 1. Exception is caught by PropertyResolverImpl, wrapped in an EvaluationException, and thrown again 2. ValueBindingImpl catches the EvaluationException and rethrows it unchanged 3. UIInput catches the EvaluationException and creates an error FacesMessage containing the EvaluationException.getMessage() if it's not null, otherwise a generic error message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TOMAHAWK-175) schedule component: select available time slots to create new entries
[ http://issues.apache.org/jira/browse/TOMAHAWK-175?page=all ] Jurgen Lust closed TOMAHAWK-175: schedule component: select available time slots to create new entries - Key: TOMAHAWK-175 URL: http://issues.apache.org/jira/browse/TOMAHAWK-175 Project: MyFaces Tomahawk Type: Improvement Versions: 1.1.2-SNAPSHOT Reporter: Stefan Betermieux Assignee: Jurgen Lust Attachments: schedule-mouselistener-all.patch Hi, our group is using the schedule component in a time management application and user evaluation showed that the entry of new appointments is cumbersome. We used to have an add entry button next to the week view, where the user had to select the day and time for start and end of the appointment, just like the EntryHandler in the examples do. We opted for a simple solution which adds a lot of usability: - if there are no appointments for a single day, put a transparent entry in the schedule, which behaves like a normal appointment (selectable) and which spans the whole day. - if there is for example one appointment arround noon, replace the first transparent entry by two transparent entries around the visible appointment. - repeat as needed... At the end, there is no unselectable space left for a single day, it is either a block representing an appointment or an invisble but selectable block representing available time. If a transparent block is selected, put the start and end time in the model. Take a look at our modified sandbox example web app, which implements the described behaviour: http://sirius.fernuni-hagen.de/myfaces-example-sandbox/schedule/example2.jsf (because of TOMAHAWK-173, the creation of new entries has to be triggered by a commandButton on the left side after selecting the time slot) The modifications are mostly renderer based, the model had just to be changed to support the start and end dates of the selected available time slot. There are no modifications of existing code bases using the schedule component if AbstractScheduleModel has been extended. If ScheduleModel is implemented, the new methods of the interface to get and set the start and end time should be added. I am not yet providing a patch because some questions have to be discussed: - would this be a desirable behaviour for general schedule users, or is it just our use case? - should this behaviour be optional? (At the moment, it respects the readonly flag, but there may be situations where appointments should be selectable, but the available time slots should not be) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOMAHAWK-173) schedule component doesn't invoke the action value binding
[ http://issues.apache.org/jira/browse/TOMAHAWK-173?page=all ]
Jurgen Lust resolved TOMAHAWK-173:
--
Resolution: Fixed
fixed by the patch for TOMAHAWK-175
schedule component doesn't invoke the action value binding
--
Key: TOMAHAWK-173
URL: http://issues.apache.org/jira/browse/TOMAHAWK-173
Project: MyFaces Tomahawk
Type: Bug
Versions: 1.1.2-SNAPSHOT
Reporter: Stefan Betermieux
Assignee: Jurgen Lust
Priority: Minor
Hi,
the current version of the sandbox schedule component doesn't invoke the
action value binding provided as a tag attribute. For instance, the example
with an action value binding doesn't work (ScheduleExampleHandler's public
String someAction() is defined in my case):
s:schedule value=#{scheduleHandler1.model} id=schedule1
rendered=true visibleEndHour=18
visibleStartHour=8
workingEndHour=17 workingStartHour=9
readonly=false
theme=evolution tooltip=true
action=#{scheduleHandler1.someAction} /
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (TOMAHAWK-173) schedule component doesn't invoke the action value binding
[ http://issues.apache.org/jira/browse/TOMAHAWK-173?page=all ]
Jurgen Lust closed TOMAHAWK-173:
schedule component doesn't invoke the action value binding
--
Key: TOMAHAWK-173
URL: http://issues.apache.org/jira/browse/TOMAHAWK-173
Project: MyFaces Tomahawk
Type: Bug
Versions: 1.1.2-SNAPSHOT
Reporter: Stefan Betermieux
Assignee: Jurgen Lust
Priority: Minor
Hi,
the current version of the sandbox schedule component doesn't invoke the
action value binding provided as a tag attribute. For instance, the example
with an action value binding doesn't work (ScheduleExampleHandler's public
String someAction() is defined in my case):
s:schedule value=#{scheduleHandler1.model} id=schedule1
rendered=true visibleEndHour=18
visibleStartHour=8
workingEndHour=17 workingStartHour=9
readonly=false
theme=evolution tooltip=true
action=#{scheduleHandler1.someAction} /
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
sharing HtmlPopup javascript with schedule
Hi, Currently, the schedule component uses the domTT library for Javascript popups, however I would like to use the JSPopup.js from the HtmlPopup instead, because it is much smaller and really all I need for the schedule. Moreover, domTT seems to have problems with Opera (see TOMAHAWK-193). I could of course just add the resource org.apache.myfaces.custom.popup.resource.JSPopup.js to the renderer class, but then the schedule component depends on another component for its rendering, which might not be desirable. So, my question is, would it be a good idea to start a common myfaces javascript library with usefuls scripts like this, for example under tomahawk/src/main/resources/org/apache/myfaces/custom/javascript? Kind regards, Jurgen
[jira] Updated: (TOMAHAWK-134) t:saveState only works with client-side state saving
[ http://issues.apache.org/jira/browse/TOMAHAWK-134?page=all ]
updated TOMAHAWK-134:
--
t:saveState only works with client-side state saving
Key: TOMAHAWK-134
URL: http://issues.apache.org/jira/browse/TOMAHAWK-134
Project: MyFaces Tomahawk
Type: Bug
Components: UISaveState
Environment: Windows XP, RSA 6.0.1, JDK 1.5.0_04, Tomcat 5.0.28, Sun RI
(distributed with RSA 6.0.1), Tomahawk nightly build (17/10/05)
Reporter: Juan Medín
t:saveState doesn't store the state when setting STATE_SAVING_METHOD to
server. It _does_ work when setting STATE_SAVING_METHOD to client.
I'm using the Sun RI (distributed with RSA 6.0.1) plus a recent nightly build
of Tomahawk.
The test code is trivial: two JSPs with t:saveState
value=aRequestScopedObject/ like this:
f:view
BODY
t:saveState value=#{aRequestScopedObject}/
h:form id=form1
more html
The generated HTML doesn't include any reference to the saveState object when
setting server-side state saving. For the example above in a simple test form
with two fields (text1 and text2) this is the generated form code:
form id=form1 method=post
action=/testbox/faces/app/savestate/test1.jsp
enctype=application/x-www-form-urlencoded
input id=form1:text1 type=text
name=form1:text1 value=/
input id=form1:text2 type=text
name=form1:text2 value=/
input type=submit value=Submit
name=form1:button1 id=form1:button1/
input type=hidden name=form1 value=form1 /
/form
There is no html code for the saveState() tag.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-201) Null pointer exception in org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils.selectContentType
[ http://issues.apache.org/jira/browse/TOMAHAWK-201?page=comments#action_12371171 ] Daniel Bernstein commented on TOMAHAWK-201: --- I'm having the same problem. Null pointer exception in org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils.selectContentType --- Key: TOMAHAWK-201 URL: http://issues.apache.org/jira/browse/TOMAHAWK-201 Project: MyFaces Tomahawk Type: Bug Versions: 1.1.2-SNAPSHOT Environment: Linux, JBoss Head Reporter: Arash Bijanzadeh I am getting a null pointer excetion in org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils.selectContentType. The problemis my browser(Mozilla) do not send a accept header, abd the clas tryin to get it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TOMAHAWK-134) t:saveState only works with client-side state saving
[ http://issues.apache.org/jira/browse/TOMAHAWK-134?page=all ]
Mike Kienenberger updated TOMAHAWK-134:
---
t:saveState only works with client-side state saving
Key: TOMAHAWK-134
URL: http://issues.apache.org/jira/browse/TOMAHAWK-134
Project: MyFaces Tomahawk
Type: Bug
Components: UISaveState
Environment: Windows XP, RSA 6.0.1, JDK 1.5.0_04, Tomcat 5.0.28, Sun RI
(distributed with RSA 6.0.1), Tomahawk nightly build (17/10/05)
Reporter: Juan Medín
t:saveState doesn't store the state when setting STATE_SAVING_METHOD to
server. It _does_ work when setting STATE_SAVING_METHOD to client.
I'm using the Sun RI (distributed with RSA 6.0.1) plus a recent nightly build
of Tomahawk.
The test code is trivial: two JSPs with t:saveState
value=aRequestScopedObject/ like this:
f:view
BODY
t:saveState value=#{aRequestScopedObject}/
h:form id=form1
more html
The generated HTML doesn't include any reference to the saveState object when
setting server-side state saving. For the example above in a simple test form
with two fields (text1 and text2) this is the generated form code:
form id=form1 method=post
action=/testbox/faces/app/savestate/test1.jsp
enctype=application/x-www-form-urlencoded
input id=form1:text1 type=text
name=form1:text1 value=/
input id=form1:text2 type=text
name=form1:text2 value=/
input type=submit value=Submit
name=form1:button1 id=form1:button1/
input type=hidden name=form1 value=form1 /
/form
There is no html code for the saveState() tag.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Ajax form
Hi all,Been a bit out of the loop for the past few weeks, I am just wondering if there has been much going on with the ajax sandbox components? There was talk of making them dojo'd ;), so just wondering if that has happened. The next step I would like to take is to make it so that multiple components can be submitted at the same time so instead of having affectedAjaxComponent, it could have a full post with an entire form. And after that, I would like to have it be able to kick off events on other components on the client side so you can update UI elements as required. Currently, it will update a message tag if an error occurs, but need similar behaviour for not message tags. Simple example:form1:inputText1 gets submitted via ajax with a command button.divA gets notified of the successful event and then itself calls an ajax method to get updated content.I'm not quite sure how this should work yet, so if anyone has thoughts on this, I'd love to hear it. I'm thinking a component could register itself as a listener on another component. Travis
[jira] Commented: (MYFACES-1183) Configurations /WEB-INF/faces-config.xml loaded twice
[ http://issues.apache.org/jira/browse/MYFACES-1183?page=comments#action_12371180 ] Gerald Müllan commented on MYFACES-1183: Hm..the two param-values should be in the current svn snapshot in the web.xml of our sandbox examples: param-value/WEB-INF/examples-config.xml,/WEB-INF/sandbox/faces-config.xml/param-value The second one is not needed anymore, I suppose.. Configurations /WEB-INF/faces-config.xml loaded twice - Key: MYFACES-1183 URL: http://issues.apache.org/jira/browse/MYFACES-1183 Project: MyFaces Core Type: Bug Components: General Versions: 1.1.1 Environment: Weblogic 9, Facelets, MyFaces1.1.10 Reporter: Anthony Hong I have a JSF configuration file faces-config.xml and put it under /WEB-INF/ In web.xml, setup context-param to load jsf configuration file. context-param param-namejavax.faces.CONFIG_FILES/param-name param-value/WEB-INF/faces-config.xml/param-value /context-param Then this configuration file will be loaded twice. As /WEB-INF/faces-config.xml will loaded automaticly at first. If I put it in CONFIG_FILES again, it doesn't ignore this file. then phase listener and navigatorHandler has two instances in container which maybe a problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Ajax form
A lot of this is occurring with JSF 1.2 and the Avatar proposal for partial processing of the component tree. Oracle's ADF components too have the concept of triggers/observers today. Travis Reeder wrote: Hi all, Been a bit out of the loop for the past few weeks, I am just wondering if there has been much going on with the ajax sandbox components? There was talk of making them dojo'd ;), so just wondering if that has happened. The next step I would like to take is to make it so that multiple components can be submitted at the same time so instead of having affectedAjaxComponent, it could have a full post with an entire form. And after that, I would like to have it be able to kick off events on other components on the client side so you can update UI elements as required. Currently, it will update a message tag if an error occurs, but need similar behaviour for not message tags. Simple example: form1:inputText1 gets submitted via ajax with a command button. divA gets notified of the successful event and then itself calls an ajax method to get updated content. I'm not quite sure how this should work yet, so if anyone has thoughts on this, I'd love to hear it. I'm thinking a component could register itself as a listener on another component. Travis -- -- Sent from my FrankenBerry Wireless Handheld
Re: Ajax form
Travis, Check out the partialTriggers attribute on the ADF components. Also the AdfFacesContext.addPartialTarget() method. These'd be good things to apply to MyFaces as a whole. One of the more important features of ADF is that we don't require target components to know anything about AJAX at all, or to be enclosed in any sort of AJAX zone component - so you can redraw any component. As long as they follow some standard best practices for using the ResponseWriter, it just works. -- Adam On 3/20/06, Jacob Hookom [EMAIL PROTECTED] wrote: A lot of this is occurring with JSF 1.2 and the Avatar proposal for partial processing of the component tree. Oracle's ADF components too have the concept of triggers/observers today. Travis Reeder wrote: Hi all, Been a bit out of the loop for the past few weeks, I am just wondering if there has been much going on with the ajax sandbox components? There was talk of making them dojo'd ;), so just wondering if that has happened. The next step I would like to take is to make it so that multiple components can be submitted at the same time so instead of having affectedAjaxComponent, it could have a full post with an entire form. And after that, I would like to have it be able to kick off events on other components on the client side so you can update UI elements as required. Currently, it will update a message tag if an error occurs, but need similar behaviour for not message tags. Simple example: form1:inputText1 gets submitted via ajax with a command button. divA gets notified of the successful event and then itself calls an ajax method to get updated content. I'm not quite sure how this should work yet, so if anyone has thoughts on this, I'd love to hear it. I'm thinking a component could register itself as a listener on another component. Travis -- -- Sent from my FrankenBerry Wireless Handheld
[jira] Closed: (MYFACES-1149) StateUtils has a static inializer that calls FacesContext.getCurrentInstance()
[ http://issues.apache.org/jira/browse/MYFACES-1149?page=all ] Dennis Byrne closed MYFACES-1149: - StateUtils has a static inializer that calls FacesContext.getCurrentInstance() -- Key: MYFACES-1149 URL: http://issues.apache.org/jira/browse/MYFACES-1149 Project: MyFaces Core Type: Bug Versions: 1.1.2-SNAPSHOT Reporter: Manfred Geiler Assignee: Dennis Byrne Attachments: StateUtils.txt In a multi-threaded environment or when using multiple webapps within one container this is subject to fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
