[jira] Created: (MYFACES-2614) EnumConverter uses toString() instead of name()
EnumConverter uses toString() instead of name() --- Key: MYFACES-2614 URL: https://issues.apache.org/jira/browse/MYFACES-2614 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.8 Reporter: gui Hi, I have an enum that has overridden the toString method. It seems the EnumConverter uses toString to convert an enum to a string (and Enum.valueOf(..) to find it back). However, since my toString is overriden, the value it returns is not valid input for the Enum.valueOf(..) function and the converter raises an exception. A better approach is to use .name() as string representation of an Enum. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTCDI-4) transactional annotation
[ https://issues.apache.org/jira/browse/EXTCDI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12846950#action_12846950 ] Matthias Weßendorf commented on EXTCDI-4: - According to Arne this was working (or still is) with Weld, but I only tried OWB... transactional annotation Key: EXTCDI-4 URL: https://issues.apache.org/jira/browse/EXTCDI-4 Project: MyFaces CODI Issue Type: New Feature Reporter: Gerhard Petracek Attachments: EntityManagerProducer.java, PersistenceContext.java, Transactional.java, TransactionHandler.java @Transactional should act like the equivalent spring annotation and it should be compatible with every custom cdi-scope. @TransactionAttribute should be supported as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1758) warnings with the new skin
[ https://issues.apache.org/jira/browse/TRINIDAD-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Catalin Kormos updated TRINIDAD-1758: - Resolution: Fixed Status: Resolved (was: Patch Available) Patch applied, thanks Cosmin. warnings with the new skin -- Key: TRINIDAD-1758 URL: https://issues.apache.org/jira/browse/TRINIDAD-1758 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.14-core , 2.0.0-alpha-2 Reporter: Matthias Weßendorf Assignee: Catalin Kormos Fix For: 1.2.14-core , 2.0.0.3-core Attachments: MessageStyle-Warnings_Fix.patch, MessageStyle-Warnings_Trinidad2_0Fix.patch Running the trinidad-demo with the new skin gives a ton of these warning msgs: Mar 15, 2010 5:19:55 PM org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _checkDuplicateAttribute WARNING: Attribute style output twice; writing attribute as duplicate_style instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTCDI-4) transactional annotation
[ https://issues.apache.org/jira/browse/EXTCDI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12846949#action_12846949 ] Matthias Weßendorf commented on EXTCDI-4: - On deployment of these classes I get the following error (2times): SEVERE: org.apache.webbeans.exception.WebBeansConfigurationException: Bean Name:null,WebBeans Type:MANAGED,API Types:[java.lang.Object,org.apache.myfaces.codi.EntityManagerProducer],Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]scope can not define other scope except @Dependent to inject InjectionPoint at org.apache.webbeans.container.BeanManagerImpl.validate(BeanManagerImpl.java:1001) at org.apache.webbeans.config.BeansDeployer.validate(BeansDeployer.java:346) at org.apache.webbeans.config.BeansDeployer.validateInjectionPoints(BeansDeployer.java:301) at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:154) at org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:120) at org.apache.webbeans.web.lifecycle.WebContainerLifecycle.startApplication(WebContainerLifecycle.java:75) at org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:66) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) yes, the message is not easy to read, but it is basically complaining, that the EntityManagerProducer is not having @Dependent scope (since it has @ApplicationScoped). transactional annotation Key: EXTCDI-4 URL: https://issues.apache.org/jira/browse/EXTCDI-4 Project: MyFaces CODI Issue Type: New Feature Reporter: Gerhard Petracek Attachments: EntityManagerProducer.java, PersistenceContext.java, Transactional.java, TransactionHandler.java @Transactional should act like the equivalent spring annotation and it should be compatible with every custom cdi-scope. @TransactionAttribute should be supported as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTCDI-4) transactional annotation
[ https://issues.apache.org/jira/browse/EXTCDI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847040#action_12847040 ] Gurkan Erdogdu commented on EXTCDI-4: - Problem is that EntityManagerProducer defines disposal method that has an InjectionPoint parameter. According to the spec, If a bean that declares any scope other than @Dependent has an injection point of type InjectionPoint and qualifier @Default, the container automatically detects the problem and treats it as a definition error. In our implementation, we treat disposal methods InjectionPoint#getBean as a Managed Bean i.ie EntityManagerProducer and it has not scoped as @Dependent. Therefore it throws Exception. transactional annotation Key: EXTCDI-4 URL: https://issues.apache.org/jira/browse/EXTCDI-4 Project: MyFaces CODI Issue Type: New Feature Reporter: Gerhard Petracek Attachments: EntityManagerProducer.java, PersistenceContext.java, Transactional.java, TransactionHandler.java @Transactional should act like the equivalent spring annotation and it should be compatible with every custom cdi-scope. @TransactionAttribute should be supported as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTCDI-4) transactional annotation
[ https://issues.apache.org/jira/browse/EXTCDI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847057#action_12847057 ] Matthias Weßendorf commented on EXTCDI-4: - I changed that too, on my setup. But once I remove the AppScope from the producer I see other issues (like close() is called or the injection points aren't passivation aware). I hope to get to it soon.. transactional annotation Key: EXTCDI-4 URL: https://issues.apache.org/jira/browse/EXTCDI-4 Project: MyFaces CODI Issue Type: New Feature Reporter: Gerhard Petracek Attachments: EntityManagerProducer.java, PersistenceContext.java, Transactional.java, TransactionHandler.java @Transactional should act like the equivalent spring annotation and it should be compatible with every custom cdi-scope. @TransactionAttribute should be supported as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Fwd: Google just announced the official list of Organizations participating in GSoC 2010
FYI ;-) -- Forwarded message -- From: Luciano Resende luckbr1...@gmail.com Date: Thu, Mar 18, 2010 at 12:16 PM Subject: Google just announced the official list of Organizations participating in GSoC 2010 To: d...@community.apache.org, code-awards code-awa...@apache.org Google just announced the list of organizations accepted to GSoC 2010 [1] and Apache is among the accepted organizations. [1] http://socghop.appspot.com/gsoc/program/accepted_orgs/google/gsoc2010 -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (PORTLETBRIDGE-128) BridgeUtil needs to account for not running in a Faces context
BridgeUtil needs to account for not running in a Faces context -- Key: PORTLETBRIDGE-128 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-128 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-alpha, 1.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman The static utility methods in BridgeUtil (like isPortletRequest()) rely on getting at the request attributes via the ExternalContext (reqquestMap). You get a nullPointerException if this is called prior to a FacesContext being established. This can occur when the bridge's Application impl is being activated by the Faces configurator at startup. Code should instead check for a null FacesContext and merely return a value indicating we aren't in a portlet request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Deleted: (PORTLETBRIDGE-128) BridgeUtil needs to account for not running in a Faces context
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman deleted PORTLETBRIDGE-128: --- BridgeUtil needs to account for not running in a Faces context -- Key: PORTLETBRIDGE-128 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-128 Project: MyFaces Portlet Bridge Issue Type: Bug Reporter: Michael Freedman Assignee: Michael Freedman The static utility methods in BridgeUtil (like isPortletRequest()) rely on getting at the request attributes via the ExternalContext (reqquestMap). You get a nullPointerException if this is called prior to a FacesContext being established. This can occur when the bridge's Application impl is being activated by the Faces configurator at startup. Code should instead check for a null FacesContext and merely return a value indicating we aren't in a portlet request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-129) FacesContext.release() throws ConcurrentModificationException
FacesContext.release() throws ConcurrentModificationException - Key: PORTLETBRIDGE-129 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-129 Project: MyFaces Portlet Bridge Issue Type: Bug Reporter: Michael Freedman Assignee: Michael Freedman Code was recently changed to release all request attributes added during Faces processing when the FacesContext is released. The code used causes a ConcurrentModificationException when run in certain systems (WebSphere). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-130) ExternalContext.getResponseCharacterEncoding and getResponseContentType fail
ExternalContext.getResponseCharacterEncoding and getResponseContentType fail - Key: PORTLETBRIDGE-130 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-130 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Both of the above methods have the same incorrect check: if (getPortletPhase() != null mPortletRequest instanceof MimeResponse) where the test shoudl be the opposite -- !mPortletRequest instanceof MimeResponse) this causes an exception to be thrown in the normal case (render) while not in the abnormal case (action) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-131) If redirect occurs within JSF rendering -- don't write/flush output
If redirect occurs within JSF rendering -- don't write/flush output --- Key: PORTLETBRIDGE-131 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-131 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-alpha, 1.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman Current code checks to see if a redirect occurred from within the JSP during rendering and does the right thing -- but not after executing the JSF tree (that resulted from the dispatch). Need to check again and if the JSF code (via EL) triggered a redirect also terminate without writing/flushing buffers. This will allow the portlet 2.0 followon forward to work because the response won't have been committed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-132) Websphere claims there are no private parameters in an action but we expect them
Websphere claims there are no private parameters in an action but we expect them Key: PORTLETBRIDGE-132 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-132 Project: MyFaces Portlet Bridge Issue Type: Bug Affects Versions: 2.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman The bridge restricts the view of parameters via the ExternalContext to the privateParameters. On websphere this is coming back null during an action causing the bridge to break. To work around this change the map code to get the full parameter set and remove the public parameters and return the difference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-133) VIEWSTATE param getting encoded in the portlet:currentView URL when it shouldn't
VIEWSTATE param getting encoded in the portlet:currentView URL when it shouldn't Key: PORTLETBRIDGE-133 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-133 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Portlet 1.0 bridge correctly handles this by carrying forward all params in the original request (not wrapped/replaced by the bridge). In Portlet 2.0 there isn't an original request (as managed by the ExternalContext) -- so when the bridge wraps this request to expose the VIEW_STATE param (and action_params) they bleed into the URL when they shouldn't. We need a way to exclude them. Maybe like portlet 1.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-134) Portlet 2.0 Bridge doesn't render correctly if event follows a render (without any previous actions)
Portlet 2.0 Bridge doesn't render correctly if event follows a render (without any previous actions) Key: PORTLETBRIDGE-134 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-134 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Currently, the bridge doesn't establish a scope until the first action/event as the scopeId is managed in a renderParam and one can't create such during a render. Problem is that render is the operation that save's the view and creates the VIEW_STATE param that the bridge caches in the request scope to reuse when called in a redisplay. So if the first render is followed by doing an operation in another portlet that causes an event to get sent to this portlet, the event will establish a scope -- but there will be no VIEW_STATE parameter -- As this isn't a client postback its not in the incoming request and as we did establish a scope in the first render its not there. When the render follows the event the render terminates prematurely (in some Mojarra imples (in 1.2_05 and later) because it checks to see if we are in a psotback (depends on this param) and when not sets responseComplete. Fix is to establish the scope in the first render and temporarily cache it in the session ala what is already done for resources. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSOC] About Proposal of HTML5 Renderkit
Hi, Thanks for your answer Matthias, you are the coolest possible mentor :) I have some *new* questions about the proposal procedure :) - As a methodology, I want to write Software prototypinghttp://en.wikipedia.org/wiki/Software_prototyping[1]. First step of this is producing the prototypes, which is not actually coding, right? So, is it OK to write prototyping in project schedule between April 30 (1 week after acceptance announcement) and May 24 (Coding start)? Possible periods for prototyping: - Prototyping before April 23 (acceptance announcement): All the GSOC work should be done within the GSOC period, so this is not an option. - Prototyping after May 24(coding starts) Is it too late? - Some time in Community Bonding Periodhttp://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline[2](April 23 - May 24) (between acceptance announcement and coding start) is a cool period for prototyping. Possible? - I don't need to write all components one by one in my proposal, right? This was my purpose when I started prototyping, but I see the effort of determining components is also part of the GSOC work. So, I won't write the possible components into my proposal. Any objection? - What do you think about this template schedule? - Determining which components to implement; *prototyping*(?); reading docs; get to know community better*(till Coding Starts) * - Configuring the project and the builder, creating initial stuff (2-3 days) - Implementing a base library (4 days) - Implementing most of target components : Milestone (till mid-term evaluation : 6 weeks) - Implementing remainder components (2.5 weeks) - Detailed testing bugfix (1 week) - Writing unit tests(3 days) - Fixing bugs(3 days) - improve docs(2 days) - Prepare tutorial and presentations(1,5 days) [1] http://en.wikipedia.org/wiki/Software_prototyping [2] http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline Thanks in advance, Ali On Thu, Mar 18, 2010 at 1:35 AM, Matthias Wessendorf mat...@apache.orgwrote: On Wed, Mar 17, 2010 at 4:00 PM, Ali Ok al...@aliok.com.tr wrote: Hi, As you know, I will apply GSOC for Myfaces HTML5 renderkit project. Tomorrow, I think it will be announced that ASF is accepted as a GSOC organization (I have no doubt:) ). actually, same here! So, I should speed up preparing my proposal and want to ask some questions. Thanks in advance and I really appreciate your help. I see that some ideas are written at https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12314021 Should I add HTML5 renderkit project there? Are these only project ideas offered by possible mentors? If so, my mentor (or I) might want to write HTML5 renderkit there. Questions below are related to each other, so you may want to answer them step-by-step in time. Citation from this wiki: ASF expects a list of deliverables, quantifiable results for the Apache community, a detailed description / design document, an approach, an approximate schedule. 1. What should I write about deliverables? Should I write complete list of JSF components? Other than that? I don't think a list of components is correct. I'd more say that you deliver a set of components that integrate HTML5 (and standard browser APIs) with servers-side rendering technology JavaServer Faces(tm). Maybe you also say that you create a kinda (base) framework, so that if you don't catch all HTML5 stuff, it is easy to continue from your work (to leverage your started work). Just a thought. 2. Approach? What will be my approach? Considering this mail (thanks to Leonardo and Jakob), are these good?: A new component set with target HTML5 and JSF 2. Write all possible components, even if duplicates some existing components.(ie hx:inputText, but not hx:form since form HTML element is not changed with HTML5) Use myfaces builder plugin Any other stuff? I'd not say duplicated; Try to sell it. For instance input type:text... has some build-in validation rules, in HTML5 right? (at least as far as I remember and older WHAT doc). So say it like leveraging the new posibility to provide them as JSF components. You could enhance the maven-plugin, if needed. Not sure if that has an impact on needs to be created during summer of code. 3. Schedule? Ok, this is related to deliverables and will be answered after question #1. But, there will be midterm evaluations in mid-July. So, IMHO, a milestone would be fine at that time. But what can be the goals and the content of milestone? -design pages, prototypes, strategies etc ? 4. Where should I put my proposal? Is http://cwiki.apache.org/confluence/display/COMDEVxSITE/GSoC good? You can answer this after announcement of
Re: [GSOC] About Proposal of HTML5 Renderkit
On Thu, Mar 18, 2010 at 4:31 PM, Ali Ok al...@aliok.com.tr wrote: Hi, Thanks for your answer Matthias, you are the coolest possible mentor :) I have some new questions about the proposal procedure :) As a methodology, I want to write Software prototyping [1]. First step of this is producing the prototypes, which is not actually coding, right? So, well, I think it is part of getting the job done.. is it OK to write prototyping in project schedule between April 30 (1 week after acceptance announcement) and May 24 (Coding start)? Possible periods for prototyping: Prototyping before April 23 (acceptance announcement): All the GSOC work should be done within the GSOC period, so this is not an option. correct, that's not good. Prototyping after May 24(coding starts) Is it too late? Some time in Community Bonding Period [2](April 23 - May 24) (between acceptance announcement and coding start) is a cool period for prototyping. Possible? the page says: snip Students get to know mentors, read documentation, get up to speed to begin working on their projects. /snip = get up to speed is kinda prototyping, once the mentor got in closer contact with the student, and the student started to read/understand the documentation. So IMO get up to speed to begin working on their projects sounds like this is the time to do prototyping. I don't need to write all components one by one in my proposal, right? This was my purpose when I started prototyping, but I see the effort of determining components is also part of the GSOC work. So, I won't write the possible components into my proposal. Any objection? IMO that's fine. As said before just say that you write an HTML 5 library for JSF. Your work will (I think/hope) generate some framework (guide), so if you can't finish all components, it will be simple afterwards to continue there. What do you think about this template schedule? it looks OK. One question = Writing unit tests(3 days) So are you planing to write the tests after you are done ? :) I'd not be too surprised if they kinda like test-driven-development. I do :-) Greetings, Matthias Determining which components to implement; prototyping(?); reading docs; get to know community better(till Coding Starts) Configuring the project and the builder, creating initial stuff (2-3 days) Implementing a base library (4 days) Implementing most of target components : Milestone (till mid-term evaluation : 6 weeks) Implementing remainder components (2.5 weeks) Detailed testing bugfix (1 week) Writing unit tests(3 days) Fixing bugs(3 days) improve docs(2 days) Prepare tutorial and presentations(1,5 days) [1] http://en.wikipedia.org/wiki/Software_prototyping [2] http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline Thanks in advance, Ali On Thu, Mar 18, 2010 at 1:35 AM, Matthias Wessendorf mat...@apache.org wrote: On Wed, Mar 17, 2010 at 4:00 PM, Ali Ok al...@aliok.com.tr wrote: Hi, As you know, I will apply GSOC for Myfaces HTML5 renderkit project. Tomorrow, I think it will be announced that ASF is accepted as a GSOC organization (I have no doubt:) ). actually, same here! So, I should speed up preparing my proposal and want to ask some questions. Thanks in advance and I really appreciate your help. I see that some ideas are written at https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12314021 Should I add HTML5 renderkit project there? Are these only project ideas offered by possible mentors? If so, my mentor (or I) might want to write HTML5 renderkit there. Questions below are related to each other, so you may want to answer them step-by-step in time. Citation from this wiki: ASF expects a list of deliverables, quantifiable results for the Apache community, a detailed description / design document, an approach, an approximate schedule. 1. What should I write about deliverables? Should I write complete list of JSF components? Other than that? I don't think a list of components is correct. I'd more say that you deliver a set of components that integrate HTML5 (and standard browser APIs) with servers-side rendering technology JavaServer Faces(tm). Maybe you also say that you create a kinda (base) framework, so that if you don't catch all HTML5 stuff, it is easy to continue from your work (to leverage your started work). Just a thought. 2. Approach? What will be my approach? Considering this mail (thanks to Leonardo and Jakob), are these good?: A new component set with target HTML5 and JSF 2. Write all possible components, even if duplicates some existing components.(ie hx:inputText, but not hx:form since form HTML element is not changed with HTML5) Use myfaces builder plugin Any other stuff? I'd not say duplicated; Try to sell it. For instance input type:text... has some build-in validation rules, in HTML5
