Re: Broken Link on Download Page
2005/9/20, Manfred Geiler <[EMAIL PROTECTED]>: Craig,Thanks. Just fixed it in SVN.Sean, can you please update the site (or tell me how I can do it)? Thanks. -Manfred2005/9/20, Craig McClanahan <[EMAIL PROTECTED]>:> The MD5 link for the new release points at:>>> http://www.apache.org/dist/myfaces/binaries/myfaces-1.1.0.tgz.md5>> but it should really point at:>>> http://www.apache.org/dist/myfaces/binaries/myfaces-1.1.0.tar.gz.md5>> Craig>>-- fancy ^_^
Re: [ANNOUNCE] Facelets Part 2: Using Facelets
Thanks Kito. Can't wait to read the next in the trenches installment. I enjoyed the last one. sean On 9/22/05, Kito D. Mann <[EMAIL PROTECTED]> wrote: > Hello, > > I just wanted to announce another new article at JSF Central about Facelets. > This is the second of a series of articles about Facelets. In this article, > Facelets founder Jacob Hookom explains how you can begin using Facelets in > your JSF applications today. Here's an excerpt: > > "Facelets is implemented as a JSF ViewHandler, which can be easily > configured in your application. Simply make sure the Facelets JAR > (jsf-facelets.jar) is in your project's classpath and add a single > modification to your faces-config.xml: > > > > > com.sun.facelets.FaceletViewHandler > > " > > Read the rest of the article here: > http://www.jsfcentral.com/articles/facelets_2.html. > > ~~~ > Kito D. Mann ([EMAIL PROTECTED]) > Principal Consultant, Virtua, Inc. (http://www.virtua.com) Author, > JavaServer Faces in Action > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info > > Are you using JSF in a project? Send your story to [EMAIL PROTECTED], > and you could get your story published and win a free copy of JavaServer > Faces in Action! > >
[jira] Commented: (MYFACES-444) HtmlMessageRendererBase renders tooltip as message summary rather than detail
[
http://issues.apache.org/jira/browse/MYFACES-444?page=comments#action_12330247
]
Ken Weiner commented on MYFACES-444:
Sure, I will give it a shot as long as you don't mind waiting a week or so.
> HtmlMessageRendererBase renders tooltip as message summary rather than detail
> -
>
> Key: MYFACES-444
> URL: http://issues.apache.org/jira/browse/MYFACES-444
> Project: MyFaces
> Type: Bug
> Components: Implementation
> Versions: 1.0.9m9
> Reporter: Ken Weiner
> Assignee: Martin Marinschek
>
> The tooltip attribute description on
> http://java.sun.com/j2ee/javaserverfaces/1.1/docs/tlddocs/h/message.html says
> that the tooltip content should be composed of the message detail text.
> However, the tooltip content in MyFaces is getting set to the message summary
> text. This happens in HtmlMessageRendererBase in the
> renderSingleFacesMessage() method. The code sets the title to the summary if
> the tooltip is enabled. Otherwise it uses the title attribute:
> String summary = getSummary(facesContext, message, facesMessage,
> messageClientId);
> String detail = getDetail(facesContext, message, facesMessage,
> messageClientId);
> String title = getTitle(message);
> boolean tooltip = isTooltip(message);
> if (title == null && tooltip)
> {
> title = summary;
> }
> Instead it should use the detail as follows:
> String summary = getSummary(facesContext, message, facesMessage,
> messageClientId);
> String detail = getDetail(facesContext, message, facesMessage,
> messageClientId);
> String title = getTitle(message);
> boolean tooltip = isTooltip(message);
> if (title == null && tooltip)
> {
> title = detail;
> }
> It might be argued that the tooltip should be set to the detail regardless of
> whether the title attribute is set at all since the description of the title
> attribute is "Advisory title information about markup elements generated for
> this component." If that is the case then the code should look like this:
> String summary = getSummary(facesContext, message, facesMessage,
> messageClientId);
> String detail = getDetail(facesContext, message, facesMessage,
> messageClientId);
> String title = getTitle(message);
> boolean tooltip = isTooltip(message);
> if (tooltip)
> {
> title = detail;
> }
--
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-599) Potential NullPointerException from HtmlResponseWriterImpl.writeAttribute()
[
http://issues.apache.org/jira/browse/MYFACES-599?page=comments#action_12330243
]
Adam Winer commented on MYFACES-599:
The correct behavior (which the spec should state, but doesn't) is to render
nothing, but also not log a warning.
Without this, you get zillions of lines of code like:
if (someAttr != null)
writer.writeAttribute("someAttr", someAttr, "someAttr");
... which is a pain, so it's easier to just centralize that code in the
ResponseWriter and make Renderers simpler to write.
> Potential NullPointerException from HtmlResponseWriterImpl.writeAttribute()
> ---
>
> Key: MYFACES-599
> URL: http://issues.apache.org/jira/browse/MYFACES-599
> Project: MyFaces
> Type: Bug
> Versions: 1.1.0
> Environment: Any
> Reporter: Kris Nuttycombe
>
> org.apache.myfaces.renderkit.html.HtmlResponseWriterImpl.writeAttribute() can
> throw a NullPointerException if the value passed for the attribute value is
> null because of a call to value.toString(). I'm not sure what the correct
> failure-tolerant behavior would be - the method throws NullPointerException
> explicitly with a detail message if the name is null, but the value being
> null is a common enough occurrance that the method should either:
> * Render an empty string as the value of the attribute
> * Return without rendering the attribute at all and log a warning
> I will provide a patch to supply whatever functionality is deemed
> appropriate, if desired.
--
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-164) Server-side state should be held
[ http://issues.apache.org/jira/browse/MYFACES-164?page=comments#action_12330237 ] Mehmet Sen commented on MYFACES-164: RI doesn't have this problem. The problem does not only require double submission, but rewriting of all form values (changes) again before the second submission. Also, repetitive refreshing of a page (in the sample tiles example) is always switching between the last two pages, page1-->page2-->page1,... I read this somewhere: "MyFaces currently only holds the last view in the session, while by default the JSF RI will hold up to 15 serialized views in the session." Please fix this, thank you. > Server-side state should be held > > > Key: MYFACES-164 > URL: http://issues.apache.org/jira/browse/MYFACES-164 > Project: MyFaces > Type: Improvement > Versions: 1.0.9m9 > Environment: WindowsXP SP2;J2SE1.4.2_07;Tomcat4.1.31 > Reporter: yamo > Priority: Critical > > "When I navigate back to a form that has previously been submitted, using the > browser back button, I need to click the submit button twice in order for the > form to actually resubmit". > In the mailing list (myfaces-user at 15 Nov 2004), Manfred said "This problem > does not exist for client-side state saving". > To be sure, it seems work correctly, but client-side state saving have > security problems. > Client-side state is non encrypted data, so users can see the state, and > tamper with it. > It is necessary to hold sever-side state like JSF-RI 1.1_01 to use MyFaces > for secure application. -- 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: tags, branches and 'current'
On Thu, 22 Sep 2005, Bill Dudney wrote: Well the idea is that people would then be using current/trunk to checkout instead of just current. But by definition, what's in branches and tags is not current, so why does it make sense to include them under 'current'? The structure you described is exactly what you have without using the 'current' external in the first place, isn't it? -- Martin Cooper TTFN, -bd- On Sep 22, 2005, at 12:31 PM, Martin Cooper wrote: On Thu, 22 Sep 2005, Bill Dudney wrote: Hi All, I'd like to propose that we change current to be; current /branches /tags /trunk Still all externals but tracking the group of tags & branches that are common across all the subprojects. current/trunk -> becomes what we currently call current current/branches -> currently empty current/tags -> 1_1_0 with externals to each subproject's 1_1_0 tag I would recommend against doing that. It would mean that everyone checking out 'current' would end up with multiple copies of the entire source tree, which is unlikely to be something that they would want. Most people are unlikely to want more than one version of the source at any given time, so I don't see a need to clump together multiple versions in a single checkout. -- Martin Cooper To fix the faces-config.xml bug that's been identified in the 1_1_0 release we can create a branch in current/branches/1_1_0 that uses externals to the tags for everything but 'build' which would point to the 1_1_0 branch in build (not yet created but I'd be glad to do that). Thoughts? TTFN, -bd-
[ANNOUNCE] Facelets Part 2: Using Facelets
Hello, I just wanted to announce another new article at JSF Central about Facelets. This is the second of a series of articles about Facelets. In this article, Facelets founder Jacob Hookom explains how you can begin using Facelets in your JSF applications today. Here's an excerpt: "Facelets is implemented as a JSF ViewHandler, which can be easily configured in your application. Simply make sure the Facelets JAR (jsf-facelets.jar) is in your project's classpath and add a single modification to your faces-config.xml: com.sun.facelets.FaceletViewHandler " Read the rest of the article here: http://www.jsfcentral.com/articles/facelets_2.html. ~~~ Kito D. Mann ([EMAIL PROTECTED]) Principal Consultant, Virtua, Inc. (http://www.virtua.com) Author, JavaServer Faces in Action http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info Are you using JSF in a project? Send your story to [EMAIL PROTECTED], and you could get your story published and win a free copy of JavaServer Faces in Action!
[jira] Updated: (MYFACES-607) t:inputFileUpload shown as t:fileUpload in web docs
[ http://issues.apache.org/jira/browse/MYFACES-607?page=all ] Mike Kienenberger updated MYFACES-607: -- Attachment: fileUpload.xdocs.patch.txt Changed name from t:fileUpload to t:inputFileUpload > t:inputFileUpload shown as t:fileUpload in web docs > --- > > Key: MYFACES-607 > URL: http://issues.apache.org/jira/browse/MYFACES-607 > Project: MyFaces > Type: Bug > Components: Tomahawk > Versions: Nightly Build > Reporter: Mike Kienenberger > Priority: Minor > Attachments: fileUpload.xdocs.patch.txt > > t:inputFileUpload shown as t:fileUpload in web docs -- 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-607) t:inputFileUpload shown as t:fileUpload in web docs
t:inputFileUpload shown as t:fileUpload in web docs --- Key: MYFACES-607 URL: http://issues.apache.org/jira/browse/MYFACES-607 Project: MyFaces Type: Bug Components: Tomahawk Versions: Nightly Build Reporter: Mike Kienenberger Priority: Minor Attachments: fileUpload.xdocs.patch.txt t:inputFileUpload shown as t:fileUpload in web docs -- 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
[ANNOUNCE] New article on writing WAP renderers
Hello, I just wanted to announce a new article at JSF Central entitled "Developing Unwired Components". Here's an excerpt: "The proliferation in recent years of web-enabled devices has brought tremendous challenges to application developers, with the need to develop components that can work across various platforms. For example, extending an application built for a standard web browser to work on a WAP device may require components of your web application to be rendered in more than one way. It is tempting to think that if you use JSF it will be a simple matter to extend an application built for a standard web browser to work on a WAP 2.0 device, requiring adjustment only for screen size. However, some components (such as a table) are not viewable on mobiles, while other components don't work because of the bugs in WAP browsers (which are more common than is usually recognised). Thankfully there is a solution. We can use JSF to extend WAP with self-programmed components supported by render kits. This article will show you how to implement JSF components that use different renderers depending on the device used. This is achieved by separating the rendering from the rest of the component." Read the rest of the article here: http://www.jsfcentral.com/articles/unwired_components.html. ~~~ Kito D. Mann ([EMAIL PROTECTED]) Principal Consultant, Virtua, Inc. (http://www.virtua.com) Author, JavaServer Faces in Action http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info Are you using JSF in a project? Send your story to [EMAIL PROTECTED], and you could get your story published and win a free copy of JavaServer Faces in Action!
[jira] Updated: (MYFACES-606) Tomahawk selectOneRadio doesn't validate. This is a side affect of patch for fixed issue 592.
[ http://issues.apache.org/jira/browse/MYFACES-606?page=all ] Jamie Cash updated MYFACES-606: --- Attachment: 606.patch.txt Patch > Tomahawk selectOneRadio doesn't validate. This is a side affect of patch for > fixed issue 592. > - > > Key: MYFACES-606 > URL: http://issues.apache.org/jira/browse/MYFACES-606 > Project: MyFaces > Type: Bug > Components: Tomahawk > Versions: Nightly Build > Environment: All > Reporter: Jamie Cash > Attachments: 606.patch.txt > > I have rewritten my patch for issue 592 to avoid the side affects described > above. I couldn't add the patch to 592 as that was closed so have had to > raise this issue instead. > Patch to follow shortly. > After the patch is applied, the component will now behave exacly as before > (call to super), if forceId is false or forceIdIndex is true, but will branch > into logic similar to that in UIInput if forceId is true AND forceIdIndex is > false. -- 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-606) Tomahawk selectOneRadio doesn't validate. This is a side affect of patch for fixed issue 592.
Tomahawk selectOneRadio doesn't validate. This is a side affect of patch for fixed issue 592. - Key: MYFACES-606 URL: http://issues.apache.org/jira/browse/MYFACES-606 Project: MyFaces Type: Bug Components: Tomahawk Versions: Nightly Build Environment: All Reporter: Jamie Cash I have rewritten my patch for issue 592 to avoid the side affects described above. I couldn't add the patch to 592 as that was closed so have had to raise this issue instead. Patch to follow shortly. After the patch is applied, the component will now behave exacly as before (call to super), if forceId is false or forceIdIndex is true, but will branch into logic similar to that in UIInput if forceId is true AND forceIdIndex is false. -- 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-552) Multiple autoUpdateDataTable elements on the same page produce unexpected results
[ http://issues.apache.org/jira/browse/MYFACES-552?page=comments#action_12330226 ] Thomas Huber commented on MYFACES-552: -- Tested on Firefox 1.0.6, Windows XP - build 22.09.2005 tested with two and three autoUpdateDataTable tags, also with different beans it is irreproducible! > Multiple autoUpdateDataTable elements on the same page produce unexpected > results > - > > Key: MYFACES-552 > URL: http://issues.apache.org/jira/browse/MYFACES-552 > Project: MyFaces > Type: Bug > Components: Sandbox > Versions: Nightly Build > Environment: Tested on Firefox 1.0.6, Windows XP - 9/7/2005 nightly build > Reporter: Sh Ma > > For example: > > > > > > > Firefox fails to render it correctly, producing some strange results. In this > case, it seems to replicate the entire page within the table (especially > after a certain amount of time)... -- 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: faces-config.xml is missing in myfaces-all.jar in the 1.1.0 release.
I have a lot of other changes related to the cactus/cargo stuff. I don't have a problem checking in all that but there has not been much discussion about it yet. I'd rather see some discussion happen before I check in the rest of the changes. TTFN, -bd- On Sep 22, 2005, at 1:38 PM, Mike Kienenberger wrote: It's got to be checked into the trunk at some point. I don't see any advantages in waiting. On 9/22/05, Bill Dudney <[EMAIL PROTECTED]> wrote: OTOH, I could checkin everything including the cactus & cargo changes and that would fix things on the trunk. Thoughts? -bd- On Sep 22, 2005, at 1:25 PM, Bill Dudney wrote: No I've not checked it in yet because I'm waiting for discussion on the idea of making a 1_1_0 branch that we could do the emergency release from. TTNF, -bd- On Sep 22, 2005, at 1:20 PM, Mike Kienenberger wrote: Is this supposed to be fixed in svn? I just did a complete checkout about an hour ago, and built it with "ant dist-all" and I'm getting the error below if I use myfaces- all, but not if I use myfaces.api, myfaces.impl, and tomahawk separately. java.lang.NoClassDefFoundError: org/apache/myfaces/config/ FacesConfigurator at org.apache.myfaces.webapp.StartupServletContextListener.initFaces (StartupServletContextListener.java:63) at org.apache.myfaces.webapp.StartupServletContextListener.contextInit ia lized(StartupServletContextListener.java:46) Or is this a case of the cure being worse than the disease? -Mike On 9/22/05, Bill Dudney <[EMAIL PROTECTED]> wrote: Since this is simply a build problem perhaps we could copy the tag 1_1_0 to a branch and update only the build.xml file then build a new release. This would be simple, quick and more or less safe. Would we have to rerun the TCK? As long as we trust our tag it should be fine. Correct? TTFN, -bd- On Sep 22, 2005, at 12:08 PM, Werner Punz wrote: Bruno Aranda wrote: This is causing many troubles to users now as we can see from questions in the list. faces-config.xml is not included in the build because of MYFACES-598, when passing -Dskip.sandbox to the build process the file is not included. I think this is important enough and we should do something about this. I don't know if it is possible to include the file in the current release but I don't think it is good to development to touch an already released thing. My opinion here is that we should release a maintenance release 1.1.1 as soon as possible. Waiting for thoughts on this. Regards, Bruno I cannot vote yet, but due to the fact that many newbys probably will try to use the new release, due to the non beta status and TCK status, and this is really a showstopper for many, I´d say get the fix out ASAP!
Re: faces-config.xml is missing in myfaces-all.jar in the 1.1.0 release.
It's got to be checked into the trunk at some point. I don't see any advantages in waiting. On 9/22/05, Bill Dudney <[EMAIL PROTECTED]> wrote: > OTOH, I could checkin everything including the cactus & cargo changes > and that would fix things on the trunk. > > Thoughts? > > -bd- > > On Sep 22, 2005, at 1:25 PM, Bill Dudney wrote: > > > No I've not checked it in yet because I'm waiting for discussion on > > the idea of making a 1_1_0 branch that we could do the emergency > > release from. > > > > TTNF, > > > > -bd- > > > > On Sep 22, 2005, at 1:20 PM, Mike Kienenberger wrote: > > > > > >> Is this supposed to be fixed in svn? > >> > >> I just did a complete checkout about an hour ago, and built it with > >> "ant dist-all" and I'm getting the error below if I use myfaces-all, > >> but not if I use myfaces.api, myfaces.impl, and tomahawk separately. > >> > >> java.lang.NoClassDefFoundError: org/apache/myfaces/config/ > >> FacesConfigurator > >> at > >> org.apache.myfaces.webapp.StartupServletContextListener.initFaces > >> (StartupServletContextListener.java:63) > >> at > >> org.apache.myfaces.webapp.StartupServletContextListener.contextInitia > >> lized(StartupServletContextListener.java:46) > >> > >> Or is this a case of the cure being worse than the disease? > >> > >> -Mike > >> > >> On 9/22/05, Bill Dudney <[EMAIL PROTECTED]> wrote: > >> > >> > >>> Since this is simply a build problem perhaps we could copy the tag > >>> 1_1_0 to a branch and update only the build.xml file then build a > >>> new > >>> release. > >>> > >>> This would be simple, quick and more or less safe. > >>> > >>> Would we have to rerun the TCK? As long as we trust our tag it > >>> should > >>> be fine. Correct? > >>> > >>> TTFN, > >>> > >>> -bd- > >>> > >>> On Sep 22, 2005, at 12:08 PM, Werner Punz wrote: > >>> > >>> > >>> > Bruno Aranda wrote: > > > > > This is causing many troubles to users now as we can see from > > questions in the list. > > faces-config.xml is not included in the build because of > > MYFACES-598, > > when passing -Dskip.sandbox to the build process the file is not > > included. I think this is important enough and we should do > > something > > about this. I don't know if it is possible to include the file > > in the > > current release but I don't think it is good to development to > > touch > > an already released thing. > > > > My opinion here is that we should release a maintenance release > > 1.1.1 > > as soon as possible. Waiting for thoughts on this. > > > > Regards, > > > > Bruno > > > > > > > > > I cannot vote yet, but due to the fact that many newbys probably > will try to use the > new release, due to the non beta status and TCK status, and this > is really a showstopper for many, I´d say get the fix > out ASAP! > > > > > > >>> > >>> > >>> > >> > >> > > > > > >
Re: faces-config.xml is missing in myfaces-all.jar in the 1.1.0 release.
OTOH, I could checkin everything including the cactus & cargo changes and that would fix things on the trunk. Thoughts? -bd- On Sep 22, 2005, at 1:25 PM, Bill Dudney wrote: No I've not checked it in yet because I'm waiting for discussion on the idea of making a 1_1_0 branch that we could do the emergency release from. TTNF, -bd- On Sep 22, 2005, at 1:20 PM, Mike Kienenberger wrote: Is this supposed to be fixed in svn? I just did a complete checkout about an hour ago, and built it with "ant dist-all" and I'm getting the error below if I use myfaces-all, but not if I use myfaces.api, myfaces.impl, and tomahawk separately. java.lang.NoClassDefFoundError: org/apache/myfaces/config/ FacesConfigurator at org.apache.myfaces.webapp.StartupServletContextListener.initFaces (StartupServletContextListener.java:63) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitia lized(StartupServletContextListener.java:46) Or is this a case of the cure being worse than the disease? -Mike On 9/22/05, Bill Dudney <[EMAIL PROTECTED]> wrote: Since this is simply a build problem perhaps we could copy the tag 1_1_0 to a branch and update only the build.xml file then build a new release. This would be simple, quick and more or less safe. Would we have to rerun the TCK? As long as we trust our tag it should be fine. Correct? TTFN, -bd- On Sep 22, 2005, at 12:08 PM, Werner Punz wrote: Bruno Aranda wrote: This is causing many troubles to users now as we can see from questions in the list. faces-config.xml is not included in the build because of MYFACES-598, when passing -Dskip.sandbox to the build process the file is not included. I think this is important enough and we should do something about this. I don't know if it is possible to include the file in the current release but I don't think it is good to development to touch an already released thing. My opinion here is that we should release a maintenance release 1.1.1 as soon as possible. Waiting for thoughts on this. Regards, Bruno I cannot vote yet, but due to the fact that many newbys probably will try to use the new release, due to the non beta status and TCK status, and this is really a showstopper for many, I´d say get the fix out ASAP!
Re: faces-config.xml is missing in myfaces-all.jar in the 1.1.0 release.
No I've not checked it in yet because I'm waiting for discussion on the idea of making a 1_1_0 branch that we could do the emergency release from. TTNF, -bd- On Sep 22, 2005, at 1:20 PM, Mike Kienenberger wrote: Is this supposed to be fixed in svn? I just did a complete checkout about an hour ago, and built it with "ant dist-all" and I'm getting the error below if I use myfaces-all, but not if I use myfaces.api, myfaces.impl, and tomahawk separately. java.lang.NoClassDefFoundError: org/apache/myfaces/config/ FacesConfigurator at org.apache.myfaces.webapp.StartupServletContextListener.initFaces (StartupServletContextListener.java:63) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitial ized(StartupServletContextListener.java:46) Or is this a case of the cure being worse than the disease? -Mike On 9/22/05, Bill Dudney <[EMAIL PROTECTED]> wrote: Since this is simply a build problem perhaps we could copy the tag 1_1_0 to a branch and update only the build.xml file then build a new release. This would be simple, quick and more or less safe. Would we have to rerun the TCK? As long as we trust our tag it should be fine. Correct? TTFN, -bd- On Sep 22, 2005, at 12:08 PM, Werner Punz wrote: Bruno Aranda wrote: This is causing many troubles to users now as we can see from questions in the list. faces-config.xml is not included in the build because of MYFACES-598, when passing -Dskip.sandbox to the build process the file is not included. I think this is important enough and we should do something about this. I don't know if it is possible to include the file in the current release but I don't think it is good to development to touch an already released thing. My opinion here is that we should release a maintenance release 1.1.1 as soon as possible. Waiting for thoughts on this. Regards, Bruno I cannot vote yet, but due to the fact that many newbys probably will try to use the new release, due to the non beta status and TCK status, and this is really a showstopper for many, I´d say get the fix out ASAP!
Re: faces-config.xml is missing in myfaces-all.jar in the 1.1.0 release.
Is this supposed to be fixed in svn? I just did a complete checkout about an hour ago, and built it with "ant dist-all" and I'm getting the error below if I use myfaces-all, but not if I use myfaces.api, myfaces.impl, and tomahawk separately. java.lang.NoClassDefFoundError: org/apache/myfaces/config/FacesConfigurator at org.apache.myfaces.webapp.StartupServletContextListener.initFaces(StartupServletContextListener.java:63) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:46) Or is this a case of the cure being worse than the disease? -Mike On 9/22/05, Bill Dudney <[EMAIL PROTECTED]> wrote: > Since this is simply a build problem perhaps we could copy the tag > 1_1_0 to a branch and update only the build.xml file then build a new > release. > > This would be simple, quick and more or less safe. > > Would we have to rerun the TCK? As long as we trust our tag it should > be fine. Correct? > > TTFN, > > -bd- > > On Sep 22, 2005, at 12:08 PM, Werner Punz wrote: > > > Bruno Aranda wrote: > > > >> This is causing many troubles to users now as we can see from > >> questions in the list. > >> faces-config.xml is not included in the build because of > >> MYFACES-598, > >> when passing -Dskip.sandbox to the build process the file is not > >> included. I think this is important enough and we should do something > >> about this. I don't know if it is possible to include the file in the > >> current release but I don't think it is good to development to touch > >> an already released thing. > >> > >> My opinion here is that we should release a maintenance release 1.1.1 > >> as soon as possible. Waiting for thoughts on this. > >> > >> Regards, > >> > >> Bruno > >> > >> > > I cannot vote yet, but due to the fact that many newbys probably > > will try to use the > > new release, due to the non beta status and TCK status, and this > > is really a showstopper for many, I´d say get the fix > > out ASAP! > > > > > > > >
[jira] Created: (MYFACES-605) FacesContext.getResponseStream/getResponseWriter unimplemented
FacesContext.getResponseStream/getResponseWriter unimplemented -- Key: MYFACES-605 URL: http://issues.apache.org/jira/browse/MYFACES-605 Project: MyFaces Type: Bug Components: Implementation Versions: Nightly Build Reporter: Mike Kienenberger I'm trying to generate a downloadable file link, and I'm using: FacesContext facesContext = FacesContext.getCurrentInstance(); OutputStream responseStream = facesContext.getResponseStream(); but responseStream is coming back null. A search through the code seems to indicate that the only thing to call ServletFacesContextImpl.setResponseStream is FacesContextWrapper.setResponseStream(), and nothing calls this method. The same thing appears to be true for responseWriter. It looks like these methods should be delegating to the ExternalContext rather than holding local copies of the values, especially since the external context has valid references. facesContext= ServletFacesContextImpl (id=117) _externalContext= ServletExternalContextImpl (id=122) _servletResponse= ExtensionsResponseWrapper (id=157) printWriter= null response= ServletHttpResponse (id=165) stream= ByteArrayOutputStream (id=167) _renderResponse= false _responseComplete= false _responseStream= null _responseWriter= null However, I'm not sure the best way of doing this. One way would be to typecast ExternalContext to either a ServletExternalContextImpl or a PortletExternalContextImpl and follow the chain of objects. I can create a patch to do this if there's confirmation that this is the best way to go about 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] Closed: (MYFACES-380) New component
[ http://issues.apache.org/jira/browse/MYFACES-380?page=all ] Sylvain Vieujot closed MYFACES-380: --- Fix Version: Nightly Build Resolution: Fixed Implemented in the sandbox. > New component > -- > > Key: MYFACES-380 > URL: http://issues.apache.org/jira/browse/MYFACES-380 > Project: MyFaces > Type: New Feature > Components: Sandbox > Reporter: Stephan Strittmatter > Priority: Trivial > Fix For: Nightly Build > > There is a HTML tag fieldset, which could be very useful to create nice > applications. > Using it at the moment reuires a lot spreating of verbatim-tags. > Her a example of the html-output: > > > My Fieldset > > > > The legend is rendered as title of the groupbox. > My suggestion of the tag will be: > > > > > > > Update comment: > > > > > > >cols="70" > rows="4" > wrap="virtual" > > > style="width:90%" > > > > > > accesskey="m" > > > > > > > > > > > > > > > > > > > > > -- 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: r290595 - in /myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset: ./ Fieldset.java FieldsetRenderer.java FieldsetTag.java
Yes, this is it.
I just close the bug.
Thanks for the notice.
Sylvain.
On Wed, 2005-09-21 at 17:49 -0400, Sean Schofield wrote:
Cool. There is an old JIRA issue on this (MYFACES-380.) Does this
basically implement that?
sean
On 9/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: svieujot
> Date: Tue Sep 20 18:06:09 2005
> New Revision: 290595
>
> URL: http://svn.apache.org/viewcvs?rev=290595&view=rev
> Log:
> New fieldset component.
>
> Added:
> myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset/
> myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset/Fieldset.java (with props)
> myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset/FieldsetRenderer.java (with props)
> myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset/FieldsetTag.java (with props)
>
> Added: myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset/Fieldset.java
> URL: http://svn.apache.org/viewcvs/myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset/Fieldset.java?rev=290595&view=auto
> ==
> --- myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset/Fieldset.java (added)
> +++ myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset/Fieldset.java Tue Sep 20 18:06:09 2005
> @@ -0,0 +1,65 @@
> +/*
> + * Copyright 2004 The Apache Software Foundation.
> + *
> + * Licensed under the Apache License, Version 2.0 (the "License");
> + * you may not use this file except in compliance with the License.
> + * You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +package org.apache.myfaces.custom.fieldset;
> +
> +import javax.faces.context.FacesContext;
> +import javax.faces.el.ValueBinding;
> +
> +import org.apache.myfaces.custom.htmlTag.HtmlTag;
> +
> +/**
> + * @author svieujot (latest modification by $Author$)
> + * @version $Revision$ $Date: 2005-06-09 02:27:56 -0400 (Thu, 09 Jun 2005) $
> + */
> +public class Fieldset extends HtmlTag {
> + public static final String COMPONENT_TYPE = "org.apache.myfaces.Fieldset";
> + public static final String COMPONENT_FAMILY = "javax.faces.Output";
> + private static final String DEFAULT_RENDERER_TYPE = FieldsetRenderer.RENDERER_TYPE;
> +
> + private String legend = null;
> +
> + public Fieldset(){
> + setRendererType(DEFAULT_RENDERER_TYPE);
> + }
> +
> + public Object getValue() {
> + return "fieldset";
> + }
> +
> + public String getLegend(){
> + if (legend != null)
> + return legend;
> + ValueBinding vb = getValueBinding("legend");
> + return vb != null ? (String) vb.getValue(getFacesContext()) : null;
> + }
> +
> + public void setLegend(String legend){
> + this.legend = legend;
> + }
> +
> + public void restoreState(FacesContext context, Object state){
> + Object values[] = (Object[]) state;
> + super.restoreState(context, values[0]);
> + legend = (String) values[1];
> + }
> +
> + public Object saveState(FacesContext context){
> + Object values[] = new Object[2];
> + values[0] = super.saveState(context);
> + values[1] = legend;
> + return values;
> + }
> +}
> \ No newline at end of file
>
> Propchange: myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset/Fieldset.java
> --
> svn:eol-style = native
>
> Propchange: myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset/Fieldset.java
> --
> svn:keywords = "LastChangedDate LastChangedBy LastChangedRevision Author Id"
>
> Propchange: myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset/Fieldset.java
> --
> svn:mime-type = text/plain
>
> Added: myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset/FieldsetRenderer.java
> URL: http://svn.apache.org/viewcvs/myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset/FieldsetRenderer.java?rev=290595&view=auto
> ==
> --- myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset/FieldsetRenderer.java (added)
> +++ myfaces/sandbox/trunk/src/java/org/apache/myfaces/custom/fieldset/FieldsetRenderer.java Tue Sep 20 18:06:09 2005
> @@ -0,0 +1,54 @@
> +/*
> + * Copyright 2004 The Apache Software Foundation.
> + *
> + * Licensed under the Apache License, Versi
Re: tags, branches and 'current'
Well the idea is that people would then be using current/trunk to checkout instead of just current. TTFN, -bd- On Sep 22, 2005, at 12:31 PM, Martin Cooper wrote: On Thu, 22 Sep 2005, Bill Dudney wrote: Hi All, I'd like to propose that we change current to be; current /branches /tags /trunk Still all externals but tracking the group of tags & branches that are common across all the subprojects. current/trunk -> becomes what we currently call current current/branches -> currently empty current/tags -> 1_1_0 with externals to each subproject's 1_1_0 tag I would recommend against doing that. It would mean that everyone checking out 'current' would end up with multiple copies of the entire source tree, which is unlikely to be something that they would want. Most people are unlikely to want more than one version of the source at any given time, so I don't see a need to clump together multiple versions in a single checkout. -- Martin Cooper To fix the faces-config.xml bug that's been identified in the 1_1_0 release we can create a branch in current/branches/1_1_0 that uses externals to the tags for everything but 'build' which would point to the 1_1_0 branch in build (not yet created but I'd be glad to do that). Thoughts? TTFN, -bd-
Re: tags, branches and 'current'
On Thu, 22 Sep 2005, Bill Dudney wrote: Hi All, I'd like to propose that we change current to be; current /branches /tags /trunk Still all externals but tracking the group of tags & branches that are common across all the subprojects. current/trunk -> becomes what we currently call current current/branches -> currently empty current/tags -> 1_1_0 with externals to each subproject's 1_1_0 tag I would recommend against doing that. It would mean that everyone checking out 'current' would end up with multiple copies of the entire source tree, which is unlikely to be something that they would want. Most people are unlikely to want more than one version of the source at any given time, so I don't see a need to clump together multiple versions in a single checkout. -- Martin Cooper To fix the faces-config.xml bug that's been identified in the 1_1_0 release we can create a branch in current/branches/1_1_0 that uses externals to the tags for everything but 'build' which would point to the 1_1_0 branch in build (not yet created but I'd be glad to do that). Thoughts? TTFN, -bd-
tags, branches and 'current'
Hi All, I'd like to propose that we change current to be; current /branches /tags /trunk Still all externals but tracking the group of tags & branches that are common across all the subprojects. current/trunk -> becomes what we currently call current current/branches -> currently empty current/tags -> 1_1_0 with externals to each subproject's 1_1_0 tag To fix the faces-config.xml bug that's been identified in the 1_1_0 release we can create a branch in current/branches/1_1_0 that uses externals to the tags for everything but 'build' which would point to the 1_1_0 branch in build (not yet created but I'd be glad to do that). Thoughts? TTFN, -bd-
Re: faces-config.xml is missing in myfaces-all.jar in the 1.1.0 release.
Since this is simply a build problem perhaps we could copy the tag 1_1_0 to a branch and update only the build.xml file then build a new release. This would be simple, quick and more or less safe. Would we have to rerun the TCK? As long as we trust our tag it should be fine. Correct? TTFN, -bd- On Sep 22, 2005, at 12:08 PM, Werner Punz wrote: Bruno Aranda wrote: This is causing many troubles to users now as we can see from questions in the list. faces-config.xml is not included in the build because of MYFACES-598, when passing -Dskip.sandbox to the build process the file is not included. I think this is important enough and we should do something about this. I don't know if it is possible to include the file in the current release but I don't think it is good to development to touch an already released thing. My opinion here is that we should release a maintenance release 1.1.1 as soon as possible. Waiting for thoughts on this. Regards, Bruno I cannot vote yet, but due to the fact that many newbys probably will try to use the new release, due to the non beta status and TCK status, and this is really a showstopper for many, I´d say get the fix out ASAP!
Re: faces-config.xml is missing in myfaces-all.jar in the 1.1.0 release.
Bruno Aranda wrote: > This is causing many troubles to users now as we can see from > questions in the list. > faces-config.xml is not included in the build because of MYFACES-598, > when passing -Dskip.sandbox to the build process the file is not > included. I think this is important enough and we should do something > about this. I don't know if it is possible to include the file in the > current release but I don't think it is good to development to touch > an already released thing. > > My opinion here is that we should release a maintenance release 1.1.1 > as soon as possible. Waiting for thoughts on this. > > Regards, > > Bruno > I cannot vote yet, but due to the fact that many newbys probably will try to use the new release, due to the non beta status and TCK status, and this is really a showstopper for many, I´d say get the fix out ASAP!
Re: faces-config.xml is missing in myfaces-all.jar in the 1.1.0 release.
Agreed it needs to be done asap. +1 from me. I have a fix and I'm in the midst of testing it now. Anyone have a problem with me checking in everything (including the cactus & cargo bits) now. TTFN -bd- On Sep 22, 2005, at 1:10 AM, Bruno Aranda wrote: This is causing many troubles to users now as we can see from questions in the list. faces-config.xml is not included in the build because of MYFACES-598, when passing -Dskip.sandbox to the build process the file is not included. I think this is important enough and we should do something about this. I don't know if it is possible to include the file in the current release but I don't think it is good to development to touch an already released thing. My opinion here is that we should release a maintenance release 1.1.1 as soon as possible. Waiting for thoughts on this. Regards, Bruno
Re: cactus, cargo and testing on myfaces
Hi All, I like the idea of mock objects that will give us easier to test components. In particular though the inputDate component (tag, renderer and UIComponent subclass) has many bugs filed against it (#233 is a good one to use as a spring board to fix the others though) and some of them would be very hard to test with a mock renderkit. I've attached a JUnit test that uses mocks and a cactus test that runs in container that test the same thing for people to compare. This is part of the testing I'm doing for the inputDate stuff and bug #233. TTFN, -bd- HtmlDateRenderCactus.java Description: Binary data HtmlDateRendererTest.java Description: Binary data On Sep 22, 2005, at 9:13 AM, Mike Kienenberger wrote: I posted this awhile back on the user list, but what about the possibility of a "testing" renderkit? The "encoding" would write values to a Map, and the "decoding" would read them from a Map.As was pointed out before, it might not work with AJAX, but it'd certainly simplify a great deal of the testing. You'd still need some kind of html-testing (maybe cactus) at some point to test the html render kit, but ideally, each render kit would be tested independently of everything else anyway. On 9/22/05, Sean Schofield <[EMAIL PROTECTED]> wrote: A few comments/questions on Bill's proposal... The first is, do we want to go with Cactus, Cargo and Ant for this? I don't have a problem with this although we've talked off and on about using Maven for this at some point. Since our biggest Maven guru (James Mitchell) is busy with some other stuff right now I say lets stick with what we know. One thing I think we should do is check out what Craig and the gang are up to in Shale. They have all of these mock objects, etc that they are using to test Shale. Lets make sure they haven't figured out something already that we could use or easily adapt for our use. There are a lot of extra dependencies but they are only for the build, not the actual usage of myfaces or tomahawk so I don't think that's too big of a deal. One option is a separate target for downloading the dependencies associated with the tests, but that might be a bit much. That does mean, however, that in order to build from the source you are required to supply your own local jars or use download-dependencies and download some jars that you might not have otherwise needed. @Bill, You asked about breaking things with this new build. Here is a good rule of thumb for you to verify this. Do an SVN checkout of myfaces-current and then do a unit-test-all from current/build. Then do clean-all from the same dir (to reset things). Then go to each subproject and build indepedently (but in a logcial order b/c that is still required). So api/build unit-test, share/build unit-test, impl/build unit-test, etc. Also you should probably do the same for dist-all at the top level and then dist at each of the subproject levels. Just to make sure that "one build to rule them all" still applies. I will try the patch shortly when I get some much needed free time. sean On 9/22/05, Enrique Medina <[EMAIL PROTECTED]> wrote: Yes, a good tutorial on the wiki would be great! 2005/9/22, Martin Marinschek <[EMAIL PROTECTED]>: I believe that there is no problem for us in adding any dependencies as long as they are ASL licensed... If you would write up some stuff on how to get started with testing, it would be great - I hope we can then get the other developers (including me) to write those tests as well. regards, Martin On 9/22/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: -Original Message- With the TCK behind us (thanks again to all who worked so hard on that) I figured it was a good time to work on getting cactus tests in place. My thinking behind Cactus is that we need to have the ability to do in container testing because some of the mock stuff is just too tedious. As background info I've been working on bug # 233 (empty date for inputCalendar) and its just too complex to test all the cases with mocks because of the amount of code that must be written to setup the mock env. -/Original Message- Good to hear that. Developing my own components I also have the problems of testing. If we all join forces and know how on that, we can come up with a sample of testing components... -Original Message- So I set out to get a cactus test env that I could execute container side tests in and I've gotten a fair way there. -/Original Message- good to hear -Original Message- The Good: 1) Cactus gives us an alternative means to test (in the container) 2) Cargo integration will be a great way to build tests that automatically invoke the example code on a wide range of containers with each release. This will help us avoid problems with the various containers because of a lack of testing. -/Original Message- Cool. Maybe I should re
Re: cactus, cargo and testing on myfaces
Hi Sean, On Sep 22, 2005, at 7:25 AM, Sean Schofield wrote: A few comments/questions on Bill's proposal... The first is, do we want to go with Cactus, Cargo and Ant for this? I don't have a problem with this although we've talked off and on about using Maven for this at some point. Since our biggest Maven guru (James Mitchell) is busy with some other stuff right now I say lets stick with what we know. Well Maven will build it but I don't think maven has in-container capabilities. You can have maven deploy your cactus tests and run them but maven is essentially a good way to reuse ant scripts, not an in-container testing tool. In a nutshell for those not familiar with these two tools. Cactus -> JUnit in the container. From the client side I invoke a Cactus test that is turned into a hit on the ServletRedirector servlet (typically) that includes among other things the test class and test method to invoke. On the server side the ServletRedirector parses the request finds the test class to instantiate and the method to invoke then using reflection invokes it and returns the result of invoking the test. Cargo -> Container management. Cargo starts and stops the container with a bit of ant configuration. It is easy to delete and rebuild the container stuff because Cargo takes care of all the file creation etc that is required to get a valid instance of the container up and running. For example with the patch I sent out Tomcat 5.5.9 is not only started but a full deployment set of directories is created (logs, webapps, work, etc) so that tomcat is running in a completely different directory than my tomcat install directory. This is very good because it can easily be deleted and recreated. I don't think we will get anything from Maven along these lines other than an easier way to fire up cactus and/or cargo. One thing I think we should do is check out what Craig and the gang are up to in Shale. They have all of these mock objects, etc that they are using to test Shale. Lets make sure they haven't figured out something already that we could use or easily adapt for our use. Great idea. I'll try to dig around today and take a look at what is there. There are a lot of extra dependencies but they are only for the build, not the actual usage of myfaces or tomahawk so I don't think that's too big of a deal. One option is a separate target for downloading the dependencies associated with the tests, but that might be a bit much. That does mean, however, that in order to build from the source you are required to supply your own local jars or use download-dependencies and download some jars that you might not have otherwise needed. It is only compile time so should not be a big deal, but wanted to point it out early so that it did not jump up on anyone. @Bill, You asked about breaking things with this new build. Here is a good rule of thumb for you to verify this. Do an SVN checkout of myfaces-current and then do a unit-test-all from current/build. Then do clean-all from the same dir (to reset things). Then go to each subproject and build indepedently (but in a logcial order b/c that is still required). So api/build unit-test, share/build unit-test, impl/build unit-test, etc. Also you should probably do the same for dist-all at the top level and then dist at each of the subproject levels. Just to make sure that "one build to rule them all" still applies. I will try the patch shortly when I get some much needed free time. sean On 9/22/05, Enrique Medina <[EMAIL PROTECTED]> wrote: Yes, a good tutorial on the wiki would be great! 2005/9/22, Martin Marinschek <[EMAIL PROTECTED]>: I believe that there is no problem for us in adding any dependencies as long as they are ASL licensed... If you would write up some stuff on how to get started with testing, it would be great - I hope we can then get the other developers (including me) to write those tests as well. regards, Martin On 9/22/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: -Original Message- With the TCK behind us (thanks again to all who worked so hard on that) I figured it was a good time to work on getting cactus tests in place. My thinking behind Cactus is that we need to have the ability to do in container testing because some of the mock stuff is just too tedious. As background info I've been working on bug # 233 (empty date for inputCalendar) and its just too complex to test all the cases with mocks because of the amount of code that must be written to setup the mock env. -/Original Message- Good to hear that. Developing my own components I also have the problems of testing. If we all join forces and know how on that, we can come up with a sample of testing components... -Original Message- So I set out to get a cactus test env that I could execute container side tests in and I've gotten a fair way there. -/Origin
Re: cactus, cargo and testing on myfaces
Sounds like a great idea. What do you think Bill? sean On 9/22/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > I posted this awhile back on the user list, but what about the > possibility of a "testing" renderkit? The "encoding" would write > values to a Map, and the "decoding" would read them from a Map.As > was pointed out before, it might not work with AJAX, but it'd > certainly simplify a great deal of the testing. You'd still need > some kind of html-testing (maybe cactus) at some point to test the > html render kit, but ideally, each render kit would be tested > independently of everything else anyway. > > On 9/22/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > A few comments/questions on Bill's proposal... > > > > The first is, do we want to go with Cactus, Cargo and Ant for this? I > > don't have a problem with this although we've talked off and on about > > using Maven for this at some point. Since our biggest Maven guru > > (James Mitchell) is busy with some other stuff right now I say lets > > stick with what we know. > > > > One thing I think we should do is check out what Craig and the gang > > are up to in Shale. They have all of these mock objects, etc that > > they are using to test Shale. Lets make sure they haven't figured out > > something already that we could use or easily adapt for our use. > > > > There are a lot of extra dependencies but they are only for the build, > > not the actual usage of myfaces or tomahawk so I don't think that's > > too big of a deal. One option is a separate target for downloading > > the dependencies associated with the tests, but that might be a bit > > much. That does mean, however, that in order to build from the source > > you are required to supply your own local jars or use > > download-dependencies and download some jars that you might not have > > otherwise needed. > > > > @Bill, > > > > You asked about breaking things with this new build. Here is a good > > rule of thumb for you to verify this. Do an SVN checkout of > > myfaces-current and then do a unit-test-all from current/build. Then > > do clean-all from the same dir (to reset things). Then go to each > > subproject and build indepedently (but in a logcial order b/c that is > > still required). So api/build unit-test, share/build unit-test, > > impl/build unit-test, etc. Also you should probably do the same for > > dist-all at the top level and then dist at each of the subproject > > levels. Just to make sure that "one build to rule them all" still > > applies. > > > > I will try the patch shortly when I get some much needed free time. > > > > sean > > > > > > > > On 9/22/05, Enrique Medina <[EMAIL PROTECTED]> wrote: > > > Yes, a good tutorial on the wiki would be great! > > > > > > 2005/9/22, Martin Marinschek <[EMAIL PROTECTED]>: > > > > I believe that there is no problem for us in adding any dependencies > > > > as long as they are ASL licensed... > > > > > > > > If you would write up some stuff on how to get started with testing, > > > > it would be great - I hope we can then get the other developers > > > > (including me) to write those tests as well. > > > > > > > > regards, > > > > > > > > Martin > > > > > > > > On 9/22/05, Jesse Alexander (KBSA 21) > > > <[EMAIL PROTECTED]> wrote: > > > > > -Original Message- > > > > > With the TCK behind us (thanks again to all who worked so hard on > > > > > that) I figured it was a good time to work on getting cactus tests in > > > > > place. My thinking behind Cactus is that we need to have the ability > > > > > to do in container testing because some of the mock stuff is just too > > > > > tedious. As background info I've been working on bug # 233 (empty > > > > > date for inputCalendar) and its just too complex to test all the > > > > > cases with mocks because of the amount of code that must be written > > > > > to setup the mock env. > > > > > -/Original Message- > > > > > Good to hear that. Developing my own components I also have the > > > > > problems > > > > > > > > > > of testing. If we all join forces and know how on that, we can come up > > > > > with a sample of testing components... > > > > > > > > > > -Original Message- > > > > > So I set out to get a cactus test env that I could execute container > > > > > side tests in and I've gotten a fair way there. > > > > > -/Original Message- > > > > > good to hear > > > > > > > > > > -Original Message- > > > > > The Good: > > > > > 1) Cactus gives us an alternative means to test (in the container) > > > > > 2) Cargo integration will be a great way to build tests that > > > > > automatically invoke the example code on a wide range of containers > > > > > with each release. This will help us avoid problems with the various > > > > > containers because of a lack of testing. > > > > > -/Original Message- > > > > > Cool. Maybe I should revive my ant-task for the Yourkit-profiler? > > > > > Right now I have a web-app (do
[jira] Created: (MYFACES-604) CommandLink & CommandButton do not invoke action if render inside the table
CommandLink & CommandButton do not invoke action if render inside the table --- Key: MYFACES-604 URL: http://issues.apache.org/jira/browse/MYFACES-604 Project: MyFaces Type: Bug Versions: 1.1.0 Environment: XP professional, IE, Firefox Reporter: Hovan I have the table 3 columns, one column i render as commandLink or commandButton. The problem is the action at the backend never got invoke. I try another test by put one link out side of the table block. It works very OK. One more thing is: if csCardSearchHandler has session scope it's also OK. But in my case csCardSearchHandler has request scope. I did try version 1.0.9 and then 1.1.0 neither of those work. -- 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: faces-config.xml is missing in myfaces-all.jar in the 1.1.0 release.
Since I was originally hoping this would have been fixed before the 1.1.0 release went out, definitely a +1 from me on getting it into a quick maintenance release. Thanks, Jeremy
Re: cactus, cargo and testing on myfaces
I posted this awhile back on the user list, but what about the possibility of a "testing" renderkit? The "encoding" would write values to a Map, and the "decoding" would read them from a Map.As was pointed out before, it might not work with AJAX, but it'd certainly simplify a great deal of the testing. You'd still need some kind of html-testing (maybe cactus) at some point to test the html render kit, but ideally, each render kit would be tested independently of everything else anyway. On 9/22/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > A few comments/questions on Bill's proposal... > > The first is, do we want to go with Cactus, Cargo and Ant for this? I > don't have a problem with this although we've talked off and on about > using Maven for this at some point. Since our biggest Maven guru > (James Mitchell) is busy with some other stuff right now I say lets > stick with what we know. > > One thing I think we should do is check out what Craig and the gang > are up to in Shale. They have all of these mock objects, etc that > they are using to test Shale. Lets make sure they haven't figured out > something already that we could use or easily adapt for our use. > > There are a lot of extra dependencies but they are only for the build, > not the actual usage of myfaces or tomahawk so I don't think that's > too big of a deal. One option is a separate target for downloading > the dependencies associated with the tests, but that might be a bit > much. That does mean, however, that in order to build from the source > you are required to supply your own local jars or use > download-dependencies and download some jars that you might not have > otherwise needed. > > @Bill, > > You asked about breaking things with this new build. Here is a good > rule of thumb for you to verify this. Do an SVN checkout of > myfaces-current and then do a unit-test-all from current/build. Then > do clean-all from the same dir (to reset things). Then go to each > subproject and build indepedently (but in a logcial order b/c that is > still required). So api/build unit-test, share/build unit-test, > impl/build unit-test, etc. Also you should probably do the same for > dist-all at the top level and then dist at each of the subproject > levels. Just to make sure that "one build to rule them all" still > applies. > > I will try the patch shortly when I get some much needed free time. > > sean > > > > On 9/22/05, Enrique Medina <[EMAIL PROTECTED]> wrote: > > Yes, a good tutorial on the wiki would be great! > > > > 2005/9/22, Martin Marinschek <[EMAIL PROTECTED]>: > > > I believe that there is no problem for us in adding any dependencies > > > as long as they are ASL licensed... > > > > > > If you would write up some stuff on how to get started with testing, > > > it would be great - I hope we can then get the other developers > > > (including me) to write those tests as well. > > > > > > regards, > > > > > > Martin > > > > > > On 9/22/05, Jesse Alexander (KBSA 21) > > <[EMAIL PROTECTED]> wrote: > > > > -Original Message- > > > > With the TCK behind us (thanks again to all who worked so hard on > > > > that) I figured it was a good time to work on getting cactus tests in > > > > place. My thinking behind Cactus is that we need to have the ability > > > > to do in container testing because some of the mock stuff is just too > > > > tedious. As background info I've been working on bug # 233 (empty > > > > date for inputCalendar) and its just too complex to test all the > > > > cases with mocks because of the amount of code that must be written > > > > to setup the mock env. > > > > -/Original Message- > > > > Good to hear that. Developing my own components I also have the problems > > > > > > > > of testing. If we all join forces and know how on that, we can come up > > > > with a sample of testing components... > > > > > > > > -Original Message- > > > > So I set out to get a cactus test env that I could execute container > > > > side tests in and I've gotten a fair way there. > > > > -/Original Message- > > > > good to hear > > > > > > > > -Original Message- > > > > The Good: > > > > 1) Cactus gives us an alternative means to test (in the container) > > > > 2) Cargo integration will be a great way to build tests that > > > > automatically invoke the example code on a wide range of containers > > > > with each release. This will help us avoid problems with the various > > > > containers because of a lack of testing. > > > > -/Original Message- > > > > Cool. Maybe I should revive my ant-task for the Yourkit-profiler? > > > > Right now I have a web-app (done with JSF) and a servlet (for use > > > > with JMeter and similar) to control the Yourkit Profiler from distance. > > > > For an old version I once had also an ant-task... but I seem to have > > > > lost that source... > > > > > > > > -Original Message- > > > > The Bad: > > > > 1) more dependencies > > > > 2) we
Re: faces-config.xml is missing in myfaces-all.jar in the 1.1.0 release.
Another reason why a maintenance release would be good is that both the jsCookMenu and the inputCalendar have had major bugs fixed in the meantime... my absolute +1 for a very fast maintenance release! regards, Martin On 9/22/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > As an end-user and as someone who answers questions on the > myfaces-user list, I'd really like to see an immediate maintenance > release fixing this issue. Otherwise, we'll be seeing this issue > continuously reposted until the next release, which could be a long > way off. > > Just out of curiosity, what's the plan for version numbering now that > MyFaces 1.1 and JSF 1.1 match, and JSF 1.2 compatibility is a long way > off? > > My suggestion would be 1.1.0.x for maintenance releases and maybe > 1.1.x.0 for major releases until 1.2 compability is reached.It'd > be nice to keep the JSF and MyFaces major release numbers in sync if > possible. > > On 9/22/05, Bruno Aranda <[EMAIL PROTECTED]> wrote: > > This is causing many troubles to users now as we can see from > > questions in the list. > > faces-config.xml is not included in the build because of MYFACES-598, > > when passing -Dskip.sandbox to the build process the file is not > > included. I think this is important enough and we should do something > > about this. I don't know if it is possible to include the file in the > > current release but I don't think it is good to development to touch > > an already released thing. > > > > My opinion here is that we should release a maintenance release 1.1.1 > > as soon as possible. Waiting for thoughts on this. > > > > Regards, > > > > Bruno > > > -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
[jira] Reopened: (MYFACES-401) CommandLink tag override onsubmit function of Form
[ http://issues.apache.org/jira/browse/MYFACES-401?page=all ]
Martin Marinschek reopened MYFACES-401:
---
Paul Klaer was absolutely right - need to change this to his suggestion.
> CommandLink tag override onsubmit function of Form
> --
>
> Key: MYFACES-401
> URL: http://issues.apache.org/jira/browse/MYFACES-401
> Project: MyFaces
> Type: Bug
> Components: Implementation
> Versions: 1.1.0
> Environment: Tomcat 5.0.28
> Reporter: Zhong Li
> Assignee: Martin Marinschek
> Priority: Critical
> Fix For: Nightly Build
> Attachments: bugfix_myfaces-401.txt
>
> I have java script onsubmit in , when I use commandLink tag, even
> onsubmit return false, the form still submitted. I checked javasctipt, If I
> am right, the bug should be here,
> JSF generate Javascript for each commandLink like,
> clear_unitItemViewList();
> document.forms['unitItemViewList'].elements['autoScroll'].value=getScrolling();
> document.forms['unitItemViewList'].elements['unitItemViewList:_link_hidden_'].value='unitItemViewList:_id49_0:_id72';
> if(document.forms['unitItemViewList'].onsubmit){document.forms['unitItemViewList'].onsubmit();}
> document.forms['unitItemViewList'].submit();
> return false;
> --
> so problem it will be caused by
> if(document.forms['unitItemViewList'].onsubmit){document.forms['unitItemViewList'].onsubmit();}
> document.forms['unitItemViewList'].submit(); //the form submitted!!
> it should be
> if(document.forms['unitItemViewList'].onsubmit)
> {
> if( document.forms['unitItemViewList'].onsubmit() )
> {
>document.forms['unitItemViewList'].submit();
> }
> }
> else
> {
>document.forms['unitItemViewList'].submit();
> }
--
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: faces-config.xml is missing in myfaces-all.jar in the 1.1.0 release.
As an end-user and as someone who answers questions on the myfaces-user list, I'd really like to see an immediate maintenance release fixing this issue. Otherwise, we'll be seeing this issue continuously reposted until the next release, which could be a long way off. Just out of curiosity, what's the plan for version numbering now that MyFaces 1.1 and JSF 1.1 match, and JSF 1.2 compatibility is a long way off? My suggestion would be 1.1.0.x for maintenance releases and maybe 1.1.x.0 for major releases until 1.2 compability is reached.It'd be nice to keep the JSF and MyFaces major release numbers in sync if possible. On 9/22/05, Bruno Aranda <[EMAIL PROTECTED]> wrote: > This is causing many troubles to users now as we can see from > questions in the list. > faces-config.xml is not included in the build because of MYFACES-598, > when passing -Dskip.sandbox to the build process the file is not > included. I think this is important enough and we should do something > about this. I don't know if it is possible to include the file in the > current release but I don't think it is good to development to touch > an already released thing. > > My opinion here is that we should release a maintenance release 1.1.1 > as soon as possible. Waiting for thoughts on this. > > Regards, > > Bruno >
[jira] Commented: (MYFACES-603) duplicate id exception
[
http://issues.apache.org/jira/browse/MYFACES-603?page=comments#action_12330196
]
Mathias Werlitz commented on MYFACES-603:
-
Maybe this is somehow related to MYFACES-580 ?
> duplicate id exception
> --
>
> Key: MYFACES-603
> URL: http://issues.apache.org/jira/browse/MYFACES-603
> Project: MyFaces
> Type: Bug
> Components: General
> Versions: 1.1.0
> Environment: Tomcat 5.5.9, JDK 1.4.2, Windows NT
> Reporter: Boris Klug
> Priority: Critical
>
> When reloading a page, I get the exception below.
> I search the mailing list and someone suggested to assign a id by hand
> to every component - which is much work and would clumber the jsf pages.
> I manualy added an id to the component with the duplicate id and
> redeployed the app - now I get the exception from another component. So
> what changed from 1.0.9m9 to 1.1.0 related to this problem?
> Another strange thing is that I get the following warning:
> 2005-09-20 15:06:39,481 INFO [/XXX]: WARNING: Component _id12 just got
> an automatic id, because there was no id assigned yet. If this component
> was created dynamically (i.e. not by a JSP tag) you should assign it an
> explicit static id or assign it the id you get from the createUniqueId
> from the current UIViewRoot component right after creation!
> Everything went away after I rearragned the components like this:
> Original:
>
>.. jscookmenu
>... dataTable with command links
>
> ... more dataTable with more command links
>
>
> Now without problems:
>
>... jscookmenu
>
> ... dataTable with command links
> ... more dataTable with more command links
>
> /f:view>
> === Thrown exception
> 2005-09-20 15:06:47,753 ERROR [jsp]: Servlet.service() for servlet jsp threw
> exception
> javax.faces.FacesException: cannot add component with id '_id21' and path :
> {Component-Path : [Class:
> javax.faces.component.html.HtmlInputText,Id: _id21]} to its parent component.
> This might be a problem due to duplicate ids.
> at javax.faces.webapp.UIComponentTag.findComponent(UIComponentTag.java:401)
> at javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:219)
> at
> org.apache.jsp.templates.generic_jsp._jspx_meth_h_inputText_1(org.apache.jsp.templates.generic_jsp:1642)
> at
> org.apache.jsp.templates.generic_jsp._jspx_meth_h_panelGrid_4(org.apache.jsp.templates.generic_jsp:1598)
> at
> org.apache.jsp.templates.generic_jsp._jspService(org.apache.jsp.templates.generic_jsp:636)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
--
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: cactus, cargo and testing on myfaces
A few comments/questions on Bill's proposal... The first is, do we want to go with Cactus, Cargo and Ant for this? I don't have a problem with this although we've talked off and on about using Maven for this at some point. Since our biggest Maven guru (James Mitchell) is busy with some other stuff right now I say lets stick with what we know. One thing I think we should do is check out what Craig and the gang are up to in Shale. They have all of these mock objects, etc that they are using to test Shale. Lets make sure they haven't figured out something already that we could use or easily adapt for our use. There are a lot of extra dependencies but they are only for the build, not the actual usage of myfaces or tomahawk so I don't think that's too big of a deal. One option is a separate target for downloading the dependencies associated with the tests, but that might be a bit much. That does mean, however, that in order to build from the source you are required to supply your own local jars or use download-dependencies and download some jars that you might not have otherwise needed. @Bill, You asked about breaking things with this new build. Here is a good rule of thumb for you to verify this. Do an SVN checkout of myfaces-current and then do a unit-test-all from current/build. Then do clean-all from the same dir (to reset things). Then go to each subproject and build indepedently (but in a logcial order b/c that is still required). So api/build unit-test, share/build unit-test, impl/build unit-test, etc. Also you should probably do the same for dist-all at the top level and then dist at each of the subproject levels. Just to make sure that "one build to rule them all" still applies. I will try the patch shortly when I get some much needed free time. sean On 9/22/05, Enrique Medina <[EMAIL PROTECTED]> wrote: > Yes, a good tutorial on the wiki would be great! > > 2005/9/22, Martin Marinschek <[EMAIL PROTECTED]>: > > I believe that there is no problem for us in adding any dependencies > > as long as they are ASL licensed... > > > > If you would write up some stuff on how to get started with testing, > > it would be great - I hope we can then get the other developers > > (including me) to write those tests as well. > > > > regards, > > > > Martin > > > > On 9/22/05, Jesse Alexander (KBSA 21) > <[EMAIL PROTECTED]> wrote: > > > -Original Message- > > > With the TCK behind us (thanks again to all who worked so hard on > > > that) I figured it was a good time to work on getting cactus tests in > > > place. My thinking behind Cactus is that we need to have the ability > > > to do in container testing because some of the mock stuff is just too > > > tedious. As background info I've been working on bug # 233 (empty > > > date for inputCalendar) and its just too complex to test all the > > > cases with mocks because of the amount of code that must be written > > > to setup the mock env. > > > -/Original Message- > > > Good to hear that. Developing my own components I also have the problems > > > > > > of testing. If we all join forces and know how on that, we can come up > > > with a sample of testing components... > > > > > > -Original Message- > > > So I set out to get a cactus test env that I could execute container > > > side tests in and I've gotten a fair way there. > > > -/Original Message- > > > good to hear > > > > > > -Original Message- > > > The Good: > > > 1) Cactus gives us an alternative means to test (in the container) > > > 2) Cargo integration will be a great way to build tests that > > > automatically invoke the example code on a wide range of containers > > > with each release. This will help us avoid problems with the various > > > containers because of a lack of testing. > > > -/Original Message- > > > Cool. Maybe I should revive my ant-task for the Yourkit-profiler? > > > Right now I have a web-app (done with JSF) and a servlet (for use > > > with JMeter and similar) to control the Yourkit Profiler from distance. > > > For an old version I once had also an ant-task... but I seem to have > > > lost that source... > > > > > > -Original Message- > > > The Bad: > > > 1) more dependencies > > > 2) we don't seem to have a ground swell of support for testing so > > > this all might be for nothing > > > -/Original Message- > > > Dependencies are only for build and testing? Is that so bad? > > > > > > -Original Message- > > > What are you thoughts? Since introduction of JUnit I've not seen any > > > additional tests being added to the mix. Its a huge task to get test > > > coverage but I think its worth it, we will significantly reduce the > > > uncertainty in doing a release if we can get a good set of tests in > > > place. > > > -/Original Message- > > > JUnit is on e part of the game. But with presentation layer stuff the > > > incontainer-testing is a must. The applications that depend on Myfaces > >
[jira] Commented: (MYFACES-430) inputDate (calendar) and French Locale
[ http://issues.apache.org/jira/browse/MYFACES-430?page=comments#action_12330191 ] Maxence Dewil commented on MYFACES-430: --- Ok, it works now for non-english characters. For the french translation I suppose the words are in the calendar html/js code itself.. So that kind of change is not possible now. I think the bug can be closed. Regards, Maxence Dewil > inputDate (calendar) and French Locale > -- > > Key: MYFACES-430 > URL: http://issues.apache.org/jira/browse/MYFACES-430 > Project: MyFaces > Type: Bug > Components: Tomahawk > Versions: 1.1.0 > Reporter: Maxence Dewil > Assignee: Martin Marinschek > Priority: Minor > > When the French Locale is enabled, the calendar gives me "Today is jeu., 18 > ao& 2005" instead of something like "Nous sommes le jeu. 18 août 2005" . > So there is a problem with the french translation and the charset. -- 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: cactus, cargo and testing on myfaces
Yes, a good tutorial on the wiki would be great!2005/9/22, Martin Marinschek <[EMAIL PROTECTED]>: I believe that there is no problem for us in adding any dependenciesas long as they are ASL licensed...If you would write up some stuff on how to get started with testing,it would be great - I hope we can then get the other developers (including me) to write those tests as well.regards,MartinOn 9/22/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: > -Original Message-> With the TCK behind us (thanks again to all who worked so hard on> that) I figured it was a good time to work on getting cactus tests in> place. My thinking behind Cactus is that we need to have the ability > to do in container testing because some of the mock stuff is just too> tedious. As background info I've been working on bug # 233 (empty> date for inputCalendar) and its just too complex to test all the > cases with mocks because of the amount of code that must be written> to setup the mock env.> -/Original Message-> Good to hear that. Developing my own components I also have the problems >> of testing. If we all join forces and know how on that, we can come up> with a sample of testing components...>> -Original Message-> So I set out to get a cactus test env that I could execute container > side tests in and I've gotten a fair way there.> -/Original Message-> good to hear>> -Original Message-> The Good:> 1) Cactus gives us an alternative means to test (in the container) > 2) Cargo integration will be a great way to build tests that> automatically invoke the example code on a wide range of containers> with each release. This will help us avoid problems with the various > containers because of a lack of testing.> -/Original Message-> Cool. Maybe I should revive my ant-task for the Yourkit-profiler?> Right now I have a web-app (done with JSF) and a servlet (for use > with JMeter and similar) to control the Yourkit Profiler from distance.> For an old version I once had also an ant-task... but I seem to have> lost that source...>> -Original Message- > The Bad:> 1) more dependencies> 2) we don't seem to have a ground swell of support for testing so> this all might be for nothing> -/Original Message-> Dependencies are only for build and testing? Is that so bad? >> -Original Message-> What are you thoughts? Since introduction of JUnit I've not seen any> additional tests being added to the mix. Its a huge task to get test> coverage but I think its worth it, we will significantly reduce the > uncertainty in doing a release if we can get a good set of tests in> place.> -/Original Message-> JUnit is on e part of the game. But with presentation layer stuff the> incontainer-testing is a must. The applications that depend on Myfaces > may not need it (maybe they also need it...), but the confidence the> incontainer test can give is important for future changes...>> -Original Message-> I'm working on getting some more JUnit tests in place and would love > to write up what is required if that would help others get started.> -/Original Message-> Way cool.>> regards> Alexander>-- http://www.irian.atYour JSF powerhouse -JSF Trainings in English and German
[jira] Updated: (MYFACES-602) I run examples in myfaces-1.1.0-examples.zip on jboss is OK! but not work on Weblogic8.1sp3!
[ http://issues.apache.org/jira/browse/MYFACES-602?page=all ] Mark Sanders updated MYFACES-602: - Attachment: config.extract.xml Here is the additional XML registry entries. I actually added them via the WebLogic console. - M > I run examples in myfaces-1.1.0-examples.zip on jboss is OK! but not work > on Weblogic8.1sp3! > -- > > Key: MYFACES-602 > URL: http://issues.apache.org/jira/browse/MYFACES-602 > Project: MyFaces > Type: Bug > Versions: 1.1.0 > Environment: Windows-2000Server + Weblogic8.1sp3 + > myfaces-1.1.0-examples.zip > 1G Mem , 30G HardDisk, My network do not connecct to internet! > Reporter: Mr. ZhangQing > Attachments: config.extract.xml > > I found that MyFaces 1.1.0 needed an internet collection to validate the DTD > for the web.xml when running on Weblogic8.1sp3! I am running simple.war in > myfaces-1.1.0-examples.zip on Weblogic8.1sp3 > Error message is : > info: Reading config > zip:D:/bea/user_projects/domains/gitdw/myserver/.wlnotdelete/extract/myserver_simple_simple/jarfiles/WEB-INF/li > b/sandbox4690.jar!/META-INF/faces-config.xml > 2005-9-22 16:23:49 org.apache.myfaces.config.FacesConfigurator > feedClassloaderConfigurations > info: Reading config > zip:D:/bea/user_projects/domains/gitdw/myserver/.wlnotdelete/extract/myserver_simple_simple/jarfiles/WEB-INF/li > b/tomahawk4692.jar!/META-INF/faces-config.xml > 2005-9-22 16:23:49 org.apache.myfaces.config.FacesConfigurator > feedContextSpecifiedConfig > info: Reading config /WEB-INF/examples-config.xml > 2005-9-22 16:23:49 org.apache.myfaces.util.LocaleUtils toLocale > fatal: Locale name null or empty, ignoring > 2005-9-22 16:24:08 org.apache.myfaces.webapp.webxml.WebXmlParser parse > fatal: Unable to parse web.xml > java.net.UnknownHostException: java.sun.com > at java.net.InetAddress.getAllByName0(InetAddress.java:1016) > at java.net.InetAddress.getAllByName0(InetAddress.java:981) > at java.net.InetAddress.getAllByName(InetAddress.java:975) > at weblogic.net.http.HttpClient.openServer(HttpClient.java:263) > at weblogic.net.http.HttpClient.openServer(HttpClient.java:329) > at weblogic.net.http.HttpClient.(HttpClient.java:128) > at > weblogic.net.http.HttpURLConnection.getHttpClient(HttpURLConnection.java:129) > at > weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:331) > at > weblogic.net.http.SOAPHttpURLConnection.getInputStream(SOAPHttpURLConnection.java:28) > at java.net.URL.openStream(URL.java:913) > at > weblogic.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:836) > at > weblogic.apache.xerces.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:796) > at > weblogic.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:275) > at > weblogic.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:841) > at > weblogic.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:329) > at > weblogic.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525) > at > weblogic.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581) > at weblogic.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) > at weblogic.apache.xerces.parsers.DOMParser.parse(DOMParser.java:257) > at > weblogic.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:201) > at > weblogic.xml.jaxp.RegistryDocumentBuilder.parse(RegistryDocumentBuilder.java:149) > at > org.apache.myfaces.webapp.webxml.WebXmlParser.parse(WebXmlParser.java:89) > at org.apache.myfaces.webapp.webxml.WebXml.init(WebXml.java:135) > at > org.apache.myfaces.webapp.StartupServletContextListener.initFaces(StartupServletContextListener.java:66) > at > org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:46) > at > weblogic.servlet.internal.WebAppServletContext$FireContextListenerAction.run(WebAppServletContext.java:6515) > at > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) > at > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118) > at > weblogic.servlet.internal.WebAppServletContext.notifyCreated(WebAppServletContext.java:1666) > at > weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:3203) > at > weblogic.servlet.internal.HttpServer.preloadResources(HttpServer.java:694) > at > weblogic.servlet.internal.WebService.preloadResources(WebService.java:483) > at > weblogic.s
[jira] Commented: (MYFACES-602) I run examples in myfaces-1.1.0-examples.zip on jboss is OK! but not work on Weblogic8.1sp3!
[ http://issues.apache.org/jira/browse/MYFACES-602?page=comments#action_12330189 ] Mark Sanders commented on MYFACES-602: -- Hello, I had the same issue myself today. This is caused by the xml parser that is trying to read the config files refering to DTD files that WebLogic does not know about. There is no need for the xml parser to access these files over the Internet, but you have to let the environment know about them. I resolved the issue by creating an XML Registry and adding the required entries from within the WebLogic console. I'll attach a file with the new XMLRegistry entry. - > I run examples in myfaces-1.1.0-examples.zip on jboss is OK! but not work > on Weblogic8.1sp3! > -- > > Key: MYFACES-602 > URL: http://issues.apache.org/jira/browse/MYFACES-602 > Project: MyFaces > Type: Bug > Versions: 1.1.0 > Environment: Windows-2000Server + Weblogic8.1sp3 + > myfaces-1.1.0-examples.zip > 1G Mem , 30G HardDisk, My network do not connecct to internet! > Reporter: Mr. ZhangQing > Attachments: config.extract.xml > > I found that MyFaces 1.1.0 needed an internet collection to validate the DTD > for the web.xml when running on Weblogic8.1sp3! I am running simple.war in > myfaces-1.1.0-examples.zip on Weblogic8.1sp3 > Error message is : > info: Reading config > zip:D:/bea/user_projects/domains/gitdw/myserver/.wlnotdelete/extract/myserver_simple_simple/jarfiles/WEB-INF/li > b/sandbox4690.jar!/META-INF/faces-config.xml > 2005-9-22 16:23:49 org.apache.myfaces.config.FacesConfigurator > feedClassloaderConfigurations > info: Reading config > zip:D:/bea/user_projects/domains/gitdw/myserver/.wlnotdelete/extract/myserver_simple_simple/jarfiles/WEB-INF/li > b/tomahawk4692.jar!/META-INF/faces-config.xml > 2005-9-22 16:23:49 org.apache.myfaces.config.FacesConfigurator > feedContextSpecifiedConfig > info: Reading config /WEB-INF/examples-config.xml > 2005-9-22 16:23:49 org.apache.myfaces.util.LocaleUtils toLocale > fatal: Locale name null or empty, ignoring > 2005-9-22 16:24:08 org.apache.myfaces.webapp.webxml.WebXmlParser parse > fatal: Unable to parse web.xml > java.net.UnknownHostException: java.sun.com > at java.net.InetAddress.getAllByName0(InetAddress.java:1016) > at java.net.InetAddress.getAllByName0(InetAddress.java:981) > at java.net.InetAddress.getAllByName(InetAddress.java:975) > at weblogic.net.http.HttpClient.openServer(HttpClient.java:263) > at weblogic.net.http.HttpClient.openServer(HttpClient.java:329) > at weblogic.net.http.HttpClient.(HttpClient.java:128) > at > weblogic.net.http.HttpURLConnection.getHttpClient(HttpURLConnection.java:129) > at > weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:331) > at > weblogic.net.http.SOAPHttpURLConnection.getInputStream(SOAPHttpURLConnection.java:28) > at java.net.URL.openStream(URL.java:913) > at > weblogic.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:836) > at > weblogic.apache.xerces.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:796) > at > weblogic.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:275) > at > weblogic.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:841) > at > weblogic.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:329) > at > weblogic.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525) > at > weblogic.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581) > at weblogic.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) > at weblogic.apache.xerces.parsers.DOMParser.parse(DOMParser.java:257) > at > weblogic.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:201) > at > weblogic.xml.jaxp.RegistryDocumentBuilder.parse(RegistryDocumentBuilder.java:149) > at > org.apache.myfaces.webapp.webxml.WebXmlParser.parse(WebXmlParser.java:89) > at org.apache.myfaces.webapp.webxml.WebXml.init(WebXml.java:135) > at > org.apache.myfaces.webapp.StartupServletContextListener.initFaces(StartupServletContextListener.java:66) > at > org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:46) > at > weblogic.servlet.internal.WebAppServletContext$FireContextListenerAction.run(WebAppServletContext.java:6515) > at > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) > at > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118) > at > weblogic.servlet.internal.WebAppSer
[jira] Created: (MYFACES-603) duplicate id exception
duplicate id exception
--
Key: MYFACES-603
URL: http://issues.apache.org/jira/browse/MYFACES-603
Project: MyFaces
Type: Bug
Components: General
Versions: 1.1.0
Environment: Tomcat 5.5.9, JDK 1.4.2, Windows NT
Reporter: Boris Klug
Priority: Critical
When reloading a page, I get the exception below.
I search the mailing list and someone suggested to assign a id by hand
to every component - which is much work and would clumber the jsf pages.
I manualy added an id to the component with the duplicate id and
redeployed the app - now I get the exception from another component. So
what changed from 1.0.9m9 to 1.1.0 related to this problem?
Another strange thing is that I get the following warning:
2005-09-20 15:06:39,481 INFO [/XXX]: WARNING: Component _id12 just got
an automatic id, because there was no id assigned yet. If this component
was created dynamically (i.e. not by a JSP tag) you should assign it an
explicit static id or assign it the id you get from the createUniqueId
from the current UIViewRoot component right after creation!
Everything went away after I rearragned the components like this:
Original:
.. jscookmenu
... dataTable with command links
... more dataTable with more command links
Now without problems:
... jscookmenu
... dataTable with command links
... more dataTable with more command links
/f:view>
=== Thrown exception
2005-09-20 15:06:47,753 ERROR [jsp]: Servlet.service() for servlet jsp threw
exception
javax.faces.FacesException: cannot add component with id '_id21' and path :
{Component-Path : [Class:
javax.faces.component.html.HtmlInputText,Id: _id21]} to its parent component.
This might be a problem due to duplicate ids.
at javax.faces.webapp.UIComponentTag.findComponent(UIComponentTag.java:401)
at javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:219)
at
org.apache.jsp.templates.generic_jsp._jspx_meth_h_inputText_1(org.apache.jsp.templates.generic_jsp:1642)
at
org.apache.jsp.templates.generic_jsp._jspx_meth_h_panelGrid_4(org.apache.jsp.templates.generic_jsp:1598)
at
org.apache.jsp.templates.generic_jsp._jspService(org.apache.jsp.templates.generic_jsp:636)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
--
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-602) I run examples in myfaces-1.1.0-examples.zip on jboss is OK! but not work on Weblogic8.1sp3!
I run examples in myfaces-1.1.0-examples.zip on jboss is OK! but not work on Weblogic8.1sp3! -- Key: MYFACES-602 URL: http://issues.apache.org/jira/browse/MYFACES-602 Project: MyFaces Type: Bug Versions: 1.1.0 Environment: Windows-2000Server + Weblogic8.1sp3 + myfaces-1.1.0-examples.zip 1G Mem , 30G HardDisk, My network do not connecct to internet! Reporter: Mr. ZhangQing I found that MyFaces 1.1.0 needed an internet collection to validate the DTD for the web.xml when running on Weblogic8.1sp3! I am running simple.war in myfaces-1.1.0-examples.zip on Weblogic8.1sp3 Error message is : info: Reading config zip:D:/bea/user_projects/domains/gitdw/myserver/.wlnotdelete/extract/myserver_simple_simple/jarfiles/WEB-INF/li b/sandbox4690.jar!/META-INF/faces-config.xml 2005-9-22 16:23:49 org.apache.myfaces.config.FacesConfigurator feedClassloaderConfigurations info: Reading config zip:D:/bea/user_projects/domains/gitdw/myserver/.wlnotdelete/extract/myserver_simple_simple/jarfiles/WEB-INF/li b/tomahawk4692.jar!/META-INF/faces-config.xml 2005-9-22 16:23:49 org.apache.myfaces.config.FacesConfigurator feedContextSpecifiedConfig info: Reading config /WEB-INF/examples-config.xml 2005-9-22 16:23:49 org.apache.myfaces.util.LocaleUtils toLocale fatal: Locale name null or empty, ignoring 2005-9-22 16:24:08 org.apache.myfaces.webapp.webxml.WebXmlParser parse fatal: Unable to parse web.xml java.net.UnknownHostException: java.sun.com at java.net.InetAddress.getAllByName0(InetAddress.java:1016) at java.net.InetAddress.getAllByName0(InetAddress.java:981) at java.net.InetAddress.getAllByName(InetAddress.java:975) at weblogic.net.http.HttpClient.openServer(HttpClient.java:263) at weblogic.net.http.HttpClient.openServer(HttpClient.java:329) at weblogic.net.http.HttpClient.(HttpClient.java:128) at weblogic.net.http.HttpURLConnection.getHttpClient(HttpURLConnection.java:129) at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:331) at weblogic.net.http.SOAPHttpURLConnection.getInputStream(SOAPHttpURLConnection.java:28) at java.net.URL.openStream(URL.java:913) at weblogic.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:836) at weblogic.apache.xerces.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:796) at weblogic.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:275) at weblogic.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:841) at weblogic.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:329) at weblogic.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525) at weblogic.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581) at weblogic.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at weblogic.apache.xerces.parsers.DOMParser.parse(DOMParser.java:257) at weblogic.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:201) at weblogic.xml.jaxp.RegistryDocumentBuilder.parse(RegistryDocumentBuilder.java:149) at org.apache.myfaces.webapp.webxml.WebXmlParser.parse(WebXmlParser.java:89) at org.apache.myfaces.webapp.webxml.WebXml.init(WebXml.java:135) at org.apache.myfaces.webapp.StartupServletContextListener.initFaces(StartupServletContextListener.java:66) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:46) at weblogic.servlet.internal.WebAppServletContext$FireContextListenerAction.run(WebAppServletContext.java:6515) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118) at weblogic.servlet.internal.WebAppServletContext.notifyCreated(WebAppServletContext.java:1666) at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:3203) at weblogic.servlet.internal.HttpServer.preloadResources(HttpServer.java:694) at weblogic.servlet.internal.WebService.preloadResources(WebService.java:483) at weblogic.servlet.internal.ServletInitService.resume(ServletInitService.java:30) at weblogic.t3.srvr.SubsystemManager.resume(SubsystemManager.java:131) at weblogic.t3.srvr.T3Srvr.resume(T3Srvr.java:966) at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:361) at weblogic.Server.main(Server.java:32) 2005-9-22 16:24:08 org.apache.myfaces.webapp.StartupServletContextListener initFaces fatal: Error initializing ServletContext javax.faces.FacesException: java.net.Unknow
Re: cactus, cargo and testing on myfaces
I believe that there is no problem for us in adding any dependencies as long as they are ASL licensed... If you would write up some stuff on how to get started with testing, it would be great - I hope we can then get the other developers (including me) to write those tests as well. regards, Martin On 9/22/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: > -Original Message- > With the TCK behind us (thanks again to all who worked so hard on > that) I figured it was a good time to work on getting cactus tests in > place. My thinking behind Cactus is that we need to have the ability > to do in container testing because some of the mock stuff is just too > tedious. As background info I've been working on bug # 233 (empty > date for inputCalendar) and its just too complex to test all the > cases with mocks because of the amount of code that must be written > to setup the mock env. > -/Original Message- > Good to hear that. Developing my own components I also have the problems > > of testing. If we all join forces and know how on that, we can come up > with a sample of testing components... > > -Original Message- > So I set out to get a cactus test env that I could execute container > side tests in and I've gotten a fair way there. > -/Original Message- > good to hear > > -Original Message- > The Good: > 1) Cactus gives us an alternative means to test (in the container) > 2) Cargo integration will be a great way to build tests that > automatically invoke the example code on a wide range of containers > with each release. This will help us avoid problems with the various > containers because of a lack of testing. > -/Original Message- > Cool. Maybe I should revive my ant-task for the Yourkit-profiler? > Right now I have a web-app (done with JSF) and a servlet (for use > with JMeter and similar) to control the Yourkit Profiler from distance. > For an old version I once had also an ant-task... but I seem to have > lost that source... > > -Original Message- > The Bad: > 1) more dependencies > 2) we don't seem to have a ground swell of support for testing so > this all might be for nothing > -/Original Message- > Dependencies are only for build and testing? Is that so bad? > > -Original Message- > What are you thoughts? Since introduction of JUnit I've not seen any > additional tests being added to the mix. Its a huge task to get test > coverage but I think its worth it, we will significantly reduce the > uncertainty in doing a release if we can get a good set of tests in > place. > -/Original Message- > JUnit is on e part of the game. But with presentation layer stuff the > incontainer-testing is a must. The applications that depend on Myfaces > may not need it (maybe they also need it...), but the confidence the > incontainer test can give is important for future changes... > > -Original Message- > I'm working on getting some more JUnit tests in place and would love > to write up what is required if that would help others get started. > -/Original Message- > Way cool. > > regards > Alexander > -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
[jira] Closed: (MYFACES-601) Bug in org.apache.myfaces.custom.date.HtmlInputDate (misinterprets 12:xx )
[ http://issues.apache.org/jira/browse/MYFACES-601?page=all ] Bruno Aranda closed MYFACES-601: Fix Version: Nightly Build Resolution: Fixed This should be fixed in the SVN (r290918) and available in the next nightly. Thanks Marcel! > Bug in org.apache.myfaces.custom.date.HtmlInputDate (misinterprets 12:xx ) > -- > > Key: MYFACES-601 > URL: http://issues.apache.org/jira/browse/MYFACES-601 > Project: MyFaces > Type: Bug > Components: Tomahawk > Reporter: Marcel Urbanek > Assignee: Bruno Aranda > Priority: Minor > Fix For: Nightly Build > > In method parse() the date is parsed as follows: > SimpleDateFormat fullFormat = new SimpleDateFormat( "dd MM HH mm ss" ); > if (timeZone != null) > fullFormat.setTimeZone(timeZone); > return fullFormat.parse(day+" "+month+" "+year+" "+hours+" "+minutes+" > "+seconds); > This is normally no problem, but when the variable "hours" is "12", > SimpleDateFormat "misinterprets" this value and thinks it's 12 AM, but the > user normally intendet 12 PM (using a 24h clock). This can be solved by using > the following routine instead: > > Calendar tempCalendar=Calendar.getInstance(); > if (timeZone != null) > tempCalendar.setTimeZone(timeZone); > tempCalendar.set(Calendar.DAY_OF_MONTH,Integer.parseInt(day)); > tempCalendar.set(Calendar.MONTH,Integer.parseInt(month)-1); > tempCalendar.set(Calendar.YEAR,Integer.parseInt(year)); > tempCalendar.set(Calendar.HOUR_OF_DAY,Integer.parseInt(hours)); > tempCalendar.set(Calendar.MINUTE,Integer.parseInt(minutes)); > return tempCalendar.getTime(); > } -- 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: (MYFACES-600) panelNavigation renders double "border" attribute
[ http://issues.apache.org/jira/browse/MYFACES-600?page=all ] Bruno Aranda closed MYFACES-600: Fix Version: Nightly Build Resolution: Fixed This should be fixed in the SVN (r290917). Thanks for reporting! > panelNavigation renders double "border" attribute > - > > Key: MYFACES-600 > URL: http://issues.apache.org/jira/browse/MYFACES-600 > Project: MyFaces > Type: Bug > Components: Tomahawk > Versions: Nightly Build > Environment: Windows XP, tomcat 5.0.28, Myfaces, HtmlNavigationRenderer.java > @version $Revision: 239380 $ $Date: 2005-08-23 11:11:59 +0200 > Reporter: Tomasz Bandura > Assignee: Bruno Aranda > Priority: Minor > Fix For: Nightly Build > > When panelNavigator is declared without style & styleClass attributes , and > "border" attribute is declared - > panelNavigator renders table with double "border" attribute, e.g. for > border="1" it renders: > In my opinion HtmlNavigationRenderer should also check if border attribute > exists (HtmlNavigationRenderer .java line 94) > regards > Tomasz -- 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-601) Bug in org.apache.myfaces.custom.date.HtmlInputDate (misinterprets 12:xx )
Bug in org.apache.myfaces.custom.date.HtmlInputDate (misinterprets 12:xx ) -- Key: MYFACES-601 URL: http://issues.apache.org/jira/browse/MYFACES-601 Project: MyFaces Type: Bug Components: Tomahawk Reporter: Marcel Urbanek Priority: Minor In method parse() the date is parsed as follows: SimpleDateFormat fullFormat = new SimpleDateFormat( "dd MM HH mm ss" ); if (timeZone != null) fullFormat.setTimeZone(timeZone); return fullFormat.parse(day+" "+month+" "+year+" "+hours+" "+minutes+" "+seconds); This is normally no problem, but when the variable "hours" is "12", SimpleDateFormat "misinterprets" this value and thinks it's 12 AM, but the user normally intendet 12 PM (using a 24h clock). This can be solved by using the following routine instead: Calendar tempCalendar=Calendar.getInstance(); if (timeZone != null) tempCalendar.setTimeZone(timeZone); tempCalendar.set(Calendar.DAY_OF_MONTH,Integer.parseInt(day)); tempCalendar.set(Calendar.MONTH,Integer.parseInt(month)-1); tempCalendar.set(Calendar.YEAR,Integer.parseInt(year)); tempCalendar.set(Calendar.HOUR_OF_DAY,Integer.parseInt(hours)); tempCalendar.set(Calendar.MINUTE,Integer.parseInt(minutes)); return tempCalendar.getTime(); } -- 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-592) tomahawke SelectOneRadio in datatable no longer working
[
http://issues.apache.org/jira/browse/MYFACES-592?page=comments#action_12330179
]
Jamie Cash commented on MYFACES-592:
Could someone please reopen this, as I am working on a better fix, that should
be ready by the end of today. The fix rhat I supplied last night resolved the
issue but may cause further problems if the validation from the super classes
is required.
> tomahawke SelectOneRadio in datatable no longer working
> ---
>
> Key: MYFACES-592
> URL: http://issues.apache.org/jira/browse/MYFACES-592
> Project: MyFaces
> Type: Bug
> Components: Tomahawk
> Versions: 1.1.0, Nightly Build
> Environment: Tomcat 5.5 running under JBoss on Windows Server 2003
> Reporter: Jamie Cash
> Assignee: Grant Smith
> Fix For: Nightly Build
> Attachments: diff.txt, screenprint.bmp
>
> The tomahawke selectOneRadio (t:selectOneRadio previously x:selectOneRadio)
> in a datatable no longer works correctly. On selection of an item and
> submission of the form a ('Validation Error', "{0}": Value is not a valid
> option') message is added to the messages.
> This worked correctly in myfaces 1.0.9 but not in the last nightly build.
> Below is a subset of my jsp that outputs the column:
>
>
>
>
>required="true" value="#{ClientSearchBean.selectedExtClientId}">
>
>
>
> The 'value; points to a string value in the backing bean and the itemValue
> points to the same string value in the Client domain object, of which the
> table is driven from.
--
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-600) panelNavigation renders double "border" attribute
panelNavigation renders double "border" attribute - Key: MYFACES-600 URL: http://issues.apache.org/jira/browse/MYFACES-600 Project: MyFaces Type: Bug Components: Tomahawk Versions: Nightly Build Environment: Windows XP, tomcat 5.0.28, Myfaces, HtmlNavigationRenderer.java @version $Revision: 239380 $ $Date: 2005-08-23 11:11:59 +0200 Reporter: Tomasz Bandura Priority: Minor When panelNavigator is declared without style & styleClass attributes , and "border" attribute is declared - panelNavigator renders table with double "border" attribute, e.g. for border="1" it renders: In my opinion HtmlNavigationRenderer should also check if border attribute exists (HtmlNavigationRenderer .java line 94) regards Tomasz -- 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: (MYFACES-597) HTMLRadioRenderer not showing selected item
[ http://issues.apache.org/jira/browse/MYFACES-597?page=all ] Mathias Broekelmann closed MYFACES-597: --- Resolution: Fixed already fixed. see MYFACES-570 > HTMLRadioRenderer not showing selected item > --- > > Key: MYFACES-597 > URL: http://issues.apache.org/jira/browse/MYFACES-597 > Project: MyFaces > Type: Bug > Components: Implementation > Versions: 1.1.0 > Reporter: Timo Thomas > Assignee: Mathias Broekelmann > > This bug is similar to MYFACES-144 > (http://issues.apache.org/jira/browse/MYFACES-144) > To reproduce the bug a complex object (other than string) must be used as the > value for SelectItem. The object is converted by using a Converter to a > string value. > The method HtmlRendererBase.renderGroupOrItemRadio(...) tests the complex > object with the converted value which is only working if a string is used as > a value for the selectitem. -- 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: Small bug in org.apache.myfaces.custom.date.HtmlInputDate
Could you open a JIRA issue and submit your patch there? Thanks! Bruno 2005/9/21, Marcel Urbanek <[EMAIL PROTECTED]>: > > Hi. > > In method parse() the date is parsed as follows: > SimpleDateFormat fullFormat = new SimpleDateFormat( "dd MM HH mm ss" ); > if (timeZone != null) > fullFormat.setTimeZone(timeZone); > return fullFormat.parse(day+" "+month+" "+year+" "+hours+" "+minutes+" > "+seconds); > > This is normally no problem, but when the variable "hours" is "12", > SimpleDateFormat "misinterprets" this value and thinks it's 12 AM, but the > user normally intendet 12 PM (using a 24h clock). This can be solved by > using the following routine instead: > > Calendar tempCalendar=Calendar.getInstance(); > if (timeZone != null) > tempCalendar.setTimeZone(timeZone); > tempCalendar.set(Calendar.DAY_OF_MONTH,Integer.parseInt(day)); > tempCalendar.set(Calendar.MONTH,Integer.parseInt(month)-1); > tempCalendar.set(Calendar.YEAR,Integer.parseInt(year)); > tempCalendar.set(Calendar.HOUR_OF_DAY,Integer.parseInt(hours)); > tempCalendar.set(Calendar.MINUTE,Integer.parseInt(minutes)); > return tempCalendar.getTime(); > } > > Greets, Marcel Urbanek > >
[jira] Closed: (MYFACES-506) DateTimeConverter.getTimeZone should return the default time of the GMT zone by default
[ http://issues.apache.org/jira/browse/MYFACES-506?page=all ] Bruno Aranda closed MYFACES-506: Fix Version: Nightly Build (was: 1.1.0) Resolution: Fixed This should be fixed now in the SVN. Thanks Bernd! > DateTimeConverter.getTimeZone should return the default time of the GMT zone > by default > --- > > Key: MYFACES-506 > URL: http://issues.apache.org/jira/browse/MYFACES-506 > Project: MyFaces > Type: Bug > Components: JSR-127 > Versions: 1.0.9m9 > Reporter: Bruno Aranda > Assignee: Bruno Aranda > Fix For: Nightly Build > > DateTimeConverter.getTimeZone should return the default time of the GMT zone > by default, and not null. -- 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: (MYFACES-579) myfaces-all.jar in 1.1.0 RC build is missing faces-config.xml for Tomahawk components.
[ http://issues.apache.org/jira/browse/MYFACES-579?page=all ] Bruno Aranda closed MYFACES-579: Resolution: Won't Fix Just reopened that by mistake, so closing again sorry :-) > myfaces-all.jar in 1.1.0 RC build is missing faces-config.xml for Tomahawk > components. > -- > > Key: MYFACES-579 > URL: http://issues.apache.org/jira/browse/MYFACES-579 > Project: MyFaces > Type: Bug > Components: General > Versions: 1.1.0 > Environment: Windows XP, Weblogic 8.1 SP4 > Reporter: Jeremy Grelle > Assignee: Bruno Aranda > Priority: Blocker > > I posted to the dev list about this, but as it seems my post was missed, I > thought I should raise a JIRA issue since this could end up in a lot of > people getting errors after downloading the new release and including the > myfaces-all.jar in their current projects. > The myfaces-all.jar in the release build is missing the faces-config.xml for > the tomahawk components. I tried it with my own internal applications as > well as the example apps, and they both are unable to locate any of the > tomahawk components when using myfaces-all.jar instead of the three seperate > jars. -- 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] Reopened: (MYFACES-506) DateTimeConverter.getTimeZone should return the default time of the GMT zone by default
[ http://issues.apache.org/jira/browse/MYFACES-506?page=all ] Bruno Aranda reopened MYFACES-506: -- Reopen this as the previous fix seems to not solve the problem completely > DateTimeConverter.getTimeZone should return the default time of the GMT zone > by default > --- > > Key: MYFACES-506 > URL: http://issues.apache.org/jira/browse/MYFACES-506 > Project: MyFaces > Type: Bug > Components: JSR-127 > Versions: 1.0.9m9 > Reporter: Bruno Aranda > Assignee: Bruno Aranda > Fix For: 1.1.0 > > DateTimeConverter.getTimeZone should return the default time of the GMT zone > by default, and not null. -- 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-579) myfaces-all.jar in 1.1.0 RC build is missing faces-config.xml for Tomahawk components.
[ http://issues.apache.org/jira/browse/MYFACES-579?page=all ] Bruno Aranda updated MYFACES-579: - Comment: was deleted > myfaces-all.jar in 1.1.0 RC build is missing faces-config.xml for Tomahawk > components. > -- > > Key: MYFACES-579 > URL: http://issues.apache.org/jira/browse/MYFACES-579 > Project: MyFaces > Type: Bug > Components: General > Versions: 1.1.0 > Environment: Windows XP, Weblogic 8.1 SP4 > Reporter: Jeremy Grelle > Assignee: Bruno Aranda > Priority: Blocker > > I posted to the dev list about this, but as it seems my post was missed, I > thought I should raise a JIRA issue since this could end up in a lot of > people getting errors after downloading the new release and including the > myfaces-all.jar in their current projects. > The myfaces-all.jar in the release build is missing the faces-config.xml for > the tomahawk components. I tried it with my own internal applications as > well as the example apps, and they both are unable to locate any of the > tomahawk components when using myfaces-all.jar instead of the three seperate > jars. -- 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] Reopened: (MYFACES-579) myfaces-all.jar in 1.1.0 RC build is missing faces-config.xml for Tomahawk components.
[ http://issues.apache.org/jira/browse/MYFACES-579?page=all ] Bruno Aranda reopened MYFACES-579: -- Reopen this as the previous fix seems to not solve the problem completely > myfaces-all.jar in 1.1.0 RC build is missing faces-config.xml for Tomahawk > components. > -- > > Key: MYFACES-579 > URL: http://issues.apache.org/jira/browse/MYFACES-579 > Project: MyFaces > Type: Bug > Components: General > Versions: 1.1.0 > Environment: Windows XP, Weblogic 8.1 SP4 > Reporter: Jeremy Grelle > Assignee: Bruno Aranda > Priority: Blocker > > I posted to the dev list about this, but as it seems my post was missed, I > thought I should raise a JIRA issue since this could end up in a lot of > people getting errors after downloading the new release and including the > myfaces-all.jar in their current projects. > The myfaces-all.jar in the release build is missing the faces-config.xml for > the tomahawk components. I tried it with my own internal applications as > well as the example apps, and they both are unable to locate any of the > tomahawk components when using myfaces-all.jar instead of the three seperate > jars. -- 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: cactus, cargo and testing on myfaces
-Original Message- With the TCK behind us (thanks again to all who worked so hard on that) I figured it was a good time to work on getting cactus tests in place. My thinking behind Cactus is that we need to have the ability to do in container testing because some of the mock stuff is just too tedious. As background info I've been working on bug # 233 (empty date for inputCalendar) and its just too complex to test all the cases with mocks because of the amount of code that must be written to setup the mock env. -/Original Message- Good to hear that. Developing my own components I also have the problems of testing. If we all join forces and know how on that, we can come up with a sample of testing components... -Original Message- So I set out to get a cactus test env that I could execute container side tests in and I've gotten a fair way there. -/Original Message- good to hear -Original Message- The Good: 1) Cactus gives us an alternative means to test (in the container) 2) Cargo integration will be a great way to build tests that automatically invoke the example code on a wide range of containers with each release. This will help us avoid problems with the various containers because of a lack of testing. -/Original Message- Cool. Maybe I should revive my ant-task for the Yourkit-profiler? Right now I have a web-app (done with JSF) and a servlet (for use with JMeter and similar) to control the Yourkit Profiler from distance. For an old version I once had also an ant-task... but I seem to have lost that source... -Original Message- The Bad: 1) more dependencies 2) we don't seem to have a ground swell of support for testing so this all might be for nothing -/Original Message- Dependencies are only for build and testing? Is that so bad? -Original Message- What are you thoughts? Since introduction of JUnit I've not seen any additional tests being added to the mix. Its a huge task to get test coverage but I think its worth it, we will significantly reduce the uncertainty in doing a release if we can get a good set of tests in place. -/Original Message- JUnit is on e part of the game. But with presentation layer stuff the incontainer-testing is a must. The applications that depend on Myfaces may not need it (maybe they also need it...), but the confidence the incontainer test can give is important for future changes... -Original Message- I'm working on getting some more JUnit tests in place and would love to write up what is required if that would help others get started. -/Original Message- Way cool. regards Alexander
faces-config.xml is missing in myfaces-all.jar in the 1.1.0 release.
This is causing many troubles to users now as we can see from questions in the list. faces-config.xml is not included in the build because of MYFACES-598, when passing -Dskip.sandbox to the build process the file is not included. I think this is important enough and we should do something about this. I don't know if it is possible to include the file in the current release but I don't think it is good to development to touch an already released thing. My opinion here is that we should release a maintenance release 1.1.1 as soon as possible. Waiting for thoughts on this. Regards, Bruno
