Re: Tomahawk 1.1.5 release plans?
Ok folks, I will try to start the release process for tomahawk next week. Well, regarding the branch there are various possibilities: - use the already existing 1.1.4 branch from Nov. 2006 and release 1.1.4 - throw away existing 1.1.4 branch, create new branch and release 1.1.4 - (optionally) throw away existing 1.1.4 branch, create new 1.1.5 branch, skip version number 1.1.4 and release 1.1.5 If we use one of the two create new branch strategies, which revision is stable enough. Current head? Thanks, Manfred On 2/22/07, Jeff Bischoff [EMAIL PROTECTED] wrote: +1 on this idea. Tomahawk has settled down since the Dojo move and has been running relatively stable. Best to ensure the next release is branched sometime before any more big changes. (Tomahawk 1.1.4 RC is very good too) :) Paul Spencer wrote: We just completed a MyFaces 1.1.5 release, which resolved blockers related to Tomahawk. Can we get a Tomahawk release done before we start changing things for Fusion? Paul Spencer
Re: Tomahawk 1.1.5 release plans?
Hi, +1 for throwing away 1.1.4, creating a new branch using current trunk and releasing 1.1.4. Cagatay On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok folks, I will try to start the release process for tomahawk next week. Well, regarding the branch there are various possibilities: - use the already existing 1.1.4 branch from Nov. 2006 and release 1.1.4 - throw away existing 1.1.4 branch, create new branch and release 1.1.4 - (optionally) throw away existing 1.1.4 branch, create new 1.1.5 branch, skip version number 1.1.4 and release 1.1.5 If we use one of the two create new branch strategies, which revision is stable enough. Current head? Thanks, Manfred On 2/22/07, Jeff Bischoff [EMAIL PROTECTED] wrote: +1 on this idea. Tomahawk has settled down since the Dojo move and has been running relatively stable. Best to ensure the next release is branched sometime before any more big changes. (Tomahawk 1.1.4 RC is very good too) :) Paul Spencer wrote: We just completed a MyFaces 1.1.5 release, which resolved blockers related to Tomahawk. Can we get a Tomahawk release done before we start changing things for Fusion? Paul Spencer
Re: MyFaces Fusion
Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario
Re: MyFaces Fusion
Hi Mario, In the meantime I'll start digging the codebase and hopefully reach a level where I can start to contribute soon:) Cheers, Cagatay On 2/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario
RE: Tomahawk 1.1.5 release plans?
I agree. The old 1.1.4 RC is getting really aged now. However, it seems strange to just throw it away and follow-up 1.1.3 by 1.1.5 Regards, Erik-Berndt Van: Cagatay Civici [mailto:[EMAIL PROTECTED] Verzonden: vr 23-2-2007 9:27 Aan: MyFaces Development Onderwerp: Re: Tomahawk 1.1.5 release plans? Hi, +1 for throwing away 1.1.4, creating a new branch using current trunk and releasing 1.1.4. Cagatay On 2/23/07, Manfred Geiler [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Ok folks, I will try to start the release process for tomahawk next week. Well, regarding the branch there are various possibilities: - use the already existing 1.1.4 branch from Nov. 2006 and release 1.1.4 - throw away existing 1.1.4 branch, create new branch and release 1.1.4 - (optionally) throw away existing 1.1.4 branch, create new 1.1.5 branch, skip version number 1.1.4 and release 1.1.5 If we use one of the two create new branch strategies, which revision is stable enough. Current head? Thanks, Manfred On 2/22/07, Jeff Bischoff [EMAIL PROTECTED] wrote: +1 on this idea. Tomahawk has settled down since the Dojo move and has been running relatively stable. Best to ensure the next release is branched sometime before any more big changes. (Tomahawk 1.1.4 RC is very good too) :) Paul Spencer wrote: We just completed a MyFaces 1.1.5 release, which resolved blockers related to Tomahawk. Can we get a Tomahawk release done before we start changing things for Fusion? Paul Spencer Disclaimer: This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. winmail.dat
Tomahawk - incorrect behaviour of TableSuggestAjax
Hi, TableSuggestAjax is behaving incorrectly after restore view phase in JSF. This is due to incorrect implementation of org.apache.myfaces.component.html.ext.HtmlInputText class - attribute autocomplete is NOT stored/restored (in saveState/restoreState methods). And question - why is autocomplete attribute implemented as String instead of Boolean? Zdenek
[jira] Commented: (TOMAHAWK-887) Duplicate Client-Id
[
https://issues.apache.org/jira/browse/TOMAHAWK-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475301
]
Robert Oschwald commented on TOMAHAWK-887:
--
This issue seems not to be limited to portlets.
We got this problem on a non-portlet JSP page.
As soon as you leave the page and return to it, you get a duplicate-id
exception:
java.lang.IllegalStateException: Client-id : scroller1first is duplicated in
the faces tree. Component : resultList:scroller1first, path: {Component-Path :
[Class: javax.faces.component.UIViewRoot,ViewId:
/faces/secure/admin/snipplet.jsp][Class:
org.apache.myfaces.component.html.ext.HtmlPanelGrid,Id: _idJsp31][Class:
javax.faces.component.html.HtmlForm,Id: resultList][Class:
javax.faces.component.html.HtmlPanelGrid,Id: _idJsp75][Class:
org.apache.myfaces.custom.column.HtmlSimpleColumn,Id: _idJsp81][Class:
org.apache.myfaces.custom.datascroller.HtmlDataScroller,Id: scroller1][Class:
javax.faces.component.html.HtmlCommandLink,Id: scroller1first]}
Workaround: Keep a binding to the scroller in the backingBean and set the
scroller to null in getScroller()
/**
* Return scroller1.
* P
* Creation date: Nov 13, 2006 6:17:13 PM
* P
* @return returns scroller1.
*/
public HtmlDataScroller getScroller1() {
// work around to avoid javax.faces.FacesException:
// Client-id : xxx is duplicated in the faces tree
this.scroller1 = null;
return this.scroller1;
}
This causes the scroller to get rebuild every time you return to the page.
Disadvantage of this is, that the scroller starts on page 1 every time you
return to the page.
BTW: This problem arised as soon as we updated from Tomahawk 1.1.3 to 1.1.5.
We need to use 1.1.5 because of the ppr support in the sandbox.
Duplicate Client-Id
---
Key: TOMAHAWK-887
URL: https://issues.apache.org/jira/browse/TOMAHAWK-887
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Data Scroller
Affects Versions: 1.1.5-SNAPSHOT
Reporter: nikolaos georgosoulos
The datascroller component returns the following error when it is part of a
portlet in page and the user leaves the page and returns. The 1.1.5 snapshot
is being used so the datascroller works fine as long as the user stays in the
portal page with the scroller. When user leaves the page and returns back to
it the error occurs. As portal Jetspeed 2 is being used. the Tomahawk bridge
is used for bridging portal and portlet of JSF that extend the
MyFacesGenericPortlet class without any real implementation (just
super.doView()). Myfaces implementation is 1.1.4. Myfaces impl 1.1.5 does not
cooperate well with Tomahawk bridge (bufferedStream errors) and the
portals-bridge-jsf simply discards any passed parameters from the
processAction to the renderPage phases. I only mention these in order to
prove there is none known alternative.
javax.portlet.PortletException
at
jp.sf.pal.facesresponse.FacesResponseFilter.renderFilter(FacesResponseFilter.java:81)
at
org.apache.portals.bridges.portletfilter.PortletFilterChain.renderFilter(PortletFilterChain.java:114)
at
org.apache.portals.bridges.portletfilter.FilterPortlet.render(FilterPortlet.java:141)
at
org.apache.jetspeed.factory.JetspeedPortletInstance.render(JetspeedPortletInstance.java:102)
at
org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:230)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510)
at
org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:213)
at
org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:125)
at
org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119)
at
org.apache.jetspeed.container.JetspeedPortletContainerWrapper.renderPortlet(JetspeedPortletContainerWrapper.java:120)
at
org.apache.jetspeed.aggregator.impl.RenderingJobImpl.execute(RenderingJobImpl.java:120)
at
org.apache.jetspeed.aggregator.impl.PortletRendererImpl.renderNow(PortletRendererImpl.java:110)
at
DojoUtils class improvement needed
Hi, by looking at org.apache.myfaces.custom.dojoDojoUtils class i found 1 issue, which could block extending usability of dojo. Problem is in static method getAttributeMap(FacesContext, String[] , UIComponent): - it doesn't count with preferred way of declaring get methods dealing with booleans (isAttribute() instead of getAttribute()). Zdenek
Re: MyFaces Fusion
Regarding the demo-app, i could help out with a nice open-source design which i had improved and used in a sourceforge app and our [EMAIL PROTECTED] website: http://jsfatwork.irian.at Let me know if it seems to be useful for MyFaces Fusion. I am willing to re-design the demo-app so that it is human-readable :) cheers, Gerald On 2/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Tomahawk 1.1.5 release plans?
Same as Cagatay. Current head should be stable enough! There was no big change last weeks in tomahawk. Due to using latest tom in a current app i can admit that there seem to be no new issues. Gerald On 2/23/07, Cagatay Civici [EMAIL PROTECTED] wrote: Hi, +1 for throwing away 1.1.4, creating a new branch using current trunk and releasing 1.1.4. Cagatay On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok folks, I will try to start the release process for tomahawk next week. Well, regarding the branch there are various possibilities: - use the already existing 1.1.4 branch from Nov. 2006 and release 1.1.4 - throw away existing 1.1.4 branch, create new branch and release 1.1.4 - (optionally) throw away existing 1.1.4 branch, create new 1.1.5 branch, skip version number 1.1.4 and release 1.1.5 If we use one of the two create new branch strategies, which revision is stable enough. Current head? Thanks, Manfred On 2/22/07, Jeff Bischoff [EMAIL PROTECTED] wrote: +1 on this idea. Tomahawk has settled down since the Dojo move and has been running relatively stable. Best to ensure the next release is branched sometime before any more big changes. (Tomahawk 1.1.4 RC is very good too) :) Paul Spencer wrote: We just completed a MyFaces 1.1.5 release, which resolved blockers related to Tomahawk. Can we get a Tomahawk release done before we start changing things for Fusion? Paul Spencer -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
JSF 1.2 / continuum
Mathias- did you now add the myfaces 1.2 stuff to continuum ? In the meantime, I just published myfaces12 to a staging repo ([1]). that should at least help the geronimo folks a bit . -M [1] http://people.apache.org/~matzew/myfaces12-stage/ -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: JSF 1.2 / continuum
Hi Matthias, I still have no rights on the continuum server at port 8081. The account mrmaven is locked there. I've created an account for me (mbr) but someone needs to give me more rights. Have you configured continuum to do the deployment? Or have you done it manually? The build problems for 1.2 are fixed now. I just had to add an additional dependency (commons-logging:1.0.4) to the maven-faces-plugin. But the pom of the plugin is probably the better place. 2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]: Mathias- did you now add the myfaces 1.2 stuff to continuum ? In the meantime, I just published myfaces12 to a staging repo ([1]). that should at least help the geronimo folks a bit . -M [1] http://people.apache.org/~matzew/myfaces12-stage/ -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Mathias
Re: JSF 1.2 / continuum
we should overhaul the distributionManagement section to be able to run mvn clean install source:jar deploy -M On 2/23/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: Hi Matthias, I still have no rights on the continuum server at port 8081. The account mrmaven is locked there. I've created an account for me (mbr) but someone needs to give me more rights. Have you configured continuum to do the deployment? Or have you done it manually? The build problems for 1.2 are fixed now. I just had to add an additional dependency (commons-logging:1.0.4) to the maven-faces-plugin. But the pom of the plugin is probably the better place. 2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]: Mathias- did you now add the myfaces 1.2 stuff to continuum ? In the meantime, I just published myfaces12 to a staging repo ([1]). that should at least help the geronimo folks a bit . -M [1] http://people.apache.org/~matzew/myfaces12-stage/ -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Mathias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: JSF 1.2 / continuum
btw. you are root ? if so, can you create me an account matzew as well on the zone ? (speaking of a unix account) -M On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: we should overhaul the distributionManagement section to be able to run mvn clean install source:jar deploy -M On 2/23/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: Hi Matthias, I still have no rights on the continuum server at port 8081. The account mrmaven is locked there. I've created an account for me (mbr) but someone needs to give me more rights. Have you configured continuum to do the deployment? Or have you done it manually? The build problems for 1.2 are fixed now. I just had to add an additional dependency (commons-logging:1.0.4) to the maven-faces-plugin. But the pom of the plugin is probably the better place. 2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]: Mathias- did you now add the myfaces 1.2 stuff to continuum ? In the meantime, I just published myfaces12 to a staging repo ([1]). that should at least help the geronimo folks a bit . -M [1] http://people.apache.org/~matzew/myfaces12-stage/ -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Mathias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: JSF 1.2 / continuum
no I'm not root. 2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]: btw. you are root ? if so, can you create me an account matzew as well on the zone ? (speaking of a unix account) -M On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: we should overhaul the distributionManagement section to be able to run mvn clean install source:jar deploy -M On 2/23/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: Hi Matthias, I still have no rights on the continuum server at port 8081. The account mrmaven is locked there. I've created an account for me (mbr) but someone needs to give me more rights. Have you configured continuum to do the deployment? Or have you done it manually? The build problems for 1.2 are fixed now. I just had to add an additional dependency (commons-logging:1.0.4) to the maven-faces-plugin. But the pom of the plugin is probably the better place. 2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]: Mathias- did you now add the myfaces 1.2 stuff to continuum ? In the meantime, I just published myfaces12 to a staging repo ([1]). that should at least help the geronimo folks a bit . -M [1] http://people.apache.org/~matzew/myfaces12-stage/ -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Mathias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Mathias
Re: JSF 1.2 / continuum
ah, ok for cont. however, I am not able to edit the things... I committed the dist. mgmt in the meantime. mvn clean install should be moved to mvn clean install source:jar deploy On 2/23/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: no I'm not root. 2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]: btw. you are root ? if so, can you create me an account matzew as well on the zone ? (speaking of a unix account) -M On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: we should overhaul the distributionManagement section to be able to run mvn clean install source:jar deploy -M On 2/23/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: Hi Matthias, I still have no rights on the continuum server at port 8081. The account mrmaven is locked there. I've created an account for me (mbr) but someone needs to give me more rights. Have you configured continuum to do the deployment? Or have you done it manually? The build problems for 1.2 are fixed now. I just had to add an additional dependency (commons-logging:1.0.4) to the maven-faces-plugin. But the pom of the plugin is probably the better place. 2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]: Mathias- did you now add the myfaces 1.2 stuff to continuum ? In the meantime, I just published myfaces12 to a staging repo ([1]). that should at least help the geronimo folks a bit . -M [1] http://people.apache.org/~matzew/myfaces12-stage/ -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Mathias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Mathias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[continuum] account blocked
hello continuum admins, the http://myfaces.zones.apache.org:8081 mrmaven account is locked currently. any change to get it unlocked ? -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Tomahawk 1.1.5 release plans?
The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 WDYT? --Manfred On 2/23/07, Scheper, Erik-Berndt [EMAIL PROTECTED] wrote: I agree. The old 1.1.4 RC is getting really aged now. However, it seems strange to just throw it away and follow-up 1.1.3 by 1.1.5 Regards, Erik-Berndt Van: Cagatay Civici [mailto:[EMAIL PROTECTED] Verzonden: vr 23-2-2007 9:27 Aan: MyFaces Development Onderwerp: Re: Tomahawk 1.1.5 release plans? Hi, +1 for throwing away 1.1.4, creating a new branch using current trunk and releasing 1.1.4. Cagatay On 2/23/07, Manfred Geiler [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Ok folks, I will try to start the release process for tomahawk next week. Well, regarding the branch there are various possibilities: - use the already existing 1.1.4 branch from Nov. 2006 and release 1.1.4 - throw away existing 1.1.4 branch, create new branch and release 1.1.4 - (optionally) throw away existing 1.1.4 branch, create new 1.1.5 branch, skip version number 1.1.4 and release 1.1.5 If we use one of the two create new branch strategies, which revision is stable enough. Current head? Thanks, Manfred On 2/22/07, Jeff Bischoff [EMAIL PROTECTED] wrote: +1 on this idea. Tomahawk has settled down since the Dojo move and has been running relatively stable. Best to ensure the next release is branched sometime before any more big changes. (Tomahawk 1.1.4 RC is very good too) :) Paul Spencer wrote: We just completed a MyFaces 1.1.5 release, which resolved blockers related to Tomahawk. Can we get a Tomahawk release done before we start changing things for Fusion? Paul Spencer Disclaimer: This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Re: Tomahawk 1.1.5 release plans?
both sounds bad... no idea, funny enough, that almost every tomahawk release has a high dependency on the core code :) -M On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 WDYT? --Manfred On 2/23/07, Scheper, Erik-Berndt [EMAIL PROTECTED] wrote: I agree. The old 1.1.4 RC is getting really aged now. However, it seems strange to just throw it away and follow-up 1.1.3 by 1.1.5 Regards, Erik-Berndt Van: Cagatay Civici [mailto:[EMAIL PROTECTED] Verzonden: vr 23-2-2007 9:27 Aan: MyFaces Development Onderwerp: Re: Tomahawk 1.1.5 release plans? Hi, +1 for throwing away 1.1.4, creating a new branch using current trunk and releasing 1.1.4. Cagatay On 2/23/07, Manfred Geiler [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Ok folks, I will try to start the release process for tomahawk next week. Well, regarding the branch there are various possibilities: - use the already existing 1.1.4 branch from Nov. 2006 and release 1.1.4 - throw away existing 1.1.4 branch, create new branch and release 1.1.4 - (optionally) throw away existing 1.1.4 branch, create new 1.1.5 branch, skip version number 1.1.4 and release 1.1.5 If we use one of the two create new branch strategies, which revision is stable enough. Current head? Thanks, Manfred On 2/22/07, Jeff Bischoff [EMAIL PROTECTED] wrote: +1 on this idea. Tomahawk has settled down since the Dojo move and has been running relatively stable. Best to ensure the next release is branched sometime before any more big changes. (Tomahawk 1.1.4 RC is very good too) :) Paul Spencer wrote: We just completed a MyFaces 1.1.5 release, which resolved blockers related to Tomahawk. Can we get a Tomahawk release done before we start changing things for Fusion? Paul Spencer Disclaimer: This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Tomahawk 1.1.5 release plans?
I slightly have a better feeling w/ skipping 1.1.4 but let's document this very good ;) -M On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: both sounds bad... no idea, funny enough, that almost every tomahawk release has a high dependency on the core code :) -M On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 WDYT? --Manfred On 2/23/07, Scheper, Erik-Berndt [EMAIL PROTECTED] wrote: I agree. The old 1.1.4 RC is getting really aged now. However, it seems strange to just throw it away and follow-up 1.1.3 by 1.1.5 Regards, Erik-Berndt Van: Cagatay Civici [mailto:[EMAIL PROTECTED] Verzonden: vr 23-2-2007 9:27 Aan: MyFaces Development Onderwerp: Re: Tomahawk 1.1.5 release plans? Hi, +1 for throwing away 1.1.4, creating a new branch using current trunk and releasing 1.1.4. Cagatay On 2/23/07, Manfred Geiler [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Ok folks, I will try to start the release process for tomahawk next week. Well, regarding the branch there are various possibilities: - use the already existing 1.1.4 branch from Nov. 2006 and release 1.1.4 - throw away existing 1.1.4 branch, create new branch and release 1.1.4 - (optionally) throw away existing 1.1.4 branch, create new 1.1.5 branch, skip version number 1.1.4 and release 1.1.5 If we use one of the two create new branch strategies, which revision is stable enough. Current head? Thanks, Manfred On 2/22/07, Jeff Bischoff [EMAIL PROTECTED] wrote: +1 on this idea. Tomahawk has settled down since the Dojo move and has been running relatively stable. Best to ensure the next release is branched sometime before any more big changes. (Tomahawk 1.1.4 RC is very good too) :) Paul Spencer wrote: We just completed a MyFaces 1.1.5 release, which resolved blockers related to Tomahawk. Can we get a Tomahawk release done before we start changing things for Fusion? Paul Spencer Disclaimer: This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Tomahawk 1.1.5 release plans?
I suggest releasing from the head with a version of 1.1.5. Releasing the head as 1.1.4 to me is more confusing for the following reasons: o It is currently called 1.1..5-SNAPSHOT o Issues are linked to 1.1.5-SNAPSHOT o Mailing list post refer to 1.1.5-SNAPSHOT o 1.1.4 has already gone through, although partially, a release process. o 1.1.4.1 has already gone through, although partially, a release process. o User searching the mailing list for 1.1.5 issues will have to determine if the post is for the first or second 1.1.5 I do not have a problem with a missing 1.1.4 release, Tomcat does this all the time. The following statement is a concerning statement: 1.1.5 that is 100% compatible to the current core 1.1.5 What does it mean? Are their related Jira issues? Paul Spencer Manfred Geiler wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 WDYT? --Manfred On 2/23/07, Scheper, Erik-Berndt [EMAIL PROTECTED] wrote: I agree. The old 1.1.4 RC is getting really aged now. However, it seems strange to just throw it away and follow-up 1.1.3 by 1.1.5 Regards, Erik-Berndt Van: Cagatay Civici [mailto:[EMAIL PROTECTED] Verzonden: vr 23-2-2007 9:27 Aan: MyFaces Development Onderwerp: Re: Tomahawk 1.1.5 release plans? Hi, +1 for throwing away 1.1.4, creating a new branch using current trunk and releasing 1.1.4. Cagatay On 2/23/07, Manfred Geiler [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Ok folks, I will try to start the release process for tomahawk next week. Well, regarding the branch there are various possibilities: - use the already existing 1.1.4 branch from Nov. 2006 and release 1.1.4 - throw away existing 1.1.4 branch, create new branch and release 1.1.4 - (optionally) throw away existing 1.1.4 branch, create new 1.1.5 branch, skip version number 1.1.4 and release 1.1.5 If we use one of the two create new branch strategies, which revision is stable enough. Current head? Thanks, Manfred On 2/22/07, Jeff Bischoff [EMAIL PROTECTED] wrote: +1 on this idea. Tomahawk has settled down since the Dojo move and has been running relatively stable. Best to ensure the next release is branched sometime before any more big changes. (Tomahawk 1.1.4 RC is very good too) :) Paul Spencer wrote: We just completed a MyFaces 1.1.5 release, which resolved blockers related to Tomahawk. Can we get a Tomahawk release done before we start changing things for Fusion? Paul Spencer Disclaimer: This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Re: MyFaces Fusion
I have also developed a simple application which I want to use teaching MyFaces. I have used Seam components for integration with JPA as data access layer. It looks like this fusion lead a more pure MyFaces application. and I am ready to use it, if you provide some minimum guidelines for rest of us. On 2/23/07, Gerald Müllan [EMAIL PROTECTED] wrote: Regarding the demo-app, i could help out with a nice open-source design which i had improved and used in a sourceforge app and our [EMAIL PROTECTED] website: http://jsfatwork.irian.at Let me know if it seems to be useful for MyFaces Fusion. I am willing to re-design the demo-app so that it is human-readable :) cheers, Gerald On 2/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Arash Rajaeeyan
The site should support version specific documentation
The MyFaces website should support version specific documentation. This is important when users are looking for answers for a released version and the site only documents the current Snapshot. The Shale and Tomahawk sites have version specific documentation I suspect this can be done via Maven, just do not know how. Paul Spencer
Re: Tomahawk 1.1.5 release plans?
On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy
Re: MyFaces Fusion
Arash- is your app somewhere accessable ? -M On 2/23/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I have also developed a simple application which I want to use teaching MyFaces. I have used Seam components for integration with JPA as data access layer. It looks like this fusion lead a more pure MyFaces application. and I am ready to use it, if you provide some minimum guidelines for rest of us. On 2/23/07, Gerald Müllan [EMAIL PROTECTED] wrote: Regarding the demo-app, i could help out with a nice open-source design which i had improved and used in a sourceforge app and our [EMAIL PROTECTED] website: http://jsfatwork.irian.at Let me know if it seems to be useful for MyFaces Fusion. I am willing to re-design the demo-app so that it is human-readable :) cheers, Gerald On 2/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Arash Rajaeeyan -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Tomahawk 1.1.5 release plans?
+1 for release number tomahawk 1.1.5 On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: I suggest releasing from the head with a version of 1.1.5. Releasing the head as 1.1.4 to me is more confusing for the following reasons: o It is currently called 1.1..5-SNAPSHOT o Issues are linked to 1.1.5-SNAPSHOT o Mailing list post refer to 1.1.5-SNAPSHOT o 1.1.4 has already gone through, although partially, a release process. o 1.1.4.1 has already gone through, although partially, a release process. o User searching the mailing list for 1.1.5 issues will have to determine if the post is for the first or second 1.1.5 I do not have a problem with a missing 1.1.4 release, Tomcat does this all the time. The following statement is a concerning statement: 1.1.5 that is 100% compatible to the current core 1.1.5 What does it mean? Are their related Jira issues? Paul Spencer Manfred Geiler wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 WDYT? --Manfred On 2/23/07, Scheper, Erik-Berndt [EMAIL PROTECTED] wrote: I agree. The old 1.1.4 RC is getting really aged now. However, it seems strange to just throw it away and follow-up 1.1.3 by 1.1.5 Regards, Erik-Berndt Van: Cagatay Civici [mailto:[EMAIL PROTECTED] Verzonden: vr 23-2-2007 9:27 Aan: MyFaces Development Onderwerp: Re: Tomahawk 1.1.5 release plans? Hi, +1 for throwing away 1.1.4, creating a new branch using current trunk and releasing 1.1.4. Cagatay On 2/23/07, Manfred Geiler [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Ok folks, I will try to start the release process for tomahawk next week. Well, regarding the branch there are various possibilities: - use the already existing 1.1.4 branch from Nov. 2006 and release 1.1.4 - throw away existing 1.1.4 branch, create new branch and release 1.1.4 - (optionally) throw away existing 1.1.4 branch, create new 1.1.5 branch, skip version number 1.1.4 and release 1.1.5 If we use one of the two create new branch strategies, which revision is stable enough. Current head? Thanks, Manfred On 2/22/07, Jeff Bischoff [EMAIL PROTECTED] wrote: +1 on this idea. Tomahawk has settled down since the Dojo move and has been running relatively stable. Best to ensure the next release is branched sometime before any more big changes. (Tomahawk 1.1.4 RC is very good too) :) Paul Spencer wrote: We just completed a MyFaces 1.1.5 release, which resolved blockers related to Tomahawk. Can we get a Tomahawk release done before we start changing things for Fusion? Paul Spencer Disclaimer: This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Fusion
I can send a working copy to your private email. if you want. zubin is going to use it in his book. I am changing it each day to make it easier for developers learning MyFaces. On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Arash- is your app somewhere accessable ? -M On 2/23/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I have also developed a simple application which I want to use teaching MyFaces. I have used Seam components for integration with JPA as data access layer. It looks like this fusion lead a more pure MyFaces application. and I am ready to use it, if you provide some minimum guidelines for rest of us. On 2/23/07, Gerald Müllan [EMAIL PROTECTED] wrote: Regarding the demo-app, i could help out with a nice open-source design which i had improved and used in a sourceforge app and our [EMAIL PROTECTED] website: http://jsfatwork.irian.at Let me know if it seems to be useful for MyFaces Fusion. I am willing to re-design the demo-app so that it is human-readable :) cheers, Gerald On 2/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Arash Rajaeeyan -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan
[jira] Commented: (MYFACES-1246) JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instanti
[ https://issues.apache.org/jira/browse/MYFACES-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475337 ] Mathias Broekelmann commented on MYFACES-1246: -- I looked into the spec section 5.4. Besides PostConstruct and PreDestroy there should also be a way to inject various j2ee container specific resources. As this is definitly out of scope for myfaces implementation I think we should find a way for j2ee containers to define their own implementation for this. Suns RI uses some kind of InjectionProvider which is implemented by j2ee containers. I think we schould do it in the same way. JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Key: MYFACES-1246 URL: https://issues.apache.org/jira/browse/MYFACES-1246 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assigned To: Dennis Byrne Specified that implementations running in a JSR-250 compliant container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Specified that methods annotated with @PreDestroy be called when the scope for the bean is ending. See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=252 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tomahawk 1.1.5 release plans?
Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy
Re: The site should support version specific documentation
Wendy,
Type-o on my part, I meant to say the Tomcat site support version specific
documentation, not Tomahawk.
Distributing to a version specific URL is part of the solution, the navigation
bar also need a entry the the version specific documentation.
Paul Spencer
Wendy Smoak wrote:
On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote:
The MyFaces website should support version specific documentation.
This is important
when users are looking for answers for a released version and the site
only documents
the current Snapshot. The Shale and Tomahawk sites have version specific
documentation
Shale does, but I don't see it in Tomahawk's site.
I suspect this can be done via Maven, just do not know how.
On the branch, change distributionManagementsite to the new
location, I suggest:
http://myfaces.apache.org/core/1.1.5/
http://myfaces.apache.org/tomahawk/1.1.5
(Or try putting ${version} in the url, that might work...)
Re: Tomahawk 1.1.5 release plans?
slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Tomahawk 1.1.5 release plans?
that would be another very good option -M On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Tomahawk 1.1.5 release plans?
Yes, good idea. So, next tomahawk release would be 1.5.0. +1 on that from my side --Manfred On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Tomahawk 1.1.5 release plans?
If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy
Re: Tomahawk 1.1.5 release plans?
-1 on 1.5.0. We have called it 1.1.5 for many months. Also the reasons I presented for NOT calling it 1.1.4 +1 on the next version of 1.6.0 Manfred Geiler wrote: Yes, good idea. So, next tomahawk release would be 1.5.0. +1 on that from my side --Manfred On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Tomahawk 1.1.5 release plans?
1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy
Re: Tomahawk 1.1.5 release plans?
we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Tomahawk 1.1.5 release plans?
1) Release the head, currently know as 1.1.5-SNAPSHOT, as 1.1.5. 2) During the release process, the release plugin prompts for the next version number. Answer 1.6.0-SNAPSHOT to the prompt. Paul Spencer Manfred Geiler wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy
Re: svn commit: r510950 - /myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd
isn't that CCLD for what ever their OS license is named ? Should go to the notice.txt file, IMO -M On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: Not to slow you down, but can we distribute this? Dennis Byrne On 2/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: mbr Date: Fri Feb 23 06:18:39 2007 New Revision: 510950 URL: http://svn.apache.org/viewvc?view=revrev=510950 Log: add 1.2 xsd Added: myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd Added: myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd URL: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd?view=autorev=510950 == --- myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd (added) +++ myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd Fri Feb 23 06:18:39 2007 @@ -0,0 +1,2071 @@ +?xml version = 1.0 encoding = UTF-8? + +xsd:schema + targetNamespace=http://java.sun.com/xml/ns/javaee + xmlns:javaee=http://java.sun.com/xml/ns/javaee; + xmlns:xsd=http://www.w3.org/2001/XMLSchema + xmlns:xml=http://www.w3.org/XML/1998/namespace; + elementFormDefault=qualified + attributeFormDefault=unqualified + version=1.2 + +xsd:annotation +xsd:documentation +$Id: web-facesconfig_1_2.xsd,v 1.11 2006/03/27 00:12:24 rogerk Exp $ +/xsd:documentation +/xsd:annotation + +xsd:annotation +xsd:documentation + +Copyright 2005 Sun Microsystems, Inc., +901 San Antonio Road, +Palo Alto, California 94303, U.S.A. +All rights reserved. + +Sun Microsystems, Inc. has intellectual property +rights relating to technology described in this document. In +particular, and without limitation, these intellectual +property rights may include one or more of the U.S. patents +listed at http://www.sun.com/patents and one or more +additional patents or pending patent applications in the +U.S. and other countries. + +This document and the technology which it describes are +distributed under licenses restricting their use, copying, +distribution, and decompilation. No part of this document +may be reproduced in any form by any means without prior +written authorization of Sun and its licensors, if any. + +Third-party software, including font technology, is +copyrighted and licensed from Sun suppliers. + +Sun, Sun Microsystems, the Sun logo, Solaris, Java, Java EE, +JavaServer Pages, Enterprise JavaBeans and the Java Coffee +Cup logo are trademarks or registered trademarks of Sun +Microsystems, Inc. in the U.S. and other countries. + +Federal Acquisitions: Commercial Software - Government Users +Subject to Standard License Terms and Conditions. + +/xsd:documentation +/xsd:annotation + +xsd:annotation +xsd:documentation + +![CDATA[ + +The XML Schema for the JavaServer Faces Application +Configuration File (Version 1.2). + +All JavaServer Faces configuration files must indicate +the JavaServer Faces schema by indicating the JavaServer +Faces namespace: + +http://java.sun.com/xml/ns/javaee + +and by indicating the version of the schema by +using the version element as shown below: + +faces-config xmlns=http://java.sun.com/xml/ns/javaee; +xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance; +xsi:schemaLocation=... +version=1.2 +... +/faces-config + +The instance documents may indicate the published +version of the schema using xsi:schemaLocation attribute +for javaee namespace with the following location: + + http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd + +]] + +/xsd:documentation +/xsd:annotation + +xsd:include schemaLocation=javaee_5.xsd/ + +!-- -- + +xsd:element name = faces-config type=javaee:faces-configType +xsd:annotation +xsd:documentation + +The faces-config element is the root of the configuration +information hierarchy, and contains nested elements for all +of the other configuration settings. + +
Re: Tomahawk 1.1.5 release plans?
+1 On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: 1) Release the head, currently know as 1.1.5-SNAPSHOT, as 1.1.5. 2) During the release process, the release plugin prompts for the next version number. Answer 1.6.0-SNAPSHOT to the prompt. Paul Spencer Manfred Geiler wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Tomahawk 1.1.5 release plans?
I would suggest keeping the MyFaces core version in 1.1.x range becuse any releses are just bug fixes. New functionality can only be added when the JSR changes. At that point should the minor version change. +1 on releasing JSF 1.2 implementation as 2.0.0 Thus : JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy
Re: Tomahawk 1.1.5 release plans?
Hi Dennis, the problem is that you don't have any leeway to change the MyFaces-API (read: not JSF API) incompatible to what it had been before. Well, given we finally reach the point at which we have a pretty stable API between bugfix-releases. regards, Martin On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x I'd rather keep the release numbers in sync with the spec numbers. 1.1 - 1.1.x, 1.2 - 1.2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Dennis Byrne -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Tomahawk 1.1.5 release plans?
How about JSF 1.1 - MyFaces 1.1.x JSF 1.2 - MyFaces 1.2.x Tomahawk for JSF 1.1 - Tomahawk 1.x Tomahawk for JSF 1.2 - Tomahawk 2.x sub project for JSF 1.1 - sub project 1.x sub project for JSF 1.2 - sub project 2.x Paul Spencer Dennis Byrne wrote: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x I'd rather keep the release numbers in sync with the spec numbers. 1.1 - 1.1.x, 1.2 - 1.2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.441 / Virus Database: 268.18.3/698 - Release Date: 2/23/2007 4:39 AM
Re: Tomahawk 1.1.5 release plans?
there was a wiki page which says that they want to have the next version of jsf (2.0) named 6.0 so... I am not really seeing any reason to go from myfaces 1.2 to a 6 ... :-) On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x I'd rather keep the release numbers in sync with the spec numbers. 1.1 - 1.1.x, 1.2 - 1.2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Dennis Byrne -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Tomahawk 1.1.5 release plans?
6.0? Seriously? Dennis Byrne On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: there was a wiki page which says that they want to have the next version of jsf (2.0) named 6.0 so... I am not really seeing any reason to go from myfaces 1.2 to a 6 ... :-) On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x I'd rather keep the release numbers in sync with the spec numbers. 1.1 - 1.1.x, 1.2 - 1.2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Dennis Byrne -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne
Re: svn commit: r510950 - /myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd
I wasn't aware of this. the dtds of 1.0 and 1.1 are also present in our repository... 2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]: isn't that CCLD for what ever their OS license is named ? Should go to the notice.txt file, IMO -M On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: Not to slow you down, but can we distribute this? Dennis Byrne On 2/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: mbr Date: Fri Feb 23 06:18:39 2007 New Revision: 510950 URL: http://svn.apache.org/viewvc?view=revrev=510950 Log: add 1.2 xsd Added: myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd Added: myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd URL: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd?view=autorev=510950 == --- myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd (added) +++ myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd Fri Feb 23 06:18:39 2007 @@ -0,0 +1,2071 @@ +?xml version = 1.0 encoding = UTF-8? + +xsd:schema + targetNamespace=http://java.sun.com/xml/ns/javaee + xmlns:javaee=http://java.sun.com/xml/ns/javaee; + xmlns:xsd=http://www.w3.org/2001/XMLSchema + xmlns:xml=http://www.w3.org/XML/1998/namespace; + elementFormDefault=qualified + attributeFormDefault=unqualified + version=1.2 + +xsd:annotation +xsd:documentation +$Id: web-facesconfig_1_2.xsd,v 1.11 2006/03/27 00:12:24 rogerk Exp $ +/xsd:documentation +/xsd:annotation + +xsd:annotation +xsd:documentation + +Copyright 2005 Sun Microsystems, Inc., +901 San Antonio Road, +Palo Alto, California 94303, U.S.A. +All rights reserved. + +Sun Microsystems, Inc. has intellectual property +rights relating to technology described in this document. In +particular, and without limitation, these intellectual +property rights may include one or more of the U.S. patents +listed at http://www.sun.com/patents and one or more +additional patents or pending patent applications in the +U.S. and other countries. + +This document and the technology which it describes are +distributed under licenses restricting their use, copying, +distribution, and decompilation. No part of this document +may be reproduced in any form by any means without prior +written authorization of Sun and its licensors, if any. + +Third-party software, including font technology, is +copyrighted and licensed from Sun suppliers. + +Sun, Sun Microsystems, the Sun logo, Solaris, Java, Java EE, +JavaServer Pages, Enterprise JavaBeans and the Java Coffee +Cup logo are trademarks or registered trademarks of Sun +Microsystems, Inc. in the U.S. and other countries. + +Federal Acquisitions: Commercial Software - Government Users +Subject to Standard License Terms and Conditions. + +/xsd:documentation +/xsd:annotation + +xsd:annotation +xsd:documentation + +![CDATA[ + +The XML Schema for the JavaServer Faces Application +Configuration File (Version 1.2). + +All JavaServer Faces configuration files must indicate +the JavaServer Faces schema by indicating the JavaServer +Faces namespace: + +http://java.sun.com/xml/ns/javaee + +and by indicating the version of the schema by +using the version element as shown below: + +faces-config xmlns=http://java.sun.com/xml/ns/javaee; +xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance; +xsi:schemaLocation=... +version=1.2 +... +/faces-config + +The instance documents may indicate the published +version of the schema using xsi:schemaLocation attribute +for javaee namespace with the following location: + + http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd + +]] + +/xsd:documentation +/xsd:annotation + +xsd:include schemaLocation=javaee_5.xsd/ + +!-- -- + +xsd:element name = faces-config type=javaee:faces-configType +
Re: Tomahawk 1.1.5 release plans?
+1 on Dennis' suggestion (JSF 1.1 - MyFaces 1.x, JSF 1.2 - MyFaces 2.x) dennis said: 1.1 - 1.1.x, 1.2 - 1.2.x I think 1.1 - 1.x.y 1.2 - 2.x.y is the better one... --Manfred On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Dennis, the problem is that you don't have any leeway to change the MyFaces-API (read: not JSF API) incompatible to what it had been before. Well, given we finally reach the point at which we have a pretty stable API between bugfix-releases. regards, Martin On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x I'd rather keep the release numbers in sync with the spec numbers. 1.1 - 1.1.x, 1.2 - 1.2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Dennis Byrne -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Tomahawk 1.1.5 release plans?
Dennis was suggesting JSF 1.1 -- MyFaces 1.1 JSF 1.2 -- MyFaces 1.2 I'm against that - Manfred, your suggestion sounds good. @MyFaces-API: well, Trinidad regards all Trinidad-component classes as a Trinidad-API. We were once discussing on having something like that for MyFaces as well. For Trinidad, a renderer is not in the Trinidad-API, a component is regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Well, in reallife there should not be (better: must not be) such a thing like a MyFaces-API that differs from the JSF-API, but: Every JSF-Implementation is free to implement certain add-on features or optimizations. These are the things you normally configure with those web.xml config-params. So, what you actually mean when you say MyFaces-API are those features, right? I agree that we need the option to differ between such a feature addition/remove (minor change) and a bug fix release. Therefore +1 on Dennis' suggestion (JSF 1.1 - MyFaces 1.x, JSF 1.2 - MyFaces 2.x) --Manfred On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Dennis, the problem is that you don't have any leeway to change the MyFaces-API (read: not JSF API) incompatible to what it had been before. Well, given we finally reach the point at which we have a pretty stable API between bugfix-releases. regards, Martin On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x I'd rather keep the release numbers in sync with the spec numbers. 1.1 - 1.1.x, 1.2 - 1.2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Dennis Byrne -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Tomahawk 1.1.5 release plans?
It wasn't the beer _we_ were drinking - that must have been the Sun officials' beer. ;) regards, Martin On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 on Dennis' suggestion (JSF 1.1 - MyFaces 1.x, JSF 1.2 - MyFaces 2.x) dennis said: 1.1 - 1.1.x, 1.2 - 1.2.x I think 1.1 - 1.x.y 1.2 - 2.x.y is the better one... --Manfred On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Dennis, the problem is that you don't have any leeway to change the MyFaces-API (read: not JSF API) incompatible to what it had been before. Well, given we finally reach the point at which we have a pretty stable API between bugfix-releases. regards, Martin On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x I'd rather keep the release numbers in sync with the spec numbers. 1.1 - 1.1.x, 1.2 - 1.2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Dennis Byrne -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Tomahawk 1.1.5 release plans?
8-) On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote: It wasn't the beer _we_ were drinking - that must have been the Sun officials' beer. ;) regards, Martin On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 on Dennis' suggestion (JSF 1.1 - MyFaces 1.x, JSF 1.2 - MyFaces 2.x) dennis said: 1.1 - 1.1.x, 1.2 - 1.2.x I think 1.1 - 1.x.y 1.2 - 2.x.y is the better one... --Manfred On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Dennis, the problem is that you don't have any leeway to change the MyFaces-API (read: not JSF API) incompatible to what it had been before. Well, given we finally reach the point at which we have a pretty stable API between bugfix-releases. regards, Martin On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x I'd rather keep the release numbers in sync with the spec numbers. 1.1 - 1.1.x, 1.2 - 1.2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Dennis Byrne -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Tomahawk 1.1.5 release plans?
@MyFaces-API: well, Trinidad regards all Trinidad-component classes as a Trinidad-API. We were once discussing on having something like that for MyFaces as well. For Trinidad, a renderer is not in the Trinidad-API, a component is that can change... I think stuff like CoreRenderer or XhtmlRenderer perhaps should be API (just to give an example) -M
Re: Tomahawk 1.1.5 release plans?
I saw that post at the time, but figured it was the result of too much doppelbock and wienerschnitzel. ;) Matthias Wessendorf wrote: Well... there was a meeting in munich, during the october fest... and they discussed that... http://wiki.java.net/bin/view/Projects/JSFDaysMunich2006 *snip* Version synchronization. JSF 2.0 renamed JSF 6 to go with Java EE 6. perhaps it was the beer ;))) On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: 6.0? Seriously? Dennis Byrne On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: there was a wiki page which says that they want to have the next version of jsf (2.0) named 6.0 so... I am not really seeing any reason to go from myfaces 1.2 to a 6 ... :-) On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x I'd rather keep the release numbers in sync with the spec numbers. 1.1 - 1.1.x, 1.2 - 1.2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Dennis Byrne -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne
Re: DojoUtils class improvement needed
please file a jira issue so we don't loose this issue. and to speed up things, providing a fix is appreciated ;) On 2/23/07, Zdeněk Sochor [EMAIL PROTECTED] wrote: Hi, by looking at org.apache.myfaces.custom.dojoDojoUtils class i found 1 issue, which could block extending usability of dojo. Problem is in static method getAttributeMap(FacesContext, String[] , UIComponent): - it doesn't count with preferred way of declaring get methods dealing with booleans (isAttribute() instead of getAttribute()). Zdenek -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Tomahawk 1.1.5 release plans?
That would indeed be a very good change. Creating your own renderer for Trinidad is quite hard currently... regards, Martin On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: @MyFaces-API: well, Trinidad regards all Trinidad-component classes as a Trinidad-API. We were once discussing on having something like that for MyFaces as well. For Trinidad, a renderer is not in the Trinidad-API, a component is that can change... I think stuff like CoreRenderer or XhtmlRenderer perhaps should be API (just to give an example) -M -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Tomahawk 1.1.5 release plans?
It's Weisswurst we ate! and a lot of that stuff. regards, Martin On 2/23/07, Jeff Bischoff [EMAIL PROTECTED] wrote: I saw that post at the time, but figured it was the result of too much doppelbock and wienerschnitzel. ;) Matthias Wessendorf wrote: Well... there was a meeting in munich, during the october fest... and they discussed that... http://wiki.java.net/bin/view/Projects/JSFDaysMunich2006 *snip* Version synchronization. JSF 2.0 renamed JSF 6 to go with Java EE 6. perhaps it was the beer ;))) On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: 6.0? Seriously? Dennis Byrne On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: there was a wiki page which says that they want to have the next version of jsf (2.0) named 6.0 so... I am not really seeing any reason to go from myfaces 1.2 to a 6 ... :-) On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x I'd rather keep the release numbers in sync with the spec numbers. 1.1 - 1.1.x, 1.2 - 1.2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Dennis Byrne -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[Friday] Re: Tomahawk 1.1.5 release plans?
well... not in muc. only schnitzel Wiener art, which sucks. the original is the better :-)) hefeweizen kills the JSF.next :) -M On 2/23/07, Jeff Bischoff [EMAIL PROTECTED] wrote: I saw that post at the time, but figured it was the result of too much doppelbock and wienerschnitzel. ;) Matthias Wessendorf wrote: Well... there was a meeting in munich, during the october fest... and they discussed that... http://wiki.java.net/bin/view/Projects/JSFDaysMunich2006 *snip* Version synchronization. JSF 2.0 renamed JSF 6 to go with Java EE 6. perhaps it was the beer ;))) On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: 6.0? Seriously? Dennis Byrne On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: there was a wiki page which says that they want to have the next version of jsf (2.0) named 6.0 so... I am not really seeing any reason to go from myfaces 1.2 to a 6 ... :-) On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x I'd rather keep the release numbers in sync with the spec numbers. 1.1 - 1.1.x, 1.2 - 1.2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Dennis Byrne -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[Friday] (was Re: Tomahawk 1.1.5 release plans?)
and tons of beer :-) On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote: It's Weisswurst we ate! and a lot of that stuff. regards, Martin On 2/23/07, Jeff Bischoff [EMAIL PROTECTED] wrote: I saw that post at the time, but figured it was the result of too much doppelbock and wienerschnitzel. ;) Matthias Wessendorf wrote: Well... there was a meeting in munich, during the october fest... and they discussed that... http://wiki.java.net/bin/view/Projects/JSFDaysMunich2006 *snip* Version synchronization. JSF 2.0 renamed JSF 6 to go with Java EE 6. perhaps it was the beer ;))) On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: 6.0? Seriously? Dennis Byrne On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: there was a wiki page which says that they want to have the next version of jsf (2.0) named 6.0 so... I am not really seeing any reason to go from myfaces 1.2 to a 6 ... :-) On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x I'd rather keep the release numbers in sync with the spec numbers. 1.1 - 1.1.x, 1.2 - 1.2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Dennis Byrne -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Commented: (TOMAHAWK-258) sandbox inputSuggestAjax ignores onkeydown event
[
https://issues.apache.org/jira/browse/TOMAHAWK-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475353
]
Stefan Schuster commented on TOMAHAWK-258:
--
This is actually based on the same issues I experienced with the new
tableSuggestAjax component. As the input field gets created by a dojo standard
component it does not know or care about the MyFaces attributes. As an
improvement to the current situation I've applied the same technique on the
inputSuggestAjax as I've done it for tableSuggestAjax (TOMAHAWK-898).
The input field will be generated by the HtmlTextRendererBase and then be
injected into the dojo component. This delegates all the standard attribute
rendering back to the Base, and attributes like disabled or the javascript
event handler work. To do the input field injection it was necessary to create
a subclass of the original dojo ComboBox component which was used previously.
The derived component gets the clientId of the inputField and will inject it
into the component.
sandbox inputSuggestAjax ignores onkeydown event
Key: TOMAHAWK-258
URL: https://issues.apache.org/jira/browse/TOMAHAWK-258
Project: MyFaces Tomahawk
Issue Type: Bug
Components: InputSuggestAjax
Affects Versions: 1.1.2-SNAPSHOT
Reporter: Juergen Melzer
Assigned To: Gerald Müllan
I created a field like:
s:inputSuggestAjax suggestedItemsMethod=#{editUser.getUserNames}
id=stellvertreterUserID
value=#{editUser.activeSubstitute}
onkeydown=alert('Hallo')
onclick=alert('Hallo')/
But no javascript event are generated...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Tomahawk 1.1.5 release plans?
Yes, of course. Sorry for bringing total confusion into this thread! Although it might seem so, I declare that I did NOT yet drink any beer today. (Only a small glass of wine... ;-) I am +1 for Paul's suggestion: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x and I am +1 for JSF 2.0 (or JSF6 or whatever) - MyFaces 3.x --Manfred On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote: Dennis was suggesting JSF 1.1 -- MyFaces 1.1 JSF 1.2 -- MyFaces 1.2 I'm against that - Manfred, your suggestion sounds good. @MyFaces-API: well, Trinidad regards all Trinidad-component classes as a Trinidad-API. We were once discussing on having something like that for MyFaces as well. For Trinidad, a renderer is not in the Trinidad-API, a component is regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Well, in reallife there should not be (better: must not be) such a thing like a MyFaces-API that differs from the JSF-API, but: Every JSF-Implementation is free to implement certain add-on features or optimizations. These are the things you normally configure with those web.xml config-params. So, what you actually mean when you say MyFaces-API are those features, right? I agree that we need the option to differ between such a feature addition/remove (minor change) and a bug fix release. Therefore +1 on Dennis' suggestion (JSF 1.1 - MyFaces 1.x, JSF 1.2 - MyFaces 2.x) --Manfred On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Dennis, the problem is that you don't have any leeway to change the MyFaces-API (read: not JSF API) incompatible to what it had been before. Well, given we finally reach the point at which we have a pretty stable API between bugfix-releases. regards, Martin On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x I'd rather keep the release numbers in sync with the spec numbers. 1.1 - 1.1.x, 1.2 - 1.2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Dennis Byrne -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: svn commit: r510950 - /myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd
The Geronimo project recently encountered this situation for several JEE schemas. It wasn't totally clear whether or not including the Sun XSDs was OK, and it was soon realized that it would be more practical to type in the XSDs by hand than try to reach a definitive conclusion. See this JIRA for details: https://issues.apache.org/jira/browse/GERONIMO-2630 Also, if you end up typing in a schema there is a utility attached to that JIRA that can be used to compare schemas to make sure they are equivalent. Best wishes, Paul On 2/23/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: I wasn't aware of this. the dtds of 1.0 and 1.1 are also present in our repository... 2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]: isn't that CCLD for what ever their OS license is named ? Should go to the notice.txt file, IMO -M On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: Not to slow you down, but can we distribute this? Dennis Byrne On 2/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: mbr Date: Fri Feb 23 06:18:39 2007 New Revision: 510950 URL: http://svn.apache.org/viewvc?view=revrev=510950 Log: add 1.2 xsd Added: myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd Added: myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd URL: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd?view=autorev=510950 == --- myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd (added) +++ myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd Fri Feb 23 06:18:39 2007 @@ -0,0 +1,2071 @@ +?xml version = 1.0 encoding = UTF-8? + +xsd:schema + targetNamespace=http://java.sun.com/xml/ns/javaee + xmlns:javaee=http://java.sun.com/xml/ns/javaee; + xmlns:xsd=http://www.w3.org/2001/XMLSchema + xmlns:xml=http://www.w3.org/XML/1998/namespace; + elementFormDefault=qualified + attributeFormDefault=unqualified + version=1.2 + +xsd:annotation +xsd:documentation +$Id: web-facesconfig_1_2.xsd,v 1.11 2006/03/27 00:12:24 rogerk Exp $ +/xsd:documentation +/xsd:annotation + +xsd:annotation +xsd:documentation + +Copyright 2005 Sun Microsystems, Inc., +901 San Antonio Road, +Palo Alto, California 94303, U.S.A. +All rights reserved. + +Sun Microsystems, Inc. has intellectual property +rights relating to technology described in this document. In +particular, and without limitation, these intellectual +property rights may include one or more of the U.S. patents +listed at http://www.sun.com/patents and one or more +additional patents or pending patent applications in the +U.S. and other countries. + +This document and the technology which it describes are +distributed under licenses restricting their use, copying, +distribution, and decompilation. No part of this document +may be reproduced in any form by any means without prior +written authorization of Sun and its licensors, if any. + +Third-party software, including font technology, is +copyrighted and licensed from Sun suppliers. + +Sun, Sun Microsystems, the Sun logo, Solaris, Java, Java EE, +JavaServer Pages, Enterprise JavaBeans and the Java Coffee +Cup logo are trademarks or registered trademarks of Sun +Microsystems, Inc. in the U.S. and other countries. + +Federal Acquisitions: Commercial Software - Government Users +Subject to Standard License Terms and Conditions. + +/xsd:documentation +/xsd:annotation + +xsd:annotation +xsd:documentation + +![CDATA[ + +The XML Schema for the JavaServer Faces Application +Configuration File (Version 1.2). + +All JavaServer Faces configuration files must indicate +the JavaServer Faces schema by indicating the JavaServer +Faces namespace: + +http://java.sun.com/xml/ns/javaee + +and by indicating the version of the schema by +using the version element as shown below: + +faces-config xmlns=http://java.sun.com/xml/ns/javaee; +xmlns:xsi=
[jira] Updated: (TOMAHAWK-258) sandbox inputSuggestAjax ignores onkeydown event
[
https://issues.apache.org/jira/browse/TOMAHAWK-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Schuster updated TOMAHAWK-258:
-
Status: Patch Available (was: Open)
sandbox inputSuggestAjax ignores onkeydown event
Key: TOMAHAWK-258
URL: https://issues.apache.org/jira/browse/TOMAHAWK-258
Project: MyFaces Tomahawk
Issue Type: Bug
Components: InputSuggestAjax
Affects Versions: 1.1.2-SNAPSHOT
Reporter: Juergen Melzer
Assigned To: Gerald Müllan
Attachments: InputSuggestAjax.patch
I created a field like:
s:inputSuggestAjax suggestedItemsMethod=#{editUser.getUserNames}
id=stellvertreterUserID
value=#{editUser.activeSubstitute}
onkeydown=alert('Hallo')
onclick=alert('Hallo')/
But no javascript event are generated...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Tomahawk 1.1.5 release plans?
I am +1 for Paul's suggestion: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x and I am +1 for JSF 2.0 (or JSF6 or whatever) - MyFaces 3.x thanks!!
Suggested Version number roadmap (was Re: Tomahawk 1.1.5 release plans?)
This is to summarize the version number discussion. MyFaces for JSF 1.1 1.1.5 - Current Release (Announced 19-Feb-2007) 1.1.6 - Next release not currently scheduled MyFaces for JSF 1.2 2.0.0 - Currently being developed as MyFaces 1.2 MyFaces for JSF 2.0 / JSF 6 3.0.0 - ? Tomahawk for JSF 1.1 1.1.3 - Current Release (Announced 14-Jun-2006) 1.1.5 - Next release, currently in process 1.6.0 - Following release Tomahawk for JSF 1.2 2.x - Not started Paul Spencer
Re: Suggested Version number roadmap (was Re: Tomahawk 1.1.5 release plans?)
+1 Thanks! --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: This is to summarize the version number discussion. MyFaces for JSF 1.1 1.1.5 - Current Release (Announced 19-Feb-2007) 1.1.6 - Next release not currently scheduled MyFaces for JSF 1.2 2.0.0 - Currently being developed as MyFaces 1.2 MyFaces for JSF 2.0 / JSF 6 3.0.0 - ? Tomahawk for JSF 1.1 1.1.3 - Current Release (Announced 14-Jun-2006) 1.1.5 - Next release, currently in process 1.6.0 - Following release Tomahawk for JSF 1.2 2.x - Not started Paul Spencer
Re: svn commit: r510950 - /myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd
That could be difficult to prove but I'm willing to testify that the person who typed in most of the specs by hand looked very very exhausted afterwards :-) Best wishes, Paul On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote: Wow. I wonder how anyone will ever find out if they typed it or if they just copied ;) regards, Martin On 2/23/07, Paul McMahan [EMAIL PROTECTED] wrote: The Geronimo project recently encountered this situation for several JEE schemas. It wasn't totally clear whether or not including the Sun XSDs was OK, and it was soon realized that it would be more practical to type in the XSDs by hand than try to reach a definitive conclusion. See this JIRA for details: https://issues.apache.org/jira/browse/GERONIMO-2630 Also, if you end up typing in a schema there is a utility attached to that JIRA that can be used to compare schemas to make sure they are equivalent. Best wishes, Paul On 2/23/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: I wasn't aware of this. the dtds of 1.0 and 1.1 are also present in our repository... 2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]: isn't that CCLD for what ever their OS license is named ? Should go to the notice.txt file, IMO -M On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: Not to slow you down, but can we distribute this? Dennis Byrne On 2/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: mbr Date: Fri Feb 23 06:18:39 2007 New Revision: 510950 URL: http://svn.apache.org/viewvc?view=revrev=510950 Log: add 1.2 xsd Added: myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd Added: myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd URL: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd?view=autorev=510950 == --- myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd (added) +++ myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd Fri Feb 23 06:18:39 2007 @@ -0,0 +1,2071 @@ +?xml version = 1.0 encoding = UTF-8? + +xsd:schema + targetNamespace=http://java.sun.com/xml/ns/javaee + xmlns:javaee=http://java.sun.com/xml/ns/javaee; + xmlns:xsd=http://www.w3.org/2001/XMLSchema + xmlns:xml=http://www.w3.org/XML/1998/namespace; + elementFormDefault=qualified + attributeFormDefault=unqualified + version=1.2 + +xsd:annotation +xsd:documentation +$Id: web-facesconfig_1_2.xsd,v 1.11 2006/03/27 00:12:24 rogerk Exp $ +/xsd:documentation +/xsd:annotation + +xsd:annotation +xsd:documentation + +Copyright 2005 Sun Microsystems, Inc., +901 San Antonio Road, +Palo Alto, California 94303, U.S.A. +All rights reserved. + +Sun Microsystems, Inc. has intellectual property +rights relating to technology described in this document. In +particular, and without limitation, these intellectual +property rights may include one or more of the U.S. patents +listed at http://www.sun.com/patents and one or more +additional patents or pending patent applications in the +U.S. and other countries. + +This document and the technology which it describes are +distributed under licenses restricting their use, copying, +distribution, and decompilation. No part of this document +may be reproduced in any form by any means without prior +written authorization of Sun and its licensors, if any. + +Third-party software, including font technology, is +copyrighted and licensed from Sun suppliers. + +Sun, Sun Microsystems, the Sun logo, Solaris, Java, Java EE, +JavaServer Pages, Enterprise JavaBeans and the Java Coffee +Cup logo are trademarks or registered trademarks of Sun +Microsystems, Inc. in the U.S. and other countries. + +Federal Acquisitions: Commercial Software - Government Users +Subject to Standard License Terms and Conditions. + +/xsd:documentation +/xsd:annotation + +xsd:annotation +xsd:documentation + +![CDATA[ + +The XML
Re: svn commit: r510950 - /myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd
Wow. I wonder how anyone will ever find out if they typed it or if they just copied ;) regards, Martin On 2/23/07, Paul McMahan [EMAIL PROTECTED] wrote: The Geronimo project recently encountered this situation for several JEE schemas. It wasn't totally clear whether or not including the Sun XSDs was OK, and it was soon realized that it would be more practical to type in the XSDs by hand than try to reach a definitive conclusion. See this JIRA for details: https://issues.apache.org/jira/browse/GERONIMO-2630 Also, if you end up typing in a schema there is a utility attached to that JIRA that can be used to compare schemas to make sure they are equivalent. Best wishes, Paul On 2/23/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: I wasn't aware of this. the dtds of 1.0 and 1.1 are also present in our repository... 2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]: isn't that CCLD for what ever their OS license is named ? Should go to the notice.txt file, IMO -M On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: Not to slow you down, but can we distribute this? Dennis Byrne On 2/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: mbr Date: Fri Feb 23 06:18:39 2007 New Revision: 510950 URL: http://svn.apache.org/viewvc?view=revrev=510950 Log: add 1.2 xsd Added: myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd Added: myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd URL: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd?view=autorev=510950 == --- myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd (added) +++ myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd Fri Feb 23 06:18:39 2007 @@ -0,0 +1,2071 @@ +?xml version = 1.0 encoding = UTF-8? + +xsd:schema + targetNamespace=http://java.sun.com/xml/ns/javaee + xmlns:javaee=http://java.sun.com/xml/ns/javaee; + xmlns:xsd=http://www.w3.org/2001/XMLSchema + xmlns:xml=http://www.w3.org/XML/1998/namespace; + elementFormDefault=qualified + attributeFormDefault=unqualified + version=1.2 + +xsd:annotation +xsd:documentation +$Id: web-facesconfig_1_2.xsd,v 1.11 2006/03/27 00:12:24 rogerk Exp $ +/xsd:documentation +/xsd:annotation + +xsd:annotation +xsd:documentation + +Copyright 2005 Sun Microsystems, Inc., +901 San Antonio Road, +Palo Alto, California 94303, U.S.A. +All rights reserved. + +Sun Microsystems, Inc. has intellectual property +rights relating to technology described in this document. In +particular, and without limitation, these intellectual +property rights may include one or more of the U.S. patents +listed at http://www.sun.com/patents and one or more +additional patents or pending patent applications in the +U.S. and other countries. + +This document and the technology which it describes are +distributed under licenses restricting their use, copying, +distribution, and decompilation. No part of this document +may be reproduced in any form by any means without prior +written authorization of Sun and its licensors, if any. + +Third-party software, including font technology, is +copyrighted and licensed from Sun suppliers. + +Sun, Sun Microsystems, the Sun logo, Solaris, Java, Java EE, +JavaServer Pages, Enterprise JavaBeans and the Java Coffee +Cup logo are trademarks or registered trademarks of Sun +Microsystems, Inc. in the U.S. and other countries. + +Federal Acquisitions: Commercial Software - Government Users +Subject to Standard License Terms and Conditions. + +/xsd:documentation +/xsd:annotation + +xsd:annotation +xsd:documentation + +![CDATA[ + +The XML Schema for the JavaServer Faces Application +Configuration File (Version 1.2). + +All JavaServer Faces configuration files must indicate +the JavaServer Faces schema by indicating the JavaServer +Faces namespace: + +http://java.sun.com/xml/ns/javaee + +
Re: svn commit: r510950 - /myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd
I can imagine ;) regards, Martin On 2/23/07, Paul McMahan [EMAIL PROTECTED] wrote: That could be difficult to prove but I'm willing to testify that the person who typed in most of the specs by hand looked very very exhausted afterwards :-) Best wishes, Paul On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote: Wow. I wonder how anyone will ever find out if they typed it or if they just copied ;) regards, Martin On 2/23/07, Paul McMahan [EMAIL PROTECTED] wrote: The Geronimo project recently encountered this situation for several JEE schemas. It wasn't totally clear whether or not including the Sun XSDs was OK, and it was soon realized that it would be more practical to type in the XSDs by hand than try to reach a definitive conclusion. See this JIRA for details: https://issues.apache.org/jira/browse/GERONIMO-2630 Also, if you end up typing in a schema there is a utility attached to that JIRA that can be used to compare schemas to make sure they are equivalent. Best wishes, Paul On 2/23/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: I wasn't aware of this. the dtds of 1.0 and 1.1 are also present in our repository... 2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]: isn't that CCLD for what ever their OS license is named ? Should go to the notice.txt file, IMO -M On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: Not to slow you down, but can we distribute this? Dennis Byrne On 2/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: mbr Date: Fri Feb 23 06:18:39 2007 New Revision: 510950 URL: http://svn.apache.org/viewvc?view=revrev=510950 Log: add 1.2 xsd Added: myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd Added: myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd URL: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd?view=autorev=510950 == --- myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd (added) +++ myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd Fri Feb 23 06:18:39 2007 @@ -0,0 +1,2071 @@ +?xml version = 1.0 encoding = UTF-8? + +xsd:schema + targetNamespace=http://java.sun.com/xml/ns/javaee + xmlns:javaee=http://java.sun.com/xml/ns/javaee; + xmlns:xsd=http://www.w3.org/2001/XMLSchema + xmlns:xml=http://www.w3.org/XML/1998/namespace; + elementFormDefault=qualified + attributeFormDefault=unqualified + version=1.2 + +xsd:annotation +xsd:documentation +$Id: web-facesconfig_1_2.xsd,v 1.11 2006/03/27 00:12:24 rogerk Exp $ +/xsd:documentation +/xsd:annotation + +xsd:annotation +xsd:documentation + +Copyright 2005 Sun Microsystems, Inc., +901 San Antonio Road, +Palo Alto, California 94303, U.S.A. +All rights reserved. + +Sun Microsystems, Inc. has intellectual property +rights relating to technology described in this document. In +particular, and without limitation, these intellectual +property rights may include one or more of the U.S. patents +listed at http://www.sun.com/patents and one or more +additional patents or pending patent applications in the +U.S. and other countries. + +This document and the technology which it describes are +distributed under licenses restricting their use, copying, +distribution, and decompilation. No part of this document +may be reproduced in any form by any means without prior +written authorization of Sun and its licensors, if any. + +Third-party software, including font technology, is +copyrighted and licensed from Sun suppliers. + +Sun, Sun Microsystems, the Sun logo, Solaris, Java, Java EE, +JavaServer Pages, Enterprise JavaBeans and the Java Coffee +Cup logo are trademarks or registered trademarks of Sun +Microsystems, Inc. in the U.S. and other countries. + +Federal Acquisitions: Commercial Software - Government Users +Subject to Standard License Terms and
[jira] Updated: (TOMAHAWK-258) sandbox inputSuggestAjax ignores onkeydown event
[
https://issues.apache.org/jira/browse/TOMAHAWK-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerald Müllan updated TOMAHAWK-258:
---
Resolution: Fixed
Fix Version/s: 1.1.5-SNAPSHOT
Status: Resolved (was: Patch Available)
Thx one more time to Stefan for fixing a dojo-component related issue.
sandbox inputSuggestAjax ignores onkeydown event
Key: TOMAHAWK-258
URL: https://issues.apache.org/jira/browse/TOMAHAWK-258
Project: MyFaces Tomahawk
Issue Type: Bug
Components: InputSuggestAjax
Affects Versions: 1.1.2-SNAPSHOT
Reporter: Juergen Melzer
Assigned To: Gerald Müllan
Fix For: 1.1.5-SNAPSHOT
Attachments: InputSuggestAjax.patch
I created a field like:
s:inputSuggestAjax suggestedItemsMethod=#{editUser.getUserNames}
id=stellvertreterUserID
value=#{editUser.activeSubstitute}
onkeydown=alert('Hallo')
onclick=alert('Hallo')/
But no javascript event are generated...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Suggested Version number roadmap (was Re: Tomahawk 1.1.5 release plans?)
Paul Spencer wrote: This is to summarize the version number discussion. MyFaces for JSF 1.1 1.1.5 - Current Release (Announced 19-Feb-2007) 1.1.6 - Next release not currently scheduled MyFaces for JSF 1.2 2.0.0 - Currently being developed as MyFaces 1.2 MyFaces for JSF 2.0 / JSF 6 3.0.0 - ? Tomahawk for JSF 1.1 1.1.3 - Current Release (Announced 14-Jun-2006) 1.1.5 - Next release, currently in process 1.6.0 - Following release Tomahawk for JSF 1.2 2.x - Not started Paul Spencer Wow, that looks pretty good. :)
Re: svn commit: r510950 - /myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd
Check it in as you go along, and that should provide a record. On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote: Wow. I wonder how anyone will ever find out if they typed it or if they just copied ;) regards, Martin On 2/23/07, Paul McMahan [EMAIL PROTECTED] wrote: The Geronimo project recently encountered this situation for several JEE schemas. It wasn't totally clear whether or not including the Sun XSDs was OK, and it was soon realized that it would be more practical to type in the XSDs by hand than try to reach a definitive conclusion. See this JIRA for details: https://issues.apache.org/jira/browse/GERONIMO-2630 Also, if you end up typing in a schema there is a utility attached to that JIRA that can be used to compare schemas to make sure they are equivalent. Best wishes, Paul On 2/23/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: I wasn't aware of this. the dtds of 1.0 and 1.1 are also present in our repository... 2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]: isn't that CCLD for what ever their OS license is named ? Should go to the notice.txt file, IMO -M On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: Not to slow you down, but can we distribute this? Dennis Byrne On 2/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: mbr Date: Fri Feb 23 06:18:39 2007 New Revision: 510950 URL: http://svn.apache.org/viewvc?view=revrev=510950 Log: add 1.2 xsd Added: myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd Added: myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd URL: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd?view=autorev=510950 == --- myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd (added) +++ myfaces/core/branches/jsf12/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_2.xsd Fri Feb 23 06:18:39 2007 @@ -0,0 +1,2071 @@ +?xml version = 1.0 encoding = UTF-8? + +xsd:schema + targetNamespace=http://java.sun.com/xml/ns/javaee + xmlns:javaee=http://java.sun.com/xml/ns/javaee; + xmlns:xsd=http://www.w3.org/2001/XMLSchema + xmlns:xml=http://www.w3.org/XML/1998/namespace; + elementFormDefault=qualified + attributeFormDefault=unqualified + version=1.2 + +xsd:annotation +xsd:documentation +$Id: web-facesconfig_1_2.xsd,v 1.11 2006/03/27 00:12:24 rogerk Exp $ +/xsd:documentation +/xsd:annotation + +xsd:annotation +xsd:documentation + +Copyright 2005 Sun Microsystems, Inc., +901 San Antonio Road, +Palo Alto, California 94303, U.S.A. +All rights reserved. + +Sun Microsystems, Inc. has intellectual property +rights relating to technology described in this document. In +particular, and without limitation, these intellectual +property rights may include one or more of the U.S. patents +listed at http://www.sun.com/patents and one or more +additional patents or pending patent applications in the +U.S. and other countries. + +This document and the technology which it describes are +distributed under licenses restricting their use, copying, +distribution, and decompilation. No part of this document +may be reproduced in any form by any means without prior +written authorization of Sun and its licensors, if any. + +Third-party software, including font technology, is +copyrighted and licensed from Sun suppliers. + +Sun, Sun Microsystems, the Sun logo, Solaris, Java, Java EE, +JavaServer Pages, Enterprise JavaBeans and the Java Coffee +Cup logo are trademarks or registered trademarks of Sun +Microsystems, Inc. in the U.S. and other countries. + +Federal Acquisitions: Commercial Software - Government Users +Subject to Standard License Terms and Conditions. + +/xsd:documentation +/xsd:annotation + +xsd:annotation +xsd:documentation + +![CDATA[ + +The XML Schema for the JavaServer Faces Application +Configuration File (Version 1.2). + +
Re: MyFaces Fusion
Hi Arash! It looks like this fusion lead a more pure MyFaces application. and I am ready to use it, if you provide some minimum guidelines for rest of us. Yep, I am working on it ... should be available soonish. Ciao, Mario
[jira] Created: (TOMAHAWK-906) DojoUtils class not handling isAttribute methods in components
DojoUtils class not handling isAttribute methods in components -- Key: TOMAHAWK-906 URL: https://issues.apache.org/jira/browse/TOMAHAWK-906 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT Reporter: Zdenek Sochor Attachments: dojo.txt Hi, by looking at org.apache.myfaces.custom.dojoDojoUtils class i found 1 issue, which could block extending usability of dojo. Problem is in static method getAttributeMap(FacesContext, String[] , UIComponent): - it doesn't count with preferred way of declaring get methods dealing with booleans (isAttribute() instead of getAttribute()). Zdenek -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-906) DojoUtils class not handling isAttribute methods in components
[ https://issues.apache.org/jira/browse/TOMAHAWK-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zdenek Sochor updated TOMAHAWK-906: --- Status: Patch Available (was: Open) DojoUtils class not handling isAttribute methods in components -- Key: TOMAHAWK-906 URL: https://issues.apache.org/jira/browse/TOMAHAWK-906 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT Reporter: Zdenek Sochor Attachments: dojo.txt Hi, by looking at org.apache.myfaces.custom.dojoDojoUtils class i found 1 issue, which could block extending usability of dojo. Problem is in static method getAttributeMap(FacesContext, String[] , UIComponent): - it doesn't count with preferred way of declaring get methods dealing with booleans (isAttribute() instead of getAttribute()). Zdenek -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Suggested Version number roadmap (was Re: Tomahawk 1.1.5 release plans?)
I don't think Tomahawk has proved yet that it is independent from core versioning. Take the MyFaces Core 1.1.4 incompatiblities between Tomahawk 1.1.5 as an example. I think we should take a wait and see attitude before we decide we're going to start with Tomahawk 1.6 numbering.Remember, we started with Tomahawk 1.1.3 as independent of core and we've still not accomplished the task with releases to date. And if it's truely independent from the core, then it would mean that someone could use Tomahawk 1.1.5 for any version of MyFaces, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.0.9, etc., and we know that's not the case. -Mike On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: This is to summarize the version number discussion. MyFaces for JSF 1.1 1.1.5 - Current Release (Announced 19-Feb-2007) 1.1.6 - Next release not currently scheduled MyFaces for JSF 1.2 2.0.0 - Currently being developed as MyFaces 1.2 MyFaces for JSF 2.0 / JSF 6 3.0.0 - ? Tomahawk for JSF 1.1 1.1.3 - Current Release (Announced 14-Jun-2006) 1.1.5 - Next release, currently in process 1.6.0 - Following release Tomahawk for JSF 1.2 2.x - Not started Paul Spencer
[jira] Created: (TOMAHAWK-907) Incorrect behaviour of HtmlInputText with ajax
Incorrect behaviour of HtmlInputText with ajax -- Key: TOMAHAWK-907 URL: https://issues.apache.org/jira/browse/TOMAHAWK-907 Project: MyFaces Tomahawk Issue Type: Bug Components: AJAX Form Components Affects Versions: 1.1.5-SNAPSHOT Reporter: Zdenek Sochor Attachments: patch.txt Hi, TableSuggestAjax is behaving incorrectly after restore view phase in JSF. This is due to incorrect implementation of org.apache.myfaces.component.html.ext.HtmlInputText class - attribute autocomplete is NOT stored/restored (in saveState/restoreState methods). And question - why is autocomplete attribute implemented as String instead of Boolean? Zdenek -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Proposed changes to t:dataTable regarding the new EL specification
If there's no objections, I'll open a JIRA and submit a patch. :)
Mike Kienenberger wrote:
This change looks good to me. It's probably more important that the
value binding be able to default to null than to output an empty
string css style.
On 2/22/07, Jeff Bischoff [EMAIL PROTECTED] wrote:
Greets,
After converting my application from JSP to Facelets, I set out to make
my rowStyleClass attribute on t:dataTable work like it used to.
First, I had to get the attribute working in Facelets. With considerable
discussion on the user list (see [1] and [2]) and a lot of help from
Mike, I think we've identified some pretty simple code changes to enable
this and other similar attributes. I plan to introduce a patch for this,
probably tomorrow.
What happened next was that during testing of this change, I could
confirm that the attribute did indeed now work, but I was baffled by
unexpected behaviour. My EL expression which had previously returned
null in certain situations was now returning the empty String. I went to
Facelets list for some clarification on this (see [3]) and it turned out
to be a requirement of the new EL spec to coerce the nulls into empty
string.
Getting an empty String instead of null for this ValueBinding lookup
creates a problem because the extended dataTable treats a null value
differently and goes looking at the more standard style attributes like
rowClasses. With an empty string returned, it assumes it needs to look
no further. As a user, there is no way for me to specify that under
certain conditions, it should fallback to the other style attributes,
e.g. rowClasses.
The best fix we have collectively come up with so far is to coerce the
empty string back into a null in the dataTable, so that the renderer
does the right thing. I don't see too much downside to this approach, as
an empty style string has no relevance in CSS. However, I feel a
proposed change like this requires extra discussion before making a
decision on it. It's another one of those situation where we have to
decide how we want to handle unexpected results due to changes in the
newer specs.
If you review the threads a bit, you can see more of the details of the
issues. I'll post my preliminary proposed code changes at the bottom.
[1] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6875
[2]
http://www.nabble.com/Re%3A-Facelets-support-for-a-Tomahawk-dataTable-trick--tf3236491.html
[3] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6941
Regards,
Jeff Bischoff
Kenneth L Kurz Associates, Inc.
Okay proposed code change in
org.apache.myfaces.component.html.ext.HtmlDataTable
Original Method:
public String getRowStyleClass()
{
if (_rowStyleClass != null)
return _rowStyleClass;
ValueBinding vb = getValueBinding(JSFAttr.ROW_STYLECLASS_ATTR);
return vb != null ? (String) vb.getValue(getFacesContext()) :
null;
}
New Method:
public String getRowStyleClass()
{
if (_rowStyleClass != null)
return _rowStyleClass;
// TODO: temporarily support fully-qualified ext. dataTable
attribute names.
ValueBinding vb =
getValueBinding(org.apache.myfaces.dataTable.ROW_STYLECLASS);
if (vb != null)
log.warn(org.apache.myfaces.dataTable.ROW_STYLECLASS is
deprecated. Please use rowStyleClass instead.);
else
vb = getValueBinding(JSFAttr.ROW_STYLECLASS_ATTR);
if(vb == null)
return null;
String bindingValue = (String) vb.getValue(getFacesContext());
if(bindingValue == )
return null; // Fix for JSF 1.2 EL coercing nulls to empty
string
return bindingValue;
}
That, along with the change to JSFAttr to change the constant value from
org.apache.myfaces.dataTable.ROW_STYLECLASS to rowStyleClass. NOTE:
This change affects the shared code!
[jira] Created: (TOMAHAWK-908) t:div and t::inputCalendar confilict
t:div and t::inputCalendar confilict
-
Key: TOMAHAWK-908
URL: https://issues.apache.org/jira/browse/TOMAHAWK-908
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Calendar
Environment: Tomahawk1.1.5 and Tomahawk-sandbox1.1.5 Windows XP tomcat
5.5.15
Reporter: Cathy Gates
Fix For: 1.1.5-SNAPSHOT
When I include a calendar within a fieldset using tomahawk 1.5 calendar and and
tomahawk sandbox fieldset the calendar pop-up window always display at the
bottom right corner of the screen. When I replace the fieldset with a panelGrid
everything works fine and the calendar popup window appears near the calendar
textbox.
Below is part of the jsp I'm using.
Any help is appreciated!
t:div style=width:95%
s:fieldset legend=#{reportMsg.reportFormatLegendLabel} style=padding:20px
20px;text-align: center;
h:outputText value=#{reportMsg.startDateLabel}/
t:inputCalendar id=startDate popupDateFormat=MM/dd/
currentDayCellClass=currentDayCell value=#{companyReport.startDate}
renderAsPopup=true popupTodayString=#{commonMsg.popupTodayString}
popupWeekString=#{commonMsg.popupWeekString} renderPopupButtonAsImage=true
helpText=MM/DD//
/s:fieldset
/t:div
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Next version Tomahawk 1.6 or 1.1.6 (was Re: Suggested Version number roadmap )
Mike, As soon as Tomahawk is compatible with the JSF 1.1 spec, then it should be considered implementation independent. If their are known incompatibilities with an implementation, i.e. MyFaces 1.1.4, then those should be noted in Tomahawk's release notes. We can make the testing easer by defining implementation specific profiles for testing Tomahawk against different MyFaces versions, and any other JSF implementations, using profiles. This is currently done in Tomahawk's example pom.xml. See the Deploy with Sun's RI section of the Selenium testing page [1]. Keeping in mind we may want to change the answer in the future, what should the next version be? __ 1.6.0 - JSF 1.1 implementation independent __ 1.1.6 - Dependent on MyFaces 1.1.6 Paul Spencer [1] http://myfaces.apache.org/tomahawk/testing/selenium.html Mike Kienenberger wrote: I don't think Tomahawk has proved yet that it is independent from core versioning. Take the MyFaces Core 1.1.4 incompatiblities between Tomahawk 1.1.5 as an example. I think we should take a wait and see attitude before we decide we're going to start with Tomahawk 1.6 numbering.Remember, we started with Tomahawk 1.1.3 as independent of core and we've still not accomplished the task with releases to date. And if it's truely independent from the core, then it would mean that someone could use Tomahawk 1.1.5 for any version of MyFaces, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.0.9, etc., and we know that's not the case. -Mike On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: This is to summarize the version number discussion. MyFaces for JSF 1.1 1.1.5 - Current Release (Announced 19-Feb-2007) 1.1.6 - Next release not currently scheduled MyFaces for JSF 1.2 2.0.0 - Currently being developed as MyFaces 1.2 MyFaces for JSF 2.0 / JSF 6 3.0.0 - ? Tomahawk for JSF 1.1 1.1.3 - Current Release (Announced 14-Jun-2006) 1.1.5 - Next release, currently in process 1.6.0 - Following release Tomahawk for JSF 1.2 2.x - Not started Paul Spencer
[jira] Commented: (TOMAHAWK-906) DojoUtils class not handling isAttribute methods in components
[ https://issues.apache.org/jira/browse/TOMAHAWK-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475419 ] Werner Punz commented on TOMAHAWK-906: -- Well the reason why is was ignored was, because it was assumed, that the return values aways had to be of the type ? extends Object but is normally is not applied to methods with the return Value boolean. But on a second thought covering is.. makes sense, in the sense that it covers all possible property method naming conventions. I have to thank a lot for the patch. it is a applied and commited. Thank you very much, help and patches are always welcome. DojoUtils class not handling isAttribute methods in components -- Key: TOMAHAWK-906 URL: https://issues.apache.org/jira/browse/TOMAHAWK-906 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT Reporter: Zdenek Sochor Assigned To: Werner Punz Attachments: dojo.txt Hi, by looking at org.apache.myfaces.custom.dojoDojoUtils class i found 1 issue, which could block extending usability of dojo. Problem is in static method getAttributeMap(FacesContext, String[] , UIComponent): - it doesn't count with preferred way of declaring get methods dealing with booleans (isAttribute() instead of getAttribute()). Zdenek -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: DojoUtils class improvement needed
Zdeněk Sochor schrieb: Hi, by looking at org.apache.myfaces.custom.dojoDojoUtils class i found 1 issue, which could block extending usability of dojo. Problem is in static method getAttributeMap(FacesContext, String[] , UIComponent): - it doesn't count with preferred way of declaring get methods dealing with booleans (isAttribute() instead of getAttribute()). Actually I added this comment as well to the issue. First of all thanks for the patch it is in the codebase. Such issues always are the best we have way too few of them. There was a reason why I did not implement the reflection for the isxxx property Methods. It is not clear from the viewpoint of the DojoUtils, but when I wrote the code (bear in mind it has been a long time ago) I basically went for java objects not native types, isxxx is not common on java.lang.Boolean only for boolean. But after reading your patch and thinking things over, it makes sense to cover is.. as well for property accessors. First of all things move slowly but steadily towards jdk 5 where the line between Objects and native types finally becomes more blurred so we will probably see is on Boolean values more often. Secondly it simply makes sense to cover it because all property accessor methods have to be covered. So to sum it up, thanks for the patch, I just committed it. Werner
Re: Next version Tomahawk 1.6 or 1.1.6 (was Re: Suggested Version number roadmap )
I think it's too soon to be making the decision on what to call the next version. Let's wait and see how things go with a Tomahawk 1.1.5 release. We're still encountering dependency issues with current Tomahawk releases. We've promised to deliver implementation-dependent releases twice in the past and failed. Let's wait and see before making that promise again. On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: Mike, As soon as Tomahawk is compatible with the JSF 1.1 spec, then it should be considered implementation independent. If their are known incompatibilities with an implementation, i.e. MyFaces 1.1.4, then those should be noted in Tomahawk's release notes. We can make the testing easer by defining implementation specific profiles for testing Tomahawk against different MyFaces versions, and any other JSF implementations, using profiles. This is currently done in Tomahawk's example pom.xml. See the Deploy with Sun's RI section of the Selenium testing page [1]. Keeping in mind we may want to change the answer in the future, what should the next version be? __ 1.6.0 - JSF 1.1 implementation independent __ 1.1.6 - Dependent on MyFaces 1.1.6 Paul Spencer [1] http://myfaces.apache.org/tomahawk/testing/selenium.html Mike Kienenberger wrote: I don't think Tomahawk has proved yet that it is independent from core versioning. Take the MyFaces Core 1.1.4 incompatiblities between Tomahawk 1.1.5 as an example. I think we should take a wait and see attitude before we decide we're going to start with Tomahawk 1.6 numbering.Remember, we started with Tomahawk 1.1.3 as independent of core and we've still not accomplished the task with releases to date. And if it's truely independent from the core, then it would mean that someone could use Tomahawk 1.1.5 for any version of MyFaces, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.0.9, etc., and we know that's not the case. -Mike On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: This is to summarize the version number discussion. MyFaces for JSF 1.1 1.1.5 - Current Release (Announced 19-Feb-2007) 1.1.6 - Next release not currently scheduled MyFaces for JSF 1.2 2.0.0 - Currently being developed as MyFaces 1.2 MyFaces for JSF 2.0 / JSF 6 3.0.0 - ? Tomahawk for JSF 1.1 1.1.3 - Current Release (Announced 14-Jun-2006) 1.1.5 - Next release, currently in process 1.6.0 - Following release Tomahawk for JSF 1.2 2.x - Not started Paul Spencer
Re: Next version Tomahawk 1.6 or 1.1.6 (was Re: Suggested Version number roadmap )
Mike, As a part of the 1.1.5 release, the next version is set. Based on your comments, the version should be set to 1.1.6. I have no problem with this. The release of 1.1.5 should not be delayed while we determine the next version number. Paul Spencer Mike Kienenberger wrote: I think it's too soon to be making the decision on what to call the next version. Let's wait and see how things go with a Tomahawk 1.1.5 release. We're still encountering dependency issues with current Tomahawk releases. We've promised to deliver implementation-dependent releases twice in the past and failed. Let's wait and see before making that promise again. On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: Mike, As soon as Tomahawk is compatible with the JSF 1.1 spec, then it should be considered implementation independent. If their are known incompatibilities with an implementation, i.e. MyFaces 1.1.4, then those should be noted in Tomahawk's release notes. We can make the testing easer by defining implementation specific profiles for testing Tomahawk against different MyFaces versions, and any other JSF implementations, using profiles. This is currently done in Tomahawk's example pom.xml. See the Deploy with Sun's RI section of the Selenium testing page [1]. Keeping in mind we may want to change the answer in the future, what should the next version be? __ 1.6.0 - JSF 1.1 implementation independent __ 1.1.6 - Dependent on MyFaces 1.1.6 Paul Spencer [1] http://myfaces.apache.org/tomahawk/testing/selenium.html Mike Kienenberger wrote: I don't think Tomahawk has proved yet that it is independent from core versioning. Take the MyFaces Core 1.1.4 incompatiblities between Tomahawk 1.1.5 as an example. I think we should take a wait and see attitude before we decide we're going to start with Tomahawk 1.6 numbering.Remember, we started with Tomahawk 1.1.3 as independent of core and we've still not accomplished the task with releases to date. And if it's truely independent from the core, then it would mean that someone could use Tomahawk 1.1.5 for any version of MyFaces, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.0.9, etc., and we know that's not the case. -Mike On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: This is to summarize the version number discussion. MyFaces for JSF 1.1 1.1.5 - Current Release (Announced 19-Feb-2007) 1.1.6 - Next release not currently scheduled MyFaces for JSF 1.2 2.0.0 - Currently being developed as MyFaces 1.2 MyFaces for JSF 2.0 / JSF 6 3.0.0 - ? Tomahawk for JSF 1.1 1.1.3 - Current Release (Announced 14-Jun-2006) 1.1.5 - Next release, currently in process 1.6.0 - Following release Tomahawk for JSF 1.2 2.x - Not started Paul Spencer
Re: Next version Tomahawk 1.6 or 1.1.6 (was Re: Suggested Version number roadmap )
Ok. I see where you're going. I also don't want 1.1.5 delayed because of the next release version number. And even if we pick 1.1.6 now, we can release it as 1.6 later. My preference is 1.1.6, but if I'm the only one that feels this way, use 1.6. On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: Mike, As a part of the 1.1.5 release, the next version is set. Based on your comments, the version should be set to 1.1.6. I have no problem with this. The release of 1.1.5 should not be delayed while we determine the next version number. Paul Spencer Mike Kienenberger wrote: I think it's too soon to be making the decision on what to call the next version. Let's wait and see how things go with a Tomahawk 1.1.5 release. We're still encountering dependency issues with current Tomahawk releases. We've promised to deliver implementation-dependent releases twice in the past and failed. Let's wait and see before making that promise again. On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: Mike, As soon as Tomahawk is compatible with the JSF 1.1 spec, then it should be considered implementation independent. If their are known incompatibilities with an implementation, i.e. MyFaces 1.1.4, then those should be noted in Tomahawk's release notes. We can make the testing easer by defining implementation specific profiles for testing Tomahawk against different MyFaces versions, and any other JSF implementations, using profiles. This is currently done in Tomahawk's example pom.xml. See the Deploy with Sun's RI section of the Selenium testing page [1]. Keeping in mind we may want to change the answer in the future, what should the next version be? __ 1.6.0 - JSF 1.1 implementation independent __ 1.1.6 - Dependent on MyFaces 1.1.6 Paul Spencer [1] http://myfaces.apache.org/tomahawk/testing/selenium.html Mike Kienenberger wrote: I don't think Tomahawk has proved yet that it is independent from core versioning. Take the MyFaces Core 1.1.4 incompatiblities between Tomahawk 1.1.5 as an example. I think we should take a wait and see attitude before we decide we're going to start with Tomahawk 1.6 numbering.Remember, we started with Tomahawk 1.1.3 as independent of core and we've still not accomplished the task with releases to date. And if it's truely independent from the core, then it would mean that someone could use Tomahawk 1.1.5 for any version of MyFaces, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.0.9, etc., and we know that's not the case. -Mike On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: This is to summarize the version number discussion. MyFaces for JSF 1.1 1.1.5 - Current Release (Announced 19-Feb-2007) 1.1.6 - Next release not currently scheduled MyFaces for JSF 1.2 2.0.0 - Currently being developed as MyFaces 1.2 MyFaces for JSF 2.0 / JSF 6 3.0.0 - ? Tomahawk for JSF 1.1 1.1.3 - Current Release (Announced 14-Jun-2006) 1.1.5 - Next release, currently in process 1.6.0 - Following release Tomahawk for JSF 1.2 2.x - Not started Paul Spencer
Re: Next version Tomahawk 1.6 or 1.1.6 (was Re: Suggested Version number roadmap )
It will be set, but not in stone. You've changed the version # of snapshots before. :) +1 for this not being a release blocker Paul Spencer wrote: Mike, As a part of the 1.1.5 release, the next version is set. Based on your comments, the version should be set to 1.1.6. I have no problem with this. The release of 1.1.5 should not be delayed while we determine the next version number. Paul Spencer Mike Kienenberger wrote: I think it's too soon to be making the decision on what to call the next version. Let's wait and see how things go with a Tomahawk 1.1.5 release. We're still encountering dependency issues with current Tomahawk releases. We've promised to deliver implementation-dependent releases twice in the past and failed. Let's wait and see before making that promise again. On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: Mike, As soon as Tomahawk is compatible with the JSF 1.1 spec, then it should be considered implementation independent. If their are known incompatibilities with an implementation, i.e. MyFaces 1.1.4, then those should be noted in Tomahawk's release notes. We can make the testing easer by defining implementation specific profiles for testing Tomahawk against different MyFaces versions, and any other JSF implementations, using profiles. This is currently done in Tomahawk's example pom.xml. See the Deploy with Sun's RI section of the Selenium testing page [1]. Keeping in mind we may want to change the answer in the future, what should the next version be? __ 1.6.0 - JSF 1.1 implementation independent __ 1.1.6 - Dependent on MyFaces 1.1.6 Paul Spencer [1] http://myfaces.apache.org/tomahawk/testing/selenium.html Mike Kienenberger wrote: I don't think Tomahawk has proved yet that it is independent from core versioning. Take the MyFaces Core 1.1.4 incompatiblities between Tomahawk 1.1.5 as an example. I think we should take a wait and see attitude before we decide we're going to start with Tomahawk 1.6 numbering.Remember, we started with Tomahawk 1.1.3 as independent of core and we've still not accomplished the task with releases to date. And if it's truely independent from the core, then it would mean that someone could use Tomahawk 1.1.5 for any version of MyFaces, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.0.9, etc., and we know that's not the case. -Mike On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: This is to summarize the version number discussion. MyFaces for JSF 1.1 1.1.5 - Current Release (Announced 19-Feb-2007) 1.1.6 - Next release not currently scheduled MyFaces for JSF 1.2 2.0.0 - Currently being developed as MyFaces 1.2 MyFaces for JSF 2.0 / JSF 6 3.0.0 - ? Tomahawk for JSF 1.1 1.1.3 - Current Release (Announced 14-Jun-2006) 1.1.5 - Next release, currently in process 1.6.0 - Following release Tomahawk for JSF 1.2 2.x - Not started Paul Spencer
jsf12 - jasper ?
line 60 is: _charArrayWriter.writeTo(getResponse().getWriter()); I am getting this, when running a app: Caused by: java.lang.NullPointerException at org.apache.myfaces.application.jsp.ViewResponseWrapper.flushToWrappedResponse(ViewResponseWrapper.java:60) at org.apache.myfaces.taglib.core.ViewTag.doStartTag(ViewTag.java:94) at org.apache.jsp.components.index_jspx._jspx_meth_f_view_0(org.apache.jsp.components.index_jspx:138) at org.apache.jsp.components.index_jspx._jspService(org.apache.jsp.components.index_jspx:115) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373) (using Jetty 6.1-SNAP and 6.1.1 and 6.1.0) -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Resolved: (MYFACES-1441) Implement method: ApplicationImpl.getResourceBundle(FacesContext ,String)
[ https://issues.apache.org/jira/browse/MYFACES-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathias Broekelmann resolved MYFACES-1441. -- Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT implemented in r511030 Implement method: ApplicationImpl.getResourceBundle(FacesContext ,String) - Key: MYFACES-1441 URL: https://issues.apache.org/jira/browse/MYFACES-1441 Project: MyFaces Core Issue Type: Sub-task Components: JSR-252 Reporter: Bruno Aranda Assigned To: Mathias Broekelmann Fix For: 1.2.0-SNAPSHOT Implement method: ApplicationImpl.getResourceBundle(FacesContext ,String) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MYFACES-1223) JSR-252 Issue #54: Added new extension elements to the Faces XML schema.
[ https://issues.apache.org/jira/browse/MYFACES-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Kienenberger reopened MYFACES-1223: Assignee: (was: Mathias Broekelmann) I don't think marking this as resolved is the right resolution. I'd suggest we leave it open at minimal priority. JSR-252 Issue #54: Added new extension elements to the Faces XML schema. Key: MYFACES-1223 URL: https://issues.apache.org/jira/browse/MYFACES-1223 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Fix For: 1.2.0-SNAPSHOT Added new extension elements to the Faces XML schema. Please see Section 1.1 XML Schema Definition. Also see https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=54 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1223) JSR-252 Issue #54: Added new extension elements to the Faces XML schema.
[ https://issues.apache.org/jira/browse/MYFACES-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathias Broekelmann resolved MYFACES-1223. -- Resolution: Later Fix Version/s: 1.2.0-SNAPSHOT as long as we don't need these extensions there is no need to implement them. JSR-252 Issue #54: Added new extension elements to the Faces XML schema. Key: MYFACES-1223 URL: https://issues.apache.org/jira/browse/MYFACES-1223 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assigned To: Mathias Broekelmann Fix For: 1.2.0-SNAPSHOT Added new extension elements to the Faces XML schema. Please see Section 1.1 XML Schema Definition. Also see https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=54 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Reopened: (MYFACES-1223) JSR-252 Issue #54: Added new extension elements to the Faces XML schema.
Mathias, I'm reading your commit messages, and maybe I'm misunderstanding your reasons for resolving this. Did you mean that you implemented it as far as was required, or that there was more work to be done to support it? It sounded like you thought more work was required later on. -Mike On 2/23/07, Mike Kienenberger (JIRA) dev@myfaces.apache.org wrote: [ https://issues.apache.org/jira/browse/MYFACES-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Kienenberger reopened MYFACES-1223: Assignee: (was: Mathias Broekelmann) I don't think marking this as resolved is the right resolution. I'd suggest we leave it open at minimal priority. JSR-252 Issue #54: Added new extension elements to the Faces XML schema. Key: MYFACES-1223 URL: https://issues.apache.org/jira/browse/MYFACES-1223 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Fix For: 1.2.0-SNAPSHOT Added new extension elements to the Faces XML schema. Please see Section 1.1 XML Schema Definition. Also see https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=54 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Suggested Version number roadmap (was Re: Tomahawk 1.1.5 release plans?)
I think a version number which is more similar to JSF standard versions will be much easier for beginners. and less confusing On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: This is to summarize the version number discussion. MyFaces for JSF 1.1 1.1.5 - Current Release (Announced 19-Feb-2007) 1.1.6 - Next release not currently scheduled MyFaces for JSF 1.2 2.0.0 - Currently being developed as MyFaces 1.2 MyFaces for JSF 2.0 / JSF 6 3.0.0 - ? Tomahawk for JSF 1.1 1.1.3 - Current Release (Announced 14-Jun-2006) 1.1.5 - Next release, currently in process 1.6.0 - Following release Tomahawk for JSF 1.2 2.x - Not started Paul Spencer -- Arash Rajaeeyan
Fwd: [jira] Reopened: (MYFACES-1223) JSR-252 Issue #54: Added new extension elements to the Faces XML schema.
Yes that is true - I also marked that issue to be resolved later. If I understand it right the extension elements are supposed to be used by jsf implementations. The structure of these elements is not defined. So it is rather hard to implement something without knowing what to implement. When I started to work on this issue I misinterpret this issue as I though it is related to the new xml config elements el-resolver and resource-bundle. That is the reason why I started to implement them through this issue. BTW I didn't found the right issue for el-resolver and resource-bundle. Sorry for the confusion. 2007/2/23, Mike Kienenberger [EMAIL PROTECTED]: Mathias, I'm reading your commit messages, and maybe I'm misunderstanding your reasons for resolving this. Did you mean that you implemented it as far as was required, or that there was more work to be done to support it? It sounded like you thought more work was required later on. -Mike On 2/23/07, Mike Kienenberger (JIRA) dev@myfaces.apache.org wrote: [ https://issues.apache.org/jira/browse/MYFACES-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Kienenberger reopened MYFACES-1223: Assignee: (was: Mathias Broekelmann) I don't think marking this as resolved is the right resolution. I'd suggest we leave it open at minimal priority. JSR-252 Issue #54: Added new extension elements to the Faces XML schema. Key: MYFACES-1223 URL: https://issues.apache.org/jira/browse/MYFACES-1223 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Fix For: 1.2.0-SNAPSHOT Added new extension elements to the Faces XML schema. Please see Section 1.1 XML Schema Definition. Also see https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=54 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Mathias -- Mathias
[jira] Commented: (MYFACES-1246) JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instanti
[ https://issues.apache.org/jira/browse/MYFACES-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475580 ] Dennis Byrne commented on MYFACES-1246: --- Thanks Bernd, Hi Paul, Paul, I plan on diving into this for the weekend. Thanks for the information but I'm not sure what you're saying. Are you saying I should not bother implementing this for the sake of passing J2EE TCK? Ultimately I think we can all agree MyFaces should have this functionality w/ or w/out a full container. Please give me any info you can ASAP in order to avoid unnecessary work. JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Key: MYFACES-1246 URL: https://issues.apache.org/jira/browse/MYFACES-1246 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assigned To: Dennis Byrne Specified that implementations running in a JSR-250 compliant container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Specified that methods annotated with @PreDestroy be called when the scope for the bean is ending. See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=252 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Bug in t:JSCook with using JSPX instead of JSP files
Hi I've found an interesting bug when using the JSCook menus. If I create a .jsp file I can use JSCook, for example, this works: %@ taglib uri=http://java.sun.com/jsf/core; prefix=f% %@ taglib uri=http://java.sun.com/jsf/html; prefix=h% %@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t% html bodyf:view h:form t:jscookMenu layout=hbr theme=ThemeOffice t:navigationMenuItem id=nav_1 itemLabel=Hello t:navigationMenuItem id=nav_1_1 itemLabel=Sub-Menu 1/ t:navigationMenuItem itemLabel=Part 2/t:navigationMenuItem /t:navigationMenuItem /t:jscookMenu /h:form /f:view/body /html However, if I create as a JSPX file I get errors during rendering: ?xml version='1.0' encoding='windows-1252'? jsp:root xmlns=http://www.w3.org/1999/xhtml; xmlns:jsp=http://java.sun.com/JSP/Page; version=2.0 xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:t=http://myfaces.apache.org/tomahawk; html xmlns=http://www.w3.org/1999/xhtml; dir=ltr xml:lang=en head title/title /head body f:view h:form t:jscookMenu layout=hbr theme=ThemeOffice t:navigationMenuItem id=nav_1 itemLabel=Hello t:navigationMenuItem id=nav_1_1 itemLabel=Sub-Menu 1/ /t:navigationMenuItem t:navigationMenuItem itemLabel=Part 2/t:navigationMenuItem /t:jscookMenu /h:form /f:view /body /html /jsp:root Specifically, I get Error: myThemeOfficeBase is not defined Source File: http://192.168.0.101:8988/MizarTagLibraries-Examples-context-root/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11722898/navmenu.jscookmenu.HtmlJSCookMenuRenderer/ThemeOffice/theme.js Line: 4 Error: mismatched tag. Expected: /td. Source File: Line: 1, Column: 1448 Source Code: html xmlns=http://www.w3.org/1999/xhtml;body xmlns=http://www.w3.org/1999/xhtml;form xmlns=http://www.w3.org/1999/xhtml;div xmlns=http://www.w3.org/1999/xhtml;table summary=main menu class=ThemeOfficeMenu cellspacing=0trtd class=ThemeOfficeMainItem onmouseover=cmItemMouseOver (this,'ThemeOffice',1,'cmSubMenuID1','hbr',0) onmouseout=cmItemMouseOut (this,500) onmousedown=cmItemMouseDown (this,0) onmouseup=cmItemMouseUp (this,0)span class=ThemeOfficeMainFolderLeft/spanspan class=ThemeOfficeMainFolderTextHello/spanspan class=ThemeOfficeMainFolderRight/span/tdtd class=ThemeOfficeMainItem onmouseover=cmItemMouseOver (this,'ThemeOffice',1,null,'hbr',2) onmouseout=cmItemMouseOut (this,500) onmousedown=cmItemMouseDown (this,2) onmouseup=cmItemMouseUp (this,2)span class=ThemeOfficeMainItemLeft/spanspan class=ThemeOfficeMainItemTextPart 2/spanspan class=ThemeOfficeMainItemRight/span/td/tr/tablediv class=ThemeOfficeSubMenu id=cmSubMenuID1table summary=sub menu cellspacing=0 class=ThemeOfficeSubMenuTabletr class=ThemeOfficeMenuItem onmouseover=cmItemMouseOver (this,'ThemeOffice',0,null,'vbr',1) onmouseout=cmItemMouseOut (this,500) onmousedown=cmItemMouseDown (this,1) onmouseup=cmItemMouseUp (this,1)td class=ThemeOfficeMenuItemLefttd class=ThemeOfficeMenuItemTextSub-Menu 1td class=ThemeOfficeMenuItemRight/td/tr/table/div Error: uncaught exception: [Exception... An invalid or illegal string was specified code: 12 nsresult: 0x8053000c (NS_ERROR_DOM_SYNTAX_ERR) location: http://192.168.0.101:8988/MizarTagLibraries-Examples-context-root/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11722898/navmenu.jscookmenu.HtmlJSCookMenuRenderer/JSCookMenu.js Line: 321] This is in FireFox 2.0, IE 7 just displays the HTML without rendering. This is very peculiar, does anyone have any ideas? I'm using Tomahawk-1.1.3. Mark
[jira] Commented: (MYFACES-1246) JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instanti
[ https://issues.apache.org/jira/browse/MYFACES-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475588 ] Paul McMahan commented on MYFACES-1246: --- Dennis, sorry I can see how my comment could be easily misunderstood. Yes I agree that MyFaces shoiuld support the @PostConstruct and @PreDestroy annotations with or without a full JEE container. My comments were mainly in reaction to Mathias' observation that MyFaces should also provide support for resource injection when running in a JEE container. If you agree with Mathias and want to tackle JEE resource injection as part of this JIRA then I wanted to let you know about Geronimo's current level of support for annotations, which discovers annotations and handles resource injection in servlets, filters, and listeners but not in managed beans. To add support for resource injection in managed beans we could take the approach that Mathias recommends where the JEE container implements an InjectionProvider interface. Geronimo is currently using MyFaces for JSF 1.2 support so as a Geronimo committer I can work with you on defining and testing this interface. Hope this makes better sense now. JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Key: MYFACES-1246 URL: https://issues.apache.org/jira/browse/MYFACES-1246 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assigned To: Dennis Byrne Specified that implementations running in a JSR-250 compliant container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Specified that methods annotated with @PreDestroy be called when the scope for the bean is ending. See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=252 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1246) JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instanti
[ https://issues.apache.org/jira/browse/MYFACES-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475593 ] Dennis Byrne commented on MYFACES-1246: --- Well, I appreciate the help but I'd like to nail this one for all environments. I've got a few unit tests running for @PC and I don't think it should be too much. Once again, thanks. And feel free to help this way. You can never have enough info. JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Key: MYFACES-1246 URL: https://issues.apache.org/jira/browse/MYFACES-1246 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assigned To: Dennis Byrne Specified that implementations running in a JSR-250 compliant container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Specified that methods annotated with @PreDestroy be called when the scope for the bean is ending. See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=252 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
