Re: [tobago] URI Names of the Taglib
While moving to myfaces I suggest to rename it to: http://myfaces.apache.org/tobago/component http://myfaces.apache.org/tobago/extension +1 Manfred
[jira] Commented: (MYFACES-885) Make version information available at runtime
[ http://issues.apache.org/jira/browse/MYFACES-885?page=comments#action_12358782 ] Ronald Brill commented on MYFACES-885: -- But maybe we can start with the primitive step to change the manifest to make the basic information readable (like it is done in all other jar's like commons). This will be a big help here and it will solve 80% of my problems. Then you have sufficient time to implement the advanced thing. Make version information available at runtime - Key: MYFACES-885 URL: http://issues.apache.org/jira/browse/MYFACES-885 Project: MyFaces Type: Improvement Reporter: Ronald Brill Please make the version/build information availabe at runtime. Maybe you can change the manifest file so that something like Package.getPackage(.).getImplementationVersion(); works. Or provide a Version class that provides the information. Or implement both ways. It really helps if you have to support various projects. Then every project is able to log the versions of the used libraries at startup. Thanks -- 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
Questions about the schedule component
I am interested in using and submitting patches for the Schedule component. I have a few question: 1) Does this component have a lot of community support or interest? 2) Is their a better component with similar features? 3) What is the process to move a component out of the sandbox and into Tomahawk? 4) Is their any design plan or feature wish list for the schedule component? I have checked the Help Wanted page, the component's wiki page, and JIRA to no avail. 5) Is this list the best place to get permission to add features to the component? 6) Is the best way to submit patches is via JIRA? Paul Spencer
Re: Questions about the schedule component
Op di, 29-11-2005 te 09:07 -0500, schreef Paul Spencer: I am interested in using and submitting patches for the Schedule component. I have a few question: 1) Does this component have a lot of community support or interest? Well, since I submitted the component to myfaces, you are one of the first that actually wants to use it :-) 2) Is their a better component with similar features? Not that I'm aware of, otherwise I wouldn't have written it... 3) What is the process to move a component out of the sandbox and into Tomahawk? I have been wondering about that one too :-) 4) Is their any design plan or feature wish list for the schedule component? I have checked the Help Wanted page, the component's wiki page, and JIRA to no avail. There is another component, the planner, that is related to the schedule. I have concentrated on the schedule first, because that seems to be the most useful of the 2. The planner component needs a better datamodel, theme support, etc... -- Jurgen Lust Project Leader J2EE Software Development Department of Information and Communication Technology Ghent University Krijgslaan 281, S9 9000 Gent, Belgium +32-9-2648554
Re: Questions about the schedule component
The schedule and planner components look great. I haven't had a need to use them in my programming yet but you can be sure I will take a close look when the need arises. My suggestion would be to post your patch to JIRA for Jurgen and others to review. If there is a consensus, one of the committers will be happy to apply it. As for moving out of the sandbox, these components seem pretty complete but they haven't been thoroughly tested. If we could get some confirmation from a few users who have actually used the component I think that would be good. We'll also have to review everything to make sure the javadoc is complete and that the examples look good. I was actually thinking of recommending we promote these two components soon so maybe we can get started with that sooner rather then later. sean On 11/29/05, Jurgen Lust [EMAIL PROTECTED] wrote: Op di, 29-11-2005 te 09:07 -0500, schreef Paul Spencer: I am interested in using and submitting patches for the Schedule component. I have a few question: 1) Does this component have a lot of community support or interest? Well, since I submitted the component to myfaces, you are one of the first that actually wants to use it :-) 2) Is their a better component with similar features? Not that I'm aware of, otherwise I wouldn't have written it... 3) What is the process to move a component out of the sandbox and into Tomahawk? I have been wondering about that one too :-) 4) Is their any design plan or feature wish list for the schedule component? I have checked the Help Wanted page, the component's wiki page, and JIRA to no avail. There is another component, the planner, that is related to the schedule. I have concentrated on the schedule first, because that seems to be the most useful of the 2. The planner component needs a better datamodel, theme support, etc... -- Jurgen Lust Project Leader J2EE Software Development Department of Information and Communication Technology Ghent University Krijgslaan 281, S9 9000 Gent, Belgium +32-9-2648554
Maven scripts?
If anyone has a Maven2 script in progress for MyFaces I would like to see it. I'm going to try and start one of my own if nobody produces one. Since I'm completely new to Maven I will be needing the help of our Maven experts. Hopefully the Tobago team and Struts lurkers will be able to help us as well ;-) I'm going to try and devote some time to this in between ApacheCon sessions ... sean
[jira] Created: (MYFACES-886) Problem with custom TreeModelListeners to DefaultTreeModel
Problem with custom TreeModelListeners to DefaultTreeModel
--
Key: MYFACES-886
URL: http://issues.apache.org/jira/browse/MYFACES-886
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: 1.1.1
Environment: xp, tomcat, java 1.4.2
Reporter: Victor Alekseev
Priority: Blocker
Program code:
...
model = new DefaultTreeModel(root);
model.getTreeModelListeners().add(new testListner());
...
class testListner implements TreeModelListener { ...}
Exception:
2005-11-29 16:28:22 StandardContext[]Loading Spring root WebApplicationContext
2005-11-29 16:28:29 StandardContext[/adf-faces-demo]Error configuring
application listener of class com.sun.faces.config.ConfigureListener
java.lang.ClassNotFoundException: com.sun.faces.config.ConfigureListener
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1366)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1213)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3723)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4257)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:866)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:850)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at
org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:316)
at org.apache.catalina.core.StandardHost.install(StandardHost.java:859)
at
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:653)
Problem code:
public void addToModelListeners()
{
Collection listeners =
getModel(FacesContext.getCurrentInstance()).getTreeModelListeners();
long currentTime = System.currentTimeMillis();
boolean found = false;
for (Iterator iterator = listeners.iterator(); iterator.hasNext();)
{
ModelListener listener = (ModelListener) iterator.next();
--
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: [jira] Commented: (MYFACES-882) CommandLink doesn't work if javascript is disabled
Al, My rant wasn't really directed at you personally. It's just that I've seen this complaint from users over and over on different mailing lists and forums. These users are *intentionally* trying to develop complex webapps without javascript. I just can't understand why anybody would bother. And if you were forced to do this by a client, you would be limited in the sophistication that you could achieve so why bother with JSF? sean On 11/29/05, Alberto Molpeceres [EMAIL PROTECTED] wrote: It isn't that I was concerned. It's just that I had disabled it (just testing), and JSF didn't help me to find the error. In fact, often MyFaces (or JSF in general) doesn't help very much to find errors, altough they could be clearly mine like in this case. If you make a mistake I would expect MyFaces to tell me, not just write something that doesn't work. My apologies. al. On 11/28/05, Sean Schofield [EMAIL PROTECTED] wrote: I can't understand for the life of me why someone would write a webapp that was complicated enough to justify JSF and still be concerned about browsers that don't support javascript. I'm sure there are some scenarios out there but if you can't count on javascript being enabled then IMO, you shouldn't be wasting your time with the overhead and complexities of JSF. Just use Struts or something simpler. sean On 11/28/05, Mike Kienenberger [EMAIL PROTECTED] wrote: JSF isn't designed to handle GET requests, so just modifying the link wouldn't be sufficient. In any case, the parameters generated would be far too large :) Take a look at a JSF form submit sometime. The idea of providing an error if you try to use JSF without javascript isn't a bad one. I'm not sure what to suggest, though. I don't think rendering a message stating that you can't use links without javascript is the best solution. Perhaps the server should simply throw a FacesException if someone attempts to render a component that requires javascript, and the parameter is set to false. Maybe some of the other committers can comment on this. On 11/28/05, Alberto Molpeceres [EMAIL PROTECTED] wrote: On 11/28/05, Mike Kienenberger (JIRA) dev@myfaces.apache.org wrote: [ http://issues.apache.org/jira/browse/MYFACES-882?page=comments#action_12358688 ] Mike Kienenberger commented on MYFACES-882: --- Well, we can discuss it on the mailing lists, but the short answer is that javascript is required to make the link submit the form. Normal anchor tags can't submit forms, so the anchor tag has to use javascript to click a submit button. Hi Mike. I was just wondering, why something to simply should need javascript. I mean, why not simply add all needed parameters to the link?. Or if really that's not possible, it would be better just write a message like don't use commandLink with js disabled instead of just rendering a broken link. Don't get me worng, I know it's my failure if I don't know what the specification says, only I have lost around three hours looking for a solution and am a bit frustrated. al. -- Alberto Molpeceres alberto.molpeceres @ linkingpaths.com (+34) 661 304 614 Linking Paths Francisco Maciá 11, 7º - 48014 Bilbao (+34) 944 764 328 http://www.linkingpaths.com
Re: Maven scripts?
I am fairly new to maven, but I could help with that if no one has already done the script. I am also migrating a private project to maven, so I am already dealing with this. One question is: it is the intention to maintain the current structure, or do we adapt the source tree to the conventions (eg. src/main/java, src/main/resources). IMO, we need just to provide the pom.xml files for each subproject and a general pom.xml that calls the subprojects poms... Regards, Bruno 2005/11/29, Sean Schofield [EMAIL PROTECTED]: If anyone has a Maven2 script in progress for MyFaces I would like to see it. I'm going to try and start one of my own if nobody produces one. Since I'm completely new to Maven I will be needing the help of our Maven experts. Hopefully the Tobago team and Struts lurkers will be able to help us as well ;-) I'm going to try and devote some time to this in between ApacheCon sessions ... sean
[jira] Created: (MYFACES-887) javax.servlet.ServletException: text name must not be null when subtitle = null in DAY mode
javax.servlet.ServletException: text name must not be null when subtitle = null in DAY mode - Key: MYFACES-887 URL: http://issues.apache.org/jira/browse/MYFACES-887 Project: MyFaces Type: Bug Components: Sandbox Versions: 1.1.1 Reporter: Paul Spencer When the schedule is in DAY mode, an entry with getSubtitle() == null causes the following error returned javax.faces.FacesException: text name must not be null org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:421) org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234) org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:352) javax.faces.webapp.FacesServlet.service(FacesServlet.java:107) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122) A portion of the stack trace from the log file is below, but I believe the resolution is to only write the subtitle if it is not null in ScheduleDetailedDayRenderer.java around line 505. From localhost.log SEVERE: Servlet.service() for servlet jsp threw exception java.lang.NullPointerException: text name must not be null at org.apache.myfaces.renderkit.html.HtmlResponseWriterImpl.writeText(HtmlResponseWriterImpl.java:421) at org.apache.myfaces.custom.schedule.renderer.ScheduleDetailedDayRenderer.writeEntries(ScheduleDetailedDayRenderer.java:505) at org.apache.myfaces.custom.schedule.renderer.ScheduleDetailedDayRenderer.encodeChildren(ScheduleDetailedDayRenderer.java:117) at org.apache.myfaces.custom.schedule.renderer.ScheduleDelegatingRenderer.encodeChildren(ScheduleDelegatingRenderer.java:75) at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:319) at org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:444) at org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427) at org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:448) at org.apache.myfaces.renderkit.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:203) at org.apache.myfaces.renderkit.html.HtmlGridRendererBase.encodeEnd(HtmlGridRendererBase.java:85) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331) at javax.faces.webapp.UIComponentTag.encodeEnd(UIComponentTag.java:349) at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:253) at org.apache.myfaces.taglib.UIComponentBodyTagBase.doEndTag(UIComponentBodyTagBase.java:55) -- 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: (MYFACES-888) Classes for Schedule Entry, Title, and Subtitle should be optional parameters to the tag.
Classes for Schedule Entry, Title, and Subtitle should be optional parameters
to the tag.
-
Key: MYFACES-888
URL: http://issues.apache.org/jira/browse/MYFACES-888
Project: MyFaces
Type: Improvement
Components: Sandbox
Versions: 1.1.1
Reporter: Paul Spencer
CSS Class for the Schedule Component are hardcoded. I sugget they should be
optional parameters to the tag.
Currently
CSS Class
--
Entire Entryentry
title fieldtitle
subtitle field subtitle
I am sure their are may other CSS Classes that are hardcoded that should be
added to this list.
--
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: Maven scripts?
According to Wendy, its *much* easier to just change the structure to adopt to Maven. What I would like to do is set up a bunch of SVN externals to link everything in the manner which Maven expects. This way we can build nightlies without changing the structure that everyone else is dealing with. I figure we can experiment and see whether we can live with the reorg or not. What do you think? sean On 11/29/05, Bruno Aranda [EMAIL PROTECTED] wrote: I am fairly new to maven, but I could help with that if no one has already done the script. I am also migrating a private project to maven, so I am already dealing with this. One question is: it is the intention to maintain the current structure, or do we adapt the source tree to the conventions (eg. src/main/java, src/main/resources). IMO, we need just to provide the pom.xml files for each subproject and a general pom.xml that calls the subprojects poms... Regards, Bruno 2005/11/29, Sean Schofield [EMAIL PROTECTED]: If anyone has a Maven2 script in progress for MyFaces I would like to see it. I'm going to try and start one of my own if nobody produces one. Since I'm completely new to Maven I will be needing the help of our Maven experts. Hopefully the Tobago team and Struts lurkers will be able to help us as well ;-) I'm going to try and devote some time to this in between ApacheCon sessions ... sean
Re: Maven scripts?
I guess that we can configure the pom's in a way that the current
svn:externals remain the same. I think we could only change the
svn:externals for the current folder, having this structure:
current/pom.xml
|
+-- api/pom.xml
|
+-- share/pom.xml (?)
|
+-- impl/pom.xml
|
+-- tomahawk/pom.xml
|
+-- sandbox/pom.xml
|
+-- examples/pom.xml
|
+ simple/pom.xml
|
+ sandbox/pom.xml
examples, etc
It would easier to have again a 'share' package, but I guess we can
configure the tomahawk and impl pom's to fetch the shared sources. The
dependencies for each subproject should be defined in each pom.xml.
The root pom could have the common dependencies for all the
subprojects. I would like to hear the opinion of people who is more
used to maven for this...
#1) If we respect the current structure, it is necessary to configure
the jar artifact creation in each subproject pom in order to look for
the current sources. A set of properties might be used here, as the
relative path to sources is the same in every subproject. The
advantage is that no current element is moved. The disadvantage is
that we do not follow the conventions, thing that can imply less
stability, and more learning curve for users who have got used to
maven (eg, the resources are in the src/java folder, mixed with the
java sources)
#2) If we adapt the structure to maven, we have to move the current
sources in src/main/java folders, the resources in src/main/resources
and the test to src/test/java ... This will imply a more clear order
in the myfaces resources, but would imply an update of the svn
structure and the current ant scripts, then, a branch should be
created for security and everyone who is working on the code currenlty
should commit the changes. This way is harder, but the resulting
structure is neat.
Maybe, I would go first for #1 to get the overall idea of this and,
later, I would go for #2. In case we went for #2, I think we should
change the structure before creating a possible branch for JSF1.2...
That is just some brainstorming
Bruno
2005/11/29, Sean Schofield [EMAIL PROTECTED]:
According to Wendy, its *much* easier to just change the structure to
adopt to Maven. What I would like to do is set up a bunch of SVN
externals to link everything in the manner which Maven expects. This
way we can build nightlies without changing the structure that
everyone else is dealing with. I figure we can experiment and see
whether we can live with the reorg or not.
What do you think?
sean
On 11/29/05, Bruno Aranda [EMAIL PROTECTED] wrote:
I am fairly new to maven, but I could help with that if no one has
already done the script. I am also migrating a private project to
maven, so I am already dealing with this. One question is: it is the
intention to maintain the current structure, or do we adapt the source
tree to the conventions (eg. src/main/java, src/main/resources). IMO,
we need just to provide the pom.xml files for each subproject and a
general pom.xml that calls the subprojects poms...
Regards,
Bruno
2005/11/29, Sean Schofield [EMAIL PROTECTED]:
If anyone has a Maven2 script in progress for MyFaces I would like to
see it. I'm going to try and start one of my own if nobody produces
one. Since I'm completely new to Maven I will be needing the help of
our Maven experts. Hopefully the Tobago team and Struts lurkers will
be able to help us as well ;-)
I'm going to try and devote some time to this in between ApacheCon
sessions ...
sean
Re: Maven scripts?
On 11/29/05, Sean Schofield [EMAIL PROTECTED] wrote: According to Wendy, its *much* easier to just change the structure to adopt to Maven. What I would like to do is set up a bunch of SVN externals to link everything in the manner which Maven expects. This way we can build nightlies without changing the structure that everyone else is dealing with. I figure we can experiment and see whether we can live with the reorg or not. What do you think? Did you get Colin's m2 build files? I took a look at them and sent him some feedback, but that was a while ago. The svn:externals thing only works for directories, not individual files. If that doesn't get you far enough, take a look at the Shale m2 build experiment. I check out from svn and move everything around with a shell script: http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleMaven2 I'm sure there will be plenty of people at ApacheCon who can help. :) -- Wendy
Re: JSF 1.2
On 11/28/05, Manfred Geiler [EMAIL PROTECTED] wrote: Not really working on it yet. Just thinking and some offlinediscussing with Martin last week.Not sure, how we can easily manage this regarding SVN.One plan is to implement/integrate as much as possible in current 1.1codebase as long as it keeps it compatible to 1.1. Some 1.2 goodiesare already implemented, right?Then we should make a 1.2 branch - is that the best practice? I would think you'd want to create a branch for the older code, and keep the latest development (i.e. 1.2 enhancements) on trunk. Otherwise you need to ask yourselves what 'trunk' means, going forwards. How do other projects (eg Tomcat) start new spec implementations? The Tomcat team has incremented the major version when the Servlet spec changes. For example: Tomcat 3.x -- Servlets 2.2 Tomcat 4.x -- Servlets 2.3 Tomcat 5.0.x -- Servlets 2.4 Tomcat 5.5.x -- Servlets 2.4 with JDK 5 -- Martin Cooper One major issue with 1.2 is EL. Anybody knows about the status of theApache EL implementation? Manfred2005/11/28, Stan Silvert [EMAIL PROTECTED]: Is anyone working on JSF 1.2 for MyFaces?Anyone care to comment on the status of this effort? Thanks, Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert
Re: JSF 1.2
I would think you'd want to create a branch for the older code, and keep the latest development (i.e. 1.2 enhancements) on trunk. Otherwise you need to ask yourselves what 'trunk' means, going forwards. You're right - that would be the better way. My may point though is that we would have to branch eventually and that we want to delay that point for as long as possible since its a PITA no matter what is on the branch and what is on the trunk. Martin Cooper sean
Re: Planner Component
I don't think its been ported over to JSF yet. It doesn't appear to be in the sandbox. Check the mailing list archives for a link to some live examples. sean On 11/29/05, Paul Spencer [EMAIL PROTECTED] wrote: Jurgen, Where can I find the Panner Component? Paul Spencer
Re: org.apache.myfaces.custom.schedule.* missing svn keywords?
Ok. I see. So you added svn:keywords with a value of Date Author Id Revision HeadURL? Thanks for figuring it out and explaining it to me :) On 11/29/05, Simon Kitching [EMAIL PROTECTED] wrote: Mike Kienenberger wrote: It looks like org.apache.myfaces.custom.schedule.* is missing svn keywords. I'm not sure what the process would be to fix it. Nothing looked obvious to me from Eclipse other than add keywords, and the missing keywords weren't on the list :) From the eclipse set properties dialog, when a *file* is selected then svn:eol-style is one of the drop-down options. However you can't select recursive from there. When selecting set properties on a directory, the svn:eol-style option isn't in the dropdown list but you can still type it in directly, select the recursive option and it works fine. I've just tested this by fixing schedule props with eclipse, and verifying from the command-line before committing. Everything worked as expected - including generating massive commit messages due to the line-ending changes :-(. It looks like about 80% of the sandbox files have not got any svn properties set :-( Cheers, Simon
Re: Javadoc problems on non-ascii char
Thanks very much Matthias. There may be some alternative like ensuring all the .java files start with a UTF8 byte-order-mark or somesuch to tell the java tools that the contents of the file is unicode, not ascii. However using ss is probably the easiest solution.. Regards, Simon Matthias Wessendorf wrote: Simon, well I'll convert the german umlaut (ß) into its equal (ss) HTH, Matthias On 11/29/05, Simon Kitching [EMAIL PROTECTED] wrote: Hi, When building the javadoc I get lots of warnings reported for occurrences of Matthias Wessendorf's name, presumably because of the use of a German double-s character. [javac] /home/skitching/workdir/myfaces/current/examples/tiles/src/java/org/apache/myfaces/tiles/example/DemoActionListener.java:23: warning: unmappable character for encoding UTF8 [javac] * @author a href=mailto:[EMAIL PROTECTED]Matthias We�endorf/a Can anyone suggest how to fix this? Thanks, Simon -- Matthias Wessendorf Zülpicher Wall 12, 239 50674 Köln http://www.wessendorf.net mwessendorf-at-gmail-dot-com
Re: Maven scripts?
My thinking on the externals was that we create a folder called myfaces-maven (or something) and have externals that reorg everything in the way that Maven wants. This wouldn't be a permanent solution, just a convenient way of building the latest and greatest without copying everything outright everytime. Another idea would be to copy the repository to the test area of the SVN server (if it still exists) and then just start moving stuff around and skip the external stuff. I looked at Wendy's wiki. That is another interesting approach. Ultimately I need to know more about Maven and what it needs before I can reach a personal conclusion on which method will work best. I am hoping that we can cut down on all of the externals in the new Maven way of doing things. I like the one build to rule them all approach but its a real PITA changing the externals for all of those build dirs. Ultimately I would like the only externals to be for the TLD entities and stuff where its truly needed. OK back to my Maven research ... sean On 11/29/05, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/29/05, Sean Schofield [EMAIL PROTECTED] wrote: According to Wendy, its *much* easier to just change the structure to adopt to Maven. What I would like to do is set up a bunch of SVN externals to link everything in the manner which Maven expects. This way we can build nightlies without changing the structure that everyone else is dealing with. I figure we can experiment and see whether we can live with the reorg or not. What do you think? Did you get Colin's m2 build files? I took a look at them and sent him some feedback, but that was a while ago. The svn:externals thing only works for directories, not individual files. If that doesn't get you far enough, take a look at the Shale m2 build experiment. I check out from svn and move everything around with a shell script: http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleMaven2 I'm sure there will be plenty of people at ApacheCon who can help. :) -- Wendy
UIComponent tag (attn: Manfred Geiler)
Hi Manfred, A long time ago class UIComponentTag was altered so that _id, _binding and _rendered were only cleared in release, not in internalRelease. Commit r166747 (by manolito) indicates that it was something to do with Resin. I believe manolito is you... Do you have any more info about this? There isn't any actual bug caused by this AFAIK, but it does seem very odd not to reset these fields even when the tag is going to be reused by the container. It would be nice to document exactly *why* this is needed. Thanks, Simon
Re: JSF 1.2
That's what I was afraid of. Presumably the deprecated stuff will be dropped in the next spec? sean On 11/29/05, Adam Winer [EMAIL PROTECTED] wrote: On 11/29/05, Sean Schofield [EMAIL PROTECTED] wrote: I have a question regarding the new EL. Does the old EL have to be supported still? It seems like a bunch of methods are *deprecated* but not removed. That's certainly going to complicate things in the interim. Sadly, the rules we work under require complete API compatibility. We can deprecate methods, but we can't remove them. I'd like nothing more than to kill the old APIs (and make some other changes, too), but it's just not in the cards. The EL side of things isn't actually that bad, since the old APIs can all be implemented in terms of the new ones in a rather straightforward fashion. The real ugliness is in supporting the old and new state manager APIs - now *that* is painful. -- Adam
Re: Re: JSF 1.2
The JSF API from Sun does have a lot of 'Wrapper' objects that can be used to ease this transition between EL versions. Adam Winer [EMAIL PROTECTED] wrote on 11/29/2005, 10:22:35 PM: On 11/29/05, Sean Schofield wrote: I have a question regarding the new EL. Does the old EL have to be supported still? It seems like a bunch of methods are *deprecated* but not removed. That's certainly going to complicate things in the interim. Sadly, the rules we work under require complete API compatibility. We can deprecate methods, but we can't remove them. I'd like nothing more than to kill the old APIs (and make some other changes, too), but it's just not in the cards. The EL side of things isn't actually that bad, since the old APIs can all be implemented in terms of the new ones in a rather straightforward fashion. The real ugliness is in supporting the old and new state manager APIs - now *that* is painful. -- Adam
Re: [jira] Commented: (MYFACES-882) CommandLink doesn't work if javascript is disabled
Sean, I agree 100% with you - I don't understand the horror of using Javascript. One truly horrific development is that in the name of webapp accessibility (a very good thing), some standards boards are trying to claim that an app has to function without Javascript to be accessible, which is utter nonsense. In regards to the bug here, the JSF 1.2 spec is explicit that commandLink *can* use Javascript, and other components (in the standard set, of course) may not. So this is not a bug. -- Adam On 11/29/05, Sean Schofield [EMAIL PROTECTED] wrote: Al, My rant wasn't really directed at you personally. It's just that I've seen this complaint from users over and over on different mailing lists and forums. These users are *intentionally* trying to develop complex webapps without javascript. I just can't understand why anybody would bother. And if you were forced to do this by a client, you would be limited in the sophistication that you could achieve so why bother with JSF? sean On 11/29/05, Alberto Molpeceres [EMAIL PROTECTED] wrote: It isn't that I was concerned. It's just that I had disabled it (just testing), and JSF didn't help me to find the error. In fact, often MyFaces (or JSF in general) doesn't help very much to find errors, altough they could be clearly mine like in this case. If you make a mistake I would expect MyFaces to tell me, not just write something that doesn't work. My apologies. al. On 11/28/05, Sean Schofield [EMAIL PROTECTED] wrote: I can't understand for the life of me why someone would write a webapp that was complicated enough to justify JSF and still be concerned about browsers that don't support javascript. I'm sure there are some scenarios out there but if you can't count on javascript being enabled then IMO, you shouldn't be wasting your time with the overhead and complexities of JSF. Just use Struts or something simpler. sean On 11/28/05, Mike Kienenberger [EMAIL PROTECTED] wrote: JSF isn't designed to handle GET requests, so just modifying the link wouldn't be sufficient. In any case, the parameters generated would be far too large :) Take a look at a JSF form submit sometime. The idea of providing an error if you try to use JSF without javascript isn't a bad one. I'm not sure what to suggest, though. I don't think rendering a message stating that you can't use links without javascript is the best solution. Perhaps the server should simply throw a FacesException if someone attempts to render a component that requires javascript, and the parameter is set to false. Maybe some of the other committers can comment on this. On 11/28/05, Alberto Molpeceres [EMAIL PROTECTED] wrote: On 11/28/05, Mike Kienenberger (JIRA) dev@myfaces.apache.org wrote: [ http://issues.apache.org/jira/browse/MYFACES-882?page=comments#action_12358688 ] Mike Kienenberger commented on MYFACES-882: --- Well, we can discuss it on the mailing lists, but the short answer is that javascript is required to make the link submit the form. Normal anchor tags can't submit forms, so the anchor tag has to use javascript to click a submit button. Hi Mike. I was just wondering, why something to simply should need javascript. I mean, why not simply add all needed parameters to the link?. Or if really that's not possible, it would be better just write a message like don't use commandLink with js disabled instead of just rendering a broken link. Don't get me worng, I know it's my failure if I don't know what the specification says, only I have lost around three hours looking for a solution and am a bit frustrated. al. -- Alberto Molpeceres alberto.molpeceres @ linkingpaths.com (+34) 661 304 614 Linking Paths Francisco Maciá 11, 7º - 48014 Bilbao (+34) 944 764 328 http://www.linkingpaths.com
Re: svn commit: r349809 - /myfaces/sandbox/trunk/tld/myfaces_sandbox.tld
Simon, I had to merge in the myfaces_sandbox.tld file changes I made, and it looks like it may have missed some of your whitespace changes. Sorry about that, but it's very difficult under Windows to detect whitespace changes, since SVN whitespace differs from the checked-out whitespace due to all of the EOL differences. If it's not easy for you to reapply the change, let me know, and I'll try to figure out a fix tomorrow. On 11/29/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: skitching Date: Tue Nov 29 13:05:18 2005 New Revision: 349809 URL: http://svn.apache.org/viewcvs?rev=349809view=rev Log: Convert tabs to spaces only Modified: myfaces/sandbox/trunk/tld/myfaces_sandbox.tld Modified: myfaces/sandbox/trunk/tld/myfaces_sandbox.tld URL: http://svn.apache.org/viewcvs/myfaces/sandbox/trunk/tld/myfaces_sandbox.tld?rev=349809r1=349808r2=349809view=diff == --- myfaces/sandbox/trunk/tld/myfaces_sandbox.tld (original) +++ myfaces/sandbox/trunk/tld/myfaces_sandbox.tld Tue Nov 29 13:05:18 2005 @@ -143,7 +143,7 @@ body-contentempty/body-content display-namePlanner component/display-name description - A meeting planner component, similar to the ones found in Outlook or Evolution. + A meeting planner component, similar to the ones found in Outlook or Evolution. /description ui_component_attributes; ui_schedule_attributes; @@ -151,15 +151,15 @@ /tag - !-- schedule -- - tag + !-- schedule -- + tag nameschedule/name tag-classorg.apache.myfaces.custom.schedule.ScheduleTag/tag-class body-contentempty/body-content display-nameSchedule component/display-name description -A schedule component similar to the ones found in Outlook or Evolution - /description + A schedule component similar to the ones found in Outlook or Evolution + /description ui_component_attributes; ui_command_attributes; ui_schedule_attributes; @@ -173,7 +173,7 @@ body-contentJSP/body-content description Provides an input textbox with suggest functionality, using a remote connection to the server. - The difference to inputSuggest is that a custom drop down is rendered. +The difference to inputSuggest is that a custom drop down is rendered. /description standard_input_text_attributes; ext_forceId_attribute; @@ -183,10 +183,10 @@ user_role_attributes; attribute - namesize/name - requiredfalse/required - rtexprvaluefalse/rtexprvalue - typejava.lang.String/type +namesize/name +requiredfalse/required +rtexprvaluefalse/rtexprvalue +typejava.lang.String/type /attribute attribute @@ -321,9 +321,10 @@ tag-classorg.apache.myfaces.custom.urlvalidator.ValidateUrlTag/tag-class body-contentJSP/body-content description - A custom validator for url format, based upons Jakarta Commons. + A custom validator for url format, based upons Jakarta Commons. /description /tag + !-- Validator for isbn codes -- tag namevalidateISBN/name @@ -333,6 +334,7 @@ A custom validator for isbn codes, based upons Jakarta Commons. /description /tag + !-- autoUpdateDataTable -- tag nameautoUpdateDataTable/name @@ -487,13 +489,13 @@ /tag !-- Converter for Boolean values -- - tag - nameconvertBoolean/name - tag-classorg.apache.myfaces.custom.convertboolean.ConvertBooleanTag/tag-class - display-nameBoolean Converter/display-name - description - Converts a boolean to custom format (yes/no), (1/0), etc. - /description +tag +nameconvertBoolean/name + tag-classorg.apache.myfaces.custom.convertboolean.ConvertBooleanTag/tag-class +display-nameBoolean Converter/display-name +description +Converts a boolean to custom format (yes/no), (1/0), etc. +/description attribute nametrueValue/name @@ -506,15 +508,15 @@ requiredfalse/required descriptionValue representing a boolean false, e.g. FALSE, no, 0, etc./description /attribute - /tag +/tag tag - nameconvertDateTime/name - tag-classorg.apache.myfaces.custom.convertDateTime.ConvertDateTimeTag/tag-class - display-nameDateTime Converter/display-name - description - Convert
Re: Maven scripts?
I agree that we probably will just reorg to comply with Maven (should we vote to go forward.) I have a question about Maven website building. It looks like our subprojects match up pretty nicely with the Maven module concept but I'm wondering what the final website will look like. Is it possible to link modules into your top level module and site? It looks like maybe you can from what the Struts team has done. There are certain items that I think should be generated at the top project level (list of contributors, mailing lists, issue tracking, etc.) Then there are other items that would be nice to have at the subproject level (javadocs, general overview and unit tests.) What are the options with Maven as far as this goes? sean On 11/29/05, Bruno Aranda [EMAIL PROTECTED] wrote: +1 For making a copy of the repository, move things and start playing (Wendy's script is also good idea). Although it is needed more effort now it would be easier to maintain in the future... I would create the new mavenized structure and, when we are happing with it, make the head adopt the new structure, Bruno 2005/11/29, Sean Schofield [EMAIL PROTECTED]: My thinking on the externals was that we create a folder called myfaces-maven (or something) and have externals that reorg everything in the way that Maven wants. This wouldn't be a permanent solution, just a convenient way of building the latest and greatest without copying everything outright everytime. Another idea would be to copy the repository to the test area of the SVN server (if it still exists) and then just start moving stuff around and skip the external stuff. I looked at Wendy's wiki. That is another interesting approach. Ultimately I need to know more about Maven and what it needs before I can reach a personal conclusion on which method will work best. I am hoping that we can cut down on all of the externals in the new Maven way of doing things. I like the one build to rule them all approach but its a real PITA changing the externals for all of those build dirs. Ultimately I would like the only externals to be for the TLD entities and stuff where its truly needed. OK back to my Maven research ... sean On 11/29/05, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/29/05, Sean Schofield [EMAIL PROTECTED] wrote: According to Wendy, its *much* easier to just change the structure to adopt to Maven. What I would like to do is set up a bunch of SVN externals to link everything in the manner which Maven expects. This way we can build nightlies without changing the structure that everyone else is dealing with. I figure we can experiment and see whether we can live with the reorg or not. What do you think? Did you get Colin's m2 build files? I took a look at them and sent him some feedback, but that was a while ago. The svn:externals thing only works for directories, not individual files. If that doesn't get you far enough, take a look at the Shale m2 build experiment. I check out from svn and move everything around with a shell script: http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleMaven2 I'm sure there will be plenty of people at ApacheCon who can help. :) -- Wendy
Re: svn commit: r349809 - /myfaces/sandbox/trunk/tld/myfaces_sandbox.tld
Mike Kienenberger wrote: Simon, I had to merge in the myfaces_sandbox.tld file changes I made, and it looks like it may have missed some of your whitespace changes. Sorry about that, but it's very difficult under Windows to detect whitespace changes, since SVN whitespace differs from the checked-out whitespace due to all of the EOL differences. If it's not easy for you to reapply the change, let me know, and I'll try to figure out a fix tomorrow. Thanks for letting me know. It's pretty much a search-and-replace so I've just reapplied the changes. However SVN handles whitespace cross-platform issues nicely in my experience. I can understand problems updating when someone has changed the svn:eol-style property on the file, but I don't know why you're experiencing problems with normal whitespace changes. I hope you can figure it out... Cheers, Simon
[jira] Updated: (MYFACES-887) javax.servlet.ServletException: text name must not be null when subtitle = null in DAY mode
[ http://issues.apache.org/jira/browse/MYFACES-887?page=all ] Jurgen Lust updated MYFACES-887: Attachment: myfaces-887.patch this should fix the problem: the renderer now checks if title or subtitle are null javax.servlet.ServletException: text name must not be null when subtitle = null in DAY mode - Key: MYFACES-887 URL: http://issues.apache.org/jira/browse/MYFACES-887 Project: MyFaces Type: Bug Components: Sandbox Versions: 1.1.1 Reporter: Paul Spencer Attachments: myfaces-887.patch When the schedule is in DAY mode, an entry with getSubtitle() == null causes the following error returned javax.faces.FacesException: text name must not be null org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:421) org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234) org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:352) javax.faces.webapp.FacesServlet.service(FacesServlet.java:107) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122) A portion of the stack trace from the log file is below, but I believe the resolution is to only write the subtitle if it is not null in ScheduleDetailedDayRenderer.java around line 505. From localhost.log SEVERE: Servlet.service() for servlet jsp threw exception java.lang.NullPointerException: text name must not be null at org.apache.myfaces.renderkit.html.HtmlResponseWriterImpl.writeText(HtmlResponseWriterImpl.java:421) at org.apache.myfaces.custom.schedule.renderer.ScheduleDetailedDayRenderer.writeEntries(ScheduleDetailedDayRenderer.java:505) at org.apache.myfaces.custom.schedule.renderer.ScheduleDetailedDayRenderer.encodeChildren(ScheduleDetailedDayRenderer.java:117) at org.apache.myfaces.custom.schedule.renderer.ScheduleDelegatingRenderer.encodeChildren(ScheduleDelegatingRenderer.java:75) at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:319) at org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:444) at org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427) at org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:448) at org.apache.myfaces.renderkit.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:203) at org.apache.myfaces.renderkit.html.HtmlGridRendererBase.encodeEnd(HtmlGridRendererBase.java:85) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331) at javax.faces.webapp.UIComponentTag.encodeEnd(UIComponentTag.java:349) at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:253) at org.apache.myfaces.taglib.UIComponentBodyTagBase.doEndTag(UIComponentBodyTagBase.java:55) -- 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: svn commit: r349809 - /myfaces/sandbox/trunk/tld/myfaces_sandbox.tld
Mike Kienenberger wrote: I think the problem is that compares against SVN aren't taking EOL into account. The file in Eclipse on my windows box has windows line-endings, and the file being compared against in the repository has unix (native) line-endings. Whatever the reason, diffs in Eclipse on Windows show every line as different until ignore whitespace is chosen. Well, I don't know if this qualifies as good news or bad news, but that is not normal behaviour; there's something wrong with your setup. Perhaps you're using the synchronize with repository option in eclipse and explicitly accepting the changes rather than selecting the update option? The svn:eol-style property was fixed by me on Nov 25. I wouldn't be surprised if synchronize doesn't correctly handle svn property changes; it's given workmates repeated problems of various sorts. Regards, Simon
[jira] Commented: (MYFACES-888) Classes for Schedule Entry, Title, and Subtitle should be optional parameters to the tag.
[ http://issues.apache.org/jira/browse/MYFACES-888?page=comments#action_12358857 ] Jurgen Lust commented on MYFACES-888: - I agree the css class should be an optional parameter of the component tag. In fact i will get to it as soon as I can. Classes for Schedule Entry, Title, and Subtitle should be optional parameters to the tag. - Key: MYFACES-888 URL: http://issues.apache.org/jira/browse/MYFACES-888 Project: MyFaces Type: Improvement Components: Sandbox Versions: 1.1.1 Reporter: Paul Spencer CSS Class for the Schedule Component are hardcoded. I sugget they should be optional parameters to the tag. Currently CSS Class -- Entire Entryentry title fieldtitle subtitle field subtitle I am sure their are may other CSS Classes that are hardcoded that should be added to this list. -- 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: svn commit: r349852 - /myfaces/build/trunk/build.xml [ATTN: Mike Kienenberger]
Yeah, looks like SVN commits work differently than CVS commits in Subclipse.In SVN, you have to manually reselect each new file to commit them. How annoying. On 11/29/05, Mike Kienenberger [EMAIL PROTECTED] wrote: Thanks, Simon. That's the third time Eclipse Subversion has claimed to commit a new file and failed to do so. Maybe you are correct when you say that the Synchronize view is defective with SVN. On 11/29/05, Simon Kitching [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Author: skitching Date: Tue Nov 29 16:45:46 2005 New Revision: 349852 URL: http://svn.apache.org/viewcvs?rev=349852view=rev Log: Validate generated DTD files Modified: myfaces/build/trunk/build.xml The build.xml now validates the generated .tld file against the DTD. This has shown up a mistake in recent commits re the sandbox focus and validateCompareTo component entity references to files that don't exist. As a result, the build now fails. Mike, if you can fix these component problems soon that would be great. If nothing happens in the next few hours, I'll commit a change to the sandbox tld file to comment out these components so the build at least works. And of course the build.xml changes should prevent any such problems from ever occurring in future [though it won't stop all tld generation problems; I'm still waiting for feedback from the ant list re references to undefined entities). Cheers, Simon
[jira] Commented: (MYFACES-743) Javascript conflict between x:tree2 and x:inputCalendar
[
http://issues.apache.org/jira/browse/MYFACES-743?page=comments#action_12358862
]
Shane Bryzak commented on MYFACES-743:
--
I found a bug in the CookieLib_setCookie method in cookielib.js - the following
test:
if (value != undefined value != null value != )
does not take into account that the Array prototype may contain additional
functions. For example, if I have some javascript as follows which adds a
contains method to Array:
Array.prototype.contains = function (element)
{
for (var i = 0; i this.length; i++)
{
if (this[i] == element)
return true;
}
return false;
};
the for loop in CookieLib_setCookie will include contains (the name of my
additional method) and the value returned from the array will be a function
pointer, not a string. The solution for this is to test the type of the value
returned from the array:
if (value != undefined value != null value != typeof(value)
!= function)
I'll attach a diff to correct this.
Javascript conflict between x:tree2 and x:inputCalendar
---
Key: MYFACES-743
URL: http://issues.apache.org/jira/browse/MYFACES-743
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: 1.1.1
Reporter: Luciano Medina
I have a x:tree2 component with client-side toggling. When I add a
x:inputCalendar with the attribute renderAsPopup=true, the node toggling
links of the tree stop working and I get the following Javascript error:
Error: value.indexOf is not a function
Source file:
[...]/org.apache.myfaces.custom.tree2.HtmlTreeRenderer/11297774/javascript/cookielib.js
Line: 108
This bug was not present on version 1.0.9m9
--
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-743) Javascript conflict between x:tree2 and x:inputCalendar
[ http://issues.apache.org/jira/browse/MYFACES-743?page=all ] Shane Bryzak updated MYFACES-743: - Attachment: cookielib.js.diff Patch for myfaces/custom/tree2/resources/javascript/cookielib.js Javascript conflict between x:tree2 and x:inputCalendar --- Key: MYFACES-743 URL: http://issues.apache.org/jira/browse/MYFACES-743 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.1.1 Reporter: Luciano Medina Attachments: cookielib.js.diff I have a x:tree2 component with client-side toggling. When I add a x:inputCalendar with the attribute renderAsPopup=true, the node toggling links of the tree stop working and I get the following Javascript error: Error: value.indexOf is not a function Source file: [...]/org.apache.myfaces.custom.tree2.HtmlTreeRenderer/11297774/javascript/cookielib.js Line: 108 This bug was not present on version 1.0.9m9 -- 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: svn commit: r349852 - /myfaces/build/trunk/build.xml [ATTN: Mike Kienenberger]
Hi Mike, Mike Kienenberger wrote: Yeah, looks like SVN commits work differently than CVS commits in Subclipse.In SVN, you have to manually reselect each new file to commit them. How annoying. In CVS, when a file is added, it is immediately committed to the repository. However SVN has this concept of atomic commits, where multiple changes to a repository can happen as one transaction. So adding a file can't immediately change the repository; that would give the user no chance to group this operation with other operations. For this reason, svn add just marks the new file locally. Later a commit is done which can involve multiple files, and all changes are within a single transaction. But yes, when adding only one file, it does mean making two operations: add then commit, which can be annoying. Cheers, Simon
[proposal] myfaces-core.jar
I wanted to resurrect one of our favorite threads ... Should the shared code be in its own jar? The reason why I bring this up now is that I'm starting to experiment with an M2 build for MyFaces. In addition to some of the arguments made earlier we can now add Maven to the list of reasons why we might want to consider this. From my early exploration of Maven it seems like the shared stuff can be handled best by making the impl and tomahawk subprojects have a dependency on the share project. In the past I have not been too wild about the shared jar idea but I think Maven may be able to help keep us and our users informed as to the exact dependencies when using MyFaces or Tomahawk. First off, I would suggest we call it *core* instead of share. I think core helps to imply that it is mandatory. They already know they need api and impl (if they have read the JSF spec.) The core wording will let them know they need this also. Maven has some cool stuff for maintaining and documenting dependencies. The tomahawk page of the website can automatically be updated so that for each new release of tomahawk, the dependency list will be updated. Its also possible that we can have tomahawk depend on an earlier version of the core then the impl. So we can compile against older versions that might be in the third party J2EE distros (like JBoss). Anyways, the point is that Maven may finally provide the best solution to this problem so far. Thoughts? sean
Re: [proposal] myfaces-core.jar
I think that's an excellent idea, since drawing those lines in the codebase would hopefully encourage levels of separation and increase compatability of your JSF implementation with other frameworks and components. Sean Schofield wrote: I wanted to resurrect one of our favorite threads ... Should the shared code be in its own jar? The reason why I bring this up now is that I'm starting to experiment with an M2 build for MyFaces. In addition to some of the arguments made earlier we can now add Maven to the list of reasons why we might want to consider this. From my early exploration of Maven it seems like the shared stuff can be handled best by making the impl and tomahawk subprojects have a dependency on the share project. In the past I have not been too wild about the shared jar idea but I think Maven may be able to help keep us and our users informed as to the exact dependencies when using MyFaces or Tomahawk. First off, I would suggest we call it *core* instead of share. I think core helps to imply that it is mandatory. They already know they need api and impl (if they have read the JSF spec.) The core wording will let them know they need this also. Maven has some cool stuff for maintaining and documenting dependencies. The tomahawk page of the website can automatically be updated so that for each new release of tomahawk, the dependency list will be updated. Its also possible that we can have tomahawk depend on an earlier version of the core then the impl. So we can compile against older versions that might be in the third party J2EE distros (like JBoss). Anyways, the point is that Maven may finally provide the best solution to this problem so far. Thoughts? sean -- Jacob Hookom - Minneapolis -- http://hookom.blogspot.com
Re: [proposal] myfaces-core.jar
I also wasn't fond of yet another myfaces.jar, but I think the advantages of releasing different versions of Tomahawk and Impl make up for it. At some point, Impl should become stable and mature, but hopefully tomahawk is going to constantly change and grow. I don't think Impl and Tomahawk should have the same release cycles indefinitely. As an end-user I also like having the ability to upgrade either one separately. On 11/29/05, Sean Schofield [EMAIL PROTECTED] wrote: I wanted to resurrect one of our favorite threads ... Should the shared code be in its own jar? The reason why I bring this up now is that I'm starting to experiment with an M2 build for MyFaces. In addition to some of the arguments made earlier we can now add Maven to the list of reasons why we might want to consider this. From my early exploration of Maven it seems like the shared stuff can be handled best by making the impl and tomahawk subprojects have a dependency on the share project. In the past I have not been too wild about the shared jar idea but I think Maven may be able to help keep us and our users informed as to the exact dependencies when using MyFaces or Tomahawk. First off, I would suggest we call it *core* instead of share. I think core helps to imply that it is mandatory. They already know they need api and impl (if they have read the JSF spec.) The core wording will let them know they need this also. Maven has some cool stuff for maintaining and documenting dependencies. The tomahawk page of the website can automatically be updated so that for each new release of tomahawk, the dependency list will be updated. Its also possible that we can have tomahawk depend on an earlier version of the core then the impl. So we can compile against older versions that might be in the third party J2EE distros (like JBoss). Anyways, the point is that Maven may finally provide the best solution to this problem so far. Thoughts? sean
[jira] Closed: (MYFACES-887) javax.servlet.ServletException: text name must not be null when subtitle = null in DAY mode
[ http://issues.apache.org/jira/browse/MYFACES-887?page=all ] sean schofield closed MYFACES-887: -- Fix Version: Nightly Resolution: Fixed javax.servlet.ServletException: text name must not be null when subtitle = null in DAY mode - Key: MYFACES-887 URL: http://issues.apache.org/jira/browse/MYFACES-887 Project: MyFaces Type: Bug Components: Sandbox Versions: 1.1.1 Reporter: Paul Spencer Fix For: Nightly Attachments: myfaces-887.patch When the schedule is in DAY mode, an entry with getSubtitle() == null causes the following error returned javax.faces.FacesException: text name must not be null org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:421) org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234) org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:352) javax.faces.webapp.FacesServlet.service(FacesServlet.java:107) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122) A portion of the stack trace from the log file is below, but I believe the resolution is to only write the subtitle if it is not null in ScheduleDetailedDayRenderer.java around line 505. From localhost.log SEVERE: Servlet.service() for servlet jsp threw exception java.lang.NullPointerException: text name must not be null at org.apache.myfaces.renderkit.html.HtmlResponseWriterImpl.writeText(HtmlResponseWriterImpl.java:421) at org.apache.myfaces.custom.schedule.renderer.ScheduleDetailedDayRenderer.writeEntries(ScheduleDetailedDayRenderer.java:505) at org.apache.myfaces.custom.schedule.renderer.ScheduleDetailedDayRenderer.encodeChildren(ScheduleDetailedDayRenderer.java:117) at org.apache.myfaces.custom.schedule.renderer.ScheduleDelegatingRenderer.encodeChildren(ScheduleDelegatingRenderer.java:75) at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:319) at org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:444) at org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427) at org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:448) at org.apache.myfaces.renderkit.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:203) at org.apache.myfaces.renderkit.html.HtmlGridRendererBase.encodeEnd(HtmlGridRendererBase.java:85) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331) at javax.faces.webapp.UIComponentTag.encodeEnd(UIComponentTag.java:349) at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:253) at org.apache.myfaces.taglib.UIComponentBodyTagBase.doEndTag(UIComponentBodyTagBase.java:55) -- 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-881) TLD tranformations break build
[ http://issues.apache.org/jira/browse/MYFACES-881?page=comments#action_12358884 ] Dennis Byrne commented on MYFACES-881: -- Thanks. Trunk builds fine for me now. TLD tranformations break build -- Key: MYFACES-881 URL: http://issues.apache.org/jira/browse/MYFACES-881 Project: MyFaces Type: Bug Components: General Versions: Nightly Environment: checkout from nov. 26 - problem persists after update on nov. 27 Reporter: Dennis Byrne Priority: Critical Attachments: align_singular.txt, impl.tld.nov.26.05.txt, sandbox.tld.nov.26.05.txt, tomahawk.tld.nov.26.05.txt There are about 20 transformation errors that occur in the build process. This affects the TLDs for impl, tomahawk and the sandbox. The following patches stop the build errors. The tests still need to be run. -- 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
