Re: [GSOC] HTML5 Renderkit Start-up
Hi Ali, I also think that you definitely should implement a new component set especially for HTML5 (of course by extending the existing one), because there are just so many new possibilities which don't really fit in with the existing component set. However it would be really great if you'd keep things straight, meaning that the HTML5 component for an input text is also called inputText just with some new attributes. Furthermore input with type email from HTML5 should be something like inputEmail. Regards, Jakob 2010/3/2 Ali Ok al...@aliok.com.tr Hi Leonardo, First of all, I am not 100% sure about my answers. The purpose of my current work is, to make my GSOC application better by getting your idea. On this mail threadhttp://old.nabble.com/-GSoc--Google-Summer-of-Code-Idea-td27040478.html, we have talked about a new HTML5 renderkit. But I have a doubt which I saved for myself till now: - If I implement a HTML5 renderkit for existing components, how to add the new features? For example, the input element has a new attribute placeholder, where you can provide an image if the input is empty. Spec of the h:inputText or t:inputText is defined and we need the placeholder attribute defined on them. Ok, we can change the Tomahawk components but, isn't this a problem since the current renderkit won't use it and placeholder attribute will never be used by it? How to solve this problem? If we can clear the question above, my answers to your questions will be changed, but here is my answers at the moment: What are you planning: I am planning A new component set with target HTML5 and JSF 2.. However, for instance, I also want to implement hx:input extending h:input, for new features of HTML5 input element (list,placeholder etc.). Based on on the previous question, you will need utility code that your components will use it. So where will you take it: I think myfaces commons utils is the correct place as you said. If there is some component creation you will: I want to implement completely new components (like hx:video) and extensions of existing components (like hx:inputText); but not duplicate anything (if possible). but first we can handle this code outside and at the end integrate it in myfaces svn if the community agrees to. That is how it's supposed to be :) Thanks for your questions :) Ali On Tue, Mar 2, 2010 at 7:17 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I want to ask you some questions with the objective of have a better idea. I'm on vacations but I feel it is important to make this clear from now. So, what are you planning: 1. A HTML5 Renderkit of existing components 2. A new component set with target HTML5 and JSF 2. 3. Something different. Based on on the previous question, you will need utility code that your components will use it. So where will you take it: 1. A new api (there is myfaces commons utils project so it would be great to do a clean and stable jsf utility api that other libraries could use it). 2. Just take myfaces shared code as tomahawk or orchestra or portlet bridge. This means repackage and copy that stuff 3. Take from trinidad or tobago. 4. Something different. If there is some component creation you will: 1. Only write html 5 components and do not replicate the basic ones. 2. Write all possible components, even if duplicates some existing components. 3. Something different. And 1. Use myfaces builder plugin 2. Use trinidad maven faces plugin 3. Use tobago apt plugin I think in my personal opinion myfaces commons is the right place to put this effort, but first we can handle this code outside and at the end integrate it in myfaces svn if the community agrees to. regards, Leonardo Uribe 2010/3/1 Ali Ok al...@aliok.com.tr Hi, I've started working on HTML5 renderkit, which I will apply GSOC this year. I haven't done much, just created the project, configured the builder (modified Tomahawk's building procedure). Now I am trying to determine what to implement and how people will use it after we are done. So I am writing some example component codes to get your ideas. The project is hosted on Google Code: http://code.google.com/p/myfaces-html5-starter/ I will appreciate some review on pages at: http://code.google.com/p/myfaces-html5-starter/source/browse/#svn/trunk/src/test/resources/tag-interface Please note that, components are not implemented yet. Code on xhtml pages are just trials. If anybody is interested, please feel free to send me your feedback :) Thanks, Ali Sorry for duplicate post :( -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[jira] Commented: (MYFACES-2559) Google App Engine Support for Myfaces 2
[ https://issues.apache.org/jira/browse/MYFACES-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842227#action_12842227 ] Jakob Korherr commented on MYFACES-2559: Great work, guys :) Google App Engine Support for Myfaces 2 --- Key: MYFACES-2559 URL: https://issues.apache.org/jira/browse/MYFACES-2559 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.0-beta Environment: Google App Engine Reporter: Ali Ok Assignee: Matthias Weßendorf Priority: Minor Fix For: 2.0.0-beta-3 Attachments: 2559.patch Google App Engine Support for Myfaces 2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: fancy missing-id warnings
Hi Mark,
The warning applies if a component isn't created and plugged into the
component tree by the VDL but by some other component or listener or
whatever and it does not get a clientId.
What do you mean by your hand written fields?
Regards,
Jakob
2010/3/4 Mark Struberg strub...@yahoo.de
Hi!
I always get the following warning which is caused by dynamically generated
fields (from a component):
01.03.2010 14:20:46 javax.faces.component.UIComponentBase getClientId
WARNUNG: WARNING: Component j_id68 just got an automatic id, because there
was no id assigned yet. If this component was created dynamically (i.e. not
by a JSP tag) you should assign it an explicit static id or assign it the id
you get from the createUniqueId from the current UIViewRoot component right
after creation! Path to Component: {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId: /reservationRequest.xhtml][Class:
javax.faces.component.UIPanel,Id: head][Class:
org.primefaces.component.resource.Resource,Id: j_id68]}
The funny thing is that it doesn't warn me if I miss an id in one of my
hand written fields ;)
Is this really the way it should work?
LieGrue,
strub
__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
gegen Massenmails.
http://mail.yahoo.com
[jira] Commented: (MYFACES-2559) Google App Engine Support for Myfaces 2
[ https://issues.apache.org/jira/browse/MYFACES-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842230#action_12842230 ] Mathias Walter commented on MYFACES-2559: - Guessing the correct number results in a javax.crypto.BadPaddingException: Given final block not properly padded. I'm not sure if it's an application error or related to MyFACES. Anyway, a test application should work. Google App Engine Support for Myfaces 2 --- Key: MYFACES-2559 URL: https://issues.apache.org/jira/browse/MYFACES-2559 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.0-beta Environment: Google App Engine Reporter: Ali Ok Assignee: Matthias Weßendorf Priority: Minor Fix For: 2.0.0-beta-3 Attachments: 2559.patch Google App Engine Support for Myfaces 2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2559) Google App Engine Support for Myfaces 2
[ https://issues.apache.org/jira/browse/MYFACES-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842231#action_12842231 ] Jakob Korherr commented on MYFACES-2559: Got it too, it occurs when guessing the number right and hitting the back button: javax.faces.FacesException: javax.crypto.BadPaddingException: Given final block not properly padded at org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:157) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093) at com.google.apphosting.utils.servlet.ParseBlobUploadFilter.doFilter(ParseBlobUploadFilter.java:97) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at com.google.apphosting.runtime.jetty.SaveSessionFilter.doFilter(SaveSessionFilter.java:35) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:238) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:313) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830) at com.google.apphosting.runtime.jetty.RpcRequestParser.parseAvailable(RpcRequestParser.java:76) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:135) at com.google.apphosting.runtime.JavaRuntime.handleRequest(JavaRuntime.java:235) at com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:5485) at com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:5483) at com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest(BlockingApplicationHandler.java:24) at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:363) at com.google.net.rpc.impl.Server$2.run(Server.java:837) at com.google.tracing.LocalTraceSpanRunnable.run(LocalTraceSpanRunnable.java:56) at com.google.tracing.LocalTraceSpanBuilder.internalContinueSpan(LocalTraceSpanBuilder.java:536) at com.google.net.rpc.impl.Server.startRpc(Server.java:792) at com.google.net.rpc.impl.Server.processRequest(Server.java:367) at com.google.net.rpc.impl.ServerConnection.messageReceived(ServerConnection.java:448) at com.google.net.rpc.impl.RpcConnection.parseMessages(RpcConnection.java:319) at com.google.net.rpc.impl.RpcConnection.dataReceived(RpcConnection.java:290) at com.google.net.async.Connection.handleReadEvent(Connection.java:474) at com.google.net.async.EventDispatcher.processNetworkEvents(EventDispatcher.java:774) at com.google.net.async.EventDispatcher.internalLoop(EventDispatcher.java:205) at com.google.net.async.EventDispatcher.loop(EventDispatcher.java:101) at com.google.net.rpc.RpcService.runUntilServerShutdown(RpcService.java:251) at com.google.apphosting.runtime.JavaRuntime$RpcRunnable.run(JavaRuntime.java:394) at java.lang.Thread.run(Unknown Source) Caused by: javax.crypto.BadPaddingException: Given final block not properly padded at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..) at javax.crypto.Cipher.doFinal(DashoA13*..) at
Demo: MyFaces2 meets Apache OWB
Some (simple) demo of the two: http://matthiaswessendorf.wordpress.com/2010/03/06/demo-of-apache-myfaces-2-and-openwebbeans/ -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Issue Comment Edited: (MYFACES-2585) ajax doesn't work if target contains script with CDATA
[
https://issues.apache.org/jira/browse/MYFACES-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12841926#action_12841926
]
Werner Punz edited comment on MYFACES-2585 at 3/6/10 2:13 PM:
--
Ok Jim Driscoll cleared this up for me, he was implementing it for Mojarra as
CDATA escape pattern
I looked up the xml spec comments and it said that everything except ]] is
allowed in a cdata block
so we can either drop the entire CDATA section or replace it with ![CDATA[
any pending ]] must be replaced with something neutral section in case of an
open CDATA block
so a user cannot trigger the usecase per xml definition I mentioned. I think we
can live with the way mojarra does it,
and page authors have to be aware with its limitations.
In any case we have to fix the problem that users might issue nested CDATA
blocks since the spec clearly states in section:
13.4.4.1 Writing The Partial Response
Implementations must take care to properly handle nested CDATA sections when
writing the response.
Which we have not covered yet, I have already written a PPRResponseWriterImpl
which does some double buffering on issued CDATA blocks and supresses nested
CDATA, it also does a needed rewriting which catches the facelets //![CDATA[
and ]] //]] cases and removes them to get a proper cdata block here.
I hope this is enough post processing to cover this problem so that it does not
become a problem for the component authors. I will commit this on monday, I
need to do some testcases and additional testing first before committing this,
since I change a vital part of the JSF2 PPR processing here.
I also did not push this code into our PPRResponseWriter, but went straight for
an impl class to get some separation of concerns and, since the spec clearly
states impls have to take care of that I think I am fine with it.
I hope the TCK wont choke on what I am going to do here.
was (Author: werpu):
Ok Jim Driscoll cleard this up for me, he was implementing it for Mojarra
as CDATA escape pattern
I looked up the xml spec comments and it said that everything except ]] is
allowed in a cdata block
so we can either drop the entire CDATA section or replace it with ![CDATA[
any pending ]] must be replaced with something neutral section in case of an
open CDATA block
so a user cannot trigger the usecase per xml definition I mentioned. I think we
can live with the way mojarra does it,
and page authors have to be aware with its limitations.
I will commit a patch on monday.
ajax doesn't work if target contains script with CDATA
--
Key: MYFACES-2585
URL: https://issues.apache.org/jira/browse/MYFACES-2585
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: Javascript, API, IMPL...
Reporter: Ganesh Jung
Priority: Critical
This doesn't work:
h:inputText value=#{numberBean.myNumber}
f:ajax render=test /
/h:inputText
h:panelGroup id=test
script type=text/javascript
//![CDATA[
alert(running);
//]]
/script
h:inputText value=#{numberBean.myNumber} /
/h:panelGroup
But this works fine:
h:inputText value=#{numberBean.myNumber}
f:ajax render=test /
/h:inputText
h:panelGroup id=test
script type=text/javascript
alert(running);
/script
h:inputText value=#{numberBean.myNumber} /
/h:panelGroup
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[core] Introducing implee6 - MYFACES-2579
Hi guys, I managed to introduce the core submodule implee6 on my local machine. This new submodule includes Java EE 6 dependencies and thus you can use Servlet API 3.0 and other new things in it. When building MyFaces, this new submodule is built before the normal impl submodule. Then the .class and the .java files are injected into the impl-build. This is very similar to how shared_impl is included in the myfaces-impl build at the moment, but without recompilation. In this way we are able to use the new services approach of Java EE 6 to get rid of the Faces Servlet entries in web.xml, because in any Java EE 6 container we can configure this dynamically at startup (see MYFACES-2579 for details). This also works fantastically on my local machine - it's really cool! Also with this method we are still Java EE 5 complaint, because the EE 6 classes just won't get loaded in a non EE 6 environment, because there are no dependencies from impl or shared to them. They are only called (and loaded) by a Java EE 6 container via the services definition. Furthermore I noticed that the Mojarra guys also include a similar solution to this in their newest build! Now, before I commit something of this, I wanted to ask if there are any objections with this proposal. If so, please tell me your concerns! Regards, Jakob
[jira] Commented: (MYFACES-2585) ajax doesn't work if target contains script with CDATA
[
https://issues.apache.org/jira/browse/MYFACES-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842266#action_12842266
]
Ganesh Jung commented on MYFACES-2585:
--
Wow, sounds complicated!
Can you please detail what exactly your code is meant to do? Do you remove
CDATA or do you encode it? Is there any change on the JavaScript side?
Looking forward to your solution!
ajax doesn't work if target contains script with CDATA
--
Key: MYFACES-2585
URL: https://issues.apache.org/jira/browse/MYFACES-2585
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: Javascript, API, IMPL...
Reporter: Ganesh Jung
Priority: Critical
This doesn't work:
h:inputText value=#{numberBean.myNumber}
f:ajax render=test /
/h:inputText
h:panelGroup id=test
script type=text/javascript
//![CDATA[
alert(running);
//]]
/script
h:inputText value=#{numberBean.myNumber} /
/h:panelGroup
But this works fine:
h:inputText value=#{numberBean.myNumber}
f:ajax render=test /
/h:inputText
h:panelGroup id=test
script type=text/javascript
alert(running);
/script
h:inputText value=#{numberBean.myNumber} /
/h:panelGroup
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [core] Introducing implee6 - MYFACES-2579
Hey, If it works on Jetty and Tomcat, I'd say +1 on committing the module. I can't think of big issues with committing it as a separate module. And we can always revert if we have to. Cool, can't wait to check it out! On what appserver are you testing this stuff Jakob? Regards, Jan-Kees 2010/3/6 Jakob Korherr jakob.korh...@gmail.com Hi guys, I managed to introduce the core submodule implee6 on my local machine. This new submodule includes Java EE 6 dependencies and thus you can use Servlet API 3.0 and other new things in it. When building MyFaces, this new submodule is built before the normal impl submodule. Then the .class and the .java files are injected into the impl-build. This is very similar to how shared_impl is included in the myfaces-impl build at the moment, but without recompilation. In this way we are able to use the new services approach of Java EE 6 to get rid of the Faces Servlet entries in web.xml, because in any Java EE 6 container we can configure this dynamically at startup (see MYFACES-2579 for details). This also works fantastically on my local machine - it's really cool! Also with this method we are still Java EE 5 complaint, because the EE 6 classes just won't get loaded in a non EE 6 environment, because there are no dependencies from impl or shared to them. They are only called (and loaded) by a Java EE 6 container via the services definition. Furthermore I noticed that the Mojarra guys also include a similar solution to this in their newest build! Now, before I commit something of this, I wanted to ask if there are any objections with this proposal. If so, please tell me your concerns! Regards, Jakob
Re: [core] Introducing implee6 - MYFACES-2579
Hi Jan-Kees, Great :) I am currently testing on Tomcat, Jetty, GlassFish v3 and JBoss 6! Regards, Jakob 2010/3/6 Jan-Kees van Andel jankeesvanan...@gmail.com Hey, If it works on Jetty and Tomcat, I'd say +1 on committing the module. I can't think of big issues with committing it as a separate module. And we can always revert if we have to. Cool, can't wait to check it out! On what appserver are you testing this stuff Jakob? Regards, Jan-Kees 2010/3/6 Jakob Korherr jakob.korh...@gmail.com Hi guys, I managed to introduce the core submodule implee6 on my local machine. This new submodule includes Java EE 6 dependencies and thus you can use Servlet API 3.0 and other new things in it. When building MyFaces, this new submodule is built before the normal impl submodule. Then the .class and the .java files are injected into the impl-build. This is very similar to how shared_impl is included in the myfaces-impl build at the moment, but without recompilation. In this way we are able to use the new services approach of Java EE 6 to get rid of the Faces Servlet entries in web.xml, because in any Java EE 6 container we can configure this dynamically at startup (see MYFACES-2579 for details). This also works fantastically on my local machine - it's really cool! Also with this method we are still Java EE 5 complaint, because the EE 6 classes just won't get loaded in a non EE 6 environment, because there are no dependencies from impl or shared to them. They are only called (and loaded) by a Java EE 6 container via the services definition. Furthermore I noticed that the Mojarra guys also include a similar solution to this in their newest build! Now, before I commit something of this, I wanted to ask if there are any objections with this proposal. If so, please tell me your concerns! Regards, Jakob
Re: [core] Introducing implee6 - MYFACES-2579
Hello Jakob, I'm not really sure that this feature should be part of myfaces-core. Maybe myfaces-commons would be a better place. But we can change this later. +1 on commiting the module. Regards Bernd On Sat, Mar 6, 2010 at 4:32 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Jan-Kees, Great :) I am currently testing on Tomcat, Jetty, GlassFish v3 and JBoss 6! Regards, Jakob 2010/3/6 Jan-Kees van Andel jankeesvanan...@gmail.com Hey, If it works on Jetty and Tomcat, I'd say +1 on committing the module. I can't think of big issues with committing it as a separate module. And we can always revert if we have to. Cool, can't wait to check it out! On what appserver are you testing this stuff Jakob? Regards, Jan-Kees 2010/3/6 Jakob Korherr jakob.korh...@gmail.com Hi guys, I managed to introduce the core submodule implee6 on my local machine. This new submodule includes Java EE 6 dependencies and thus you can use Servlet API 3.0 and other new things in it. When building MyFaces, this new submodule is built before the normal impl submodule. Then the .class and the .java files are injected into the impl-build. This is very similar to how shared_impl is included in the myfaces-impl build at the moment, but without recompilation. In this way we are able to use the new services approach of Java EE 6 to get rid of the Faces Servlet entries in web.xml, because in any Java EE 6 container we can configure this dynamically at startup (see MYFACES-2579 for details). This also works fantastically on my local machine - it's really cool! Also with this method we are still Java EE 5 complaint, because the EE 6 classes just won't get loaded in a non EE 6 environment, because there are no dependencies from impl or shared to them. They are only called (and loaded) by a Java EE 6 container via the services definition. Furthermore I noticed that the Mojarra guys also include a similar solution to this in their newest build! Now, before I commit something of this, I wanted to ask if there are any objections with this proposal. If so, please tell me your concerns! Regards, Jakob
Re: [core] Introducing implee6 - MYFACES-2579
Hi Bernd, If this module wouldn't be a part of myfaces core, the users still would have to configure something to run their MyFaces-2 apps in a EE6 container (e.g. they'd have to include myfaces commons), which is not the target. The target is to get rid of any unnecessary configuration to make the development process easier! Regards, Jakob 2010/3/6 Bernd Bohmann bernd.bohm...@googlemail.com Hello Jakob, I'm not really sure that this feature should be part of myfaces-core. Maybe myfaces-commons would be a better place. But we can change this later. +1 on commiting the module. Regards Bernd On Sat, Mar 6, 2010 at 4:32 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Jan-Kees, Great :) I am currently testing on Tomcat, Jetty, GlassFish v3 and JBoss 6! Regards, Jakob 2010/3/6 Jan-Kees van Andel jankeesvanan...@gmail.com Hey, If it works on Jetty and Tomcat, I'd say +1 on committing the module. I can't think of big issues with committing it as a separate module. And we can always revert if we have to. Cool, can't wait to check it out! On what appserver are you testing this stuff Jakob? Regards, Jan-Kees 2010/3/6 Jakob Korherr jakob.korh...@gmail.com Hi guys, I managed to introduce the core submodule implee6 on my local machine. This new submodule includes Java EE 6 dependencies and thus you can use Servlet API 3.0 and other new things in it. When building MyFaces, this new submodule is built before the normal impl submodule. Then the .class and the .java files are injected into the impl-build. This is very similar to how shared_impl is included in the myfaces-impl build at the moment, but without recompilation. In this way we are able to use the new services approach of Java EE 6 to get rid of the Faces Servlet entries in web.xml, because in any Java EE 6 container we can configure this dynamically at startup (see MYFACES-2579 for details). This also works fantastically on my local machine - it's really cool! Also with this method we are still Java EE 5 complaint, because the EE 6 classes just won't get loaded in a non EE 6 environment, because there are no dependencies from impl or shared to them. They are only called (and loaded) by a Java EE 6 container via the services definition. Furthermore I noticed that the Mojarra guys also include a similar solution to this in their newest build! Now, before I commit something of this, I wanted to ask if there are any objections with this proposal. If so, please tell me your concerns! Regards, Jakob
Re: [core] Introducing implee6 - MYFACES-2579
Hello Jakob, do you really think adding an other dependency is a real problem? How do you configure prefix or suffix mapping? For each possible configuration option an own impl version? Regards Bernd On Sat, Mar 6, 2010 at 4:48 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Bernd, If this module wouldn't be a part of myfaces core, the users still would have to configure something to run their MyFaces-2 apps in a EE6 container (e.g. they'd have to include myfaces commons), which is not the target. The target is to get rid of any unnecessary configuration to make the development process easier! Regards, Jakob 2010/3/6 Bernd Bohmann bernd.bohm...@googlemail.com Hello Jakob, I'm not really sure that this feature should be part of myfaces-core. Maybe myfaces-commons would be a better place. But we can change this later. +1 on commiting the module. Regards Bernd On Sat, Mar 6, 2010 at 4:32 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Jan-Kees, Great :) I am currently testing on Tomcat, Jetty, GlassFish v3 and JBoss 6! Regards, Jakob 2010/3/6 Jan-Kees van Andel jankeesvanan...@gmail.com Hey, If it works on Jetty and Tomcat, I'd say +1 on committing the module. I can't think of big issues with committing it as a separate module. And we can always revert if we have to. Cool, can't wait to check it out! On what appserver are you testing this stuff Jakob? Regards, Jan-Kees 2010/3/6 Jakob Korherr jakob.korh...@gmail.com Hi guys, I managed to introduce the core submodule implee6 on my local machine. This new submodule includes Java EE 6 dependencies and thus you can use Servlet API 3.0 and other new things in it. When building MyFaces, this new submodule is built before the normal impl submodule. Then the .class and the .java files are injected into the impl-build. This is very similar to how shared_impl is included in the myfaces-impl build at the moment, but without recompilation. In this way we are able to use the new services approach of Java EE 6 to get rid of the Faces Servlet entries in web.xml, because in any Java EE 6 container we can configure this dynamically at startup (see MYFACES-2579 for details). This also works fantastically on my local machine - it's really cool! Also with this method we are still Java EE 5 complaint, because the EE 6 classes just won't get loaded in a non EE 6 environment, because there are no dependencies from impl or shared to them. They are only called (and loaded) by a Java EE 6 container via the services definition. Furthermore I noticed that the Mojarra guys also include a similar solution to this in their newest build! Now, before I commit something of this, I wanted to ask if there are any objections with this proposal. If so, please tell me your concerns! Regards, Jakob
[jira] Created: (EXTVAL-86) BeanAware constraint validators for Model Validation beanValidation
BeanAware constraint validators for Model Validation beanValidation --- Key: EXTVAL-86 URL: https://issues.apache.org/jira/browse/EXTVAL-86 Project: MyFaces Extensions Validator Issue Type: Improvement Components: Bean Validation Affects Versions: 1.2.3-SNAPSHOT Reporter: Rudy De Busscher Allow beans defined in a context to be used as BeanValidation Constrain Validators just like constraints on properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (EXTVAL-86) BeanAware constraint validators for Model Validation beanValidation
[ https://issues.apache.org/jira/browse/EXTVAL-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudy De Busscher updated EXTVAL-86: --- Status: Patch Available (was: Open) BeanAware constraint validators for Model Validation beanValidation --- Key: EXTVAL-86 URL: https://issues.apache.org/jira/browse/EXTVAL-86 Project: MyFaces Extensions Validator Issue Type: Improvement Components: Bean Validation Affects Versions: 1.2.3-SNAPSHOT Reporter: Rudy De Busscher Attachments: extval-86.patch Allow beans defined in a context to be used as BeanValidation Constrain Validators just like constraints on properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Extval] BeanAware constraint validators for Model Validation beanValidation
[ExtVal] BeanAware constraint validators for Model Validation beanValidation Hi, The Constraint Validator for BeanValidation constraints on properties can be defined in a context repository. The * BeanValidationModuleValidationInterceptorInternals.validate* method makes use of code that checks if a bean is defined in a context that can be used. The *ModelValidationPhaseListener* makes use of a slightly different aproach which leads to the fact that no beans could be used. A small change to the ModelValidationPhaseListener.validateTarget method solves this problem. I haven't tested the fix extensively but with my small test, I was able to use a bean for the constraint validator defined on a class. *ModelValidationPhaseListener.validateTarget* return ExtValBeanValidationContext.getCurrentInstance() .getValidatorFactory().usingContext() .messageInterpolator(ExtValBeanValidationContext.getCurrentInstance().getMessageInterpolator()) .getValidator() .validate(validationTarget, groups); should become ValidatorFactory validatorFactory = ExtValBeanValidationContext.getCurrentInstance().getValidatorFactory(); return validatorFactory .usingContext() .messageInterpolator(ExtValBeanValidationContext.getCurrentInstance().getMessageInterpolator()) .constraintValidatorFactory(validatorFactory.getConstraintValidatorFactory()) .traversableResolver(validatorFactory.getTraversableResolver()) .getValidator() .validate(validationTarget, groups); See EXTVAL-86 for the patch. Include it in the x.x.3 release ? regards Rudy.
[jira] Updated: (EXTVAL-86) BeanAware constraint validators for Model Validation beanValidation
[ https://issues.apache.org/jira/browse/EXTVAL-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated EXTVAL-86: --- Resolution: Fixed Fix Version/s: 1.1.3-SNAPSHOT 2.0.3-SNAPSHOT 1.2.3-SNAPSHOT Status: Resolved (was: Patch Available) BeanAware constraint validators for Model Validation beanValidation --- Key: EXTVAL-86 URL: https://issues.apache.org/jira/browse/EXTVAL-86 Project: MyFaces Extensions Validator Issue Type: Improvement Components: Bean Validation Affects Versions: 1.2.3-SNAPSHOT Reporter: Rudy De Busscher Fix For: 1.2.3-SNAPSHOT, 2.0.3-SNAPSHOT, 1.1.3-SNAPSHOT Attachments: extval-86.patch Allow beans defined in a context to be used as BeanValidation Constrain Validators just like constraints on properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Extval] BeanAware constraint validators for Model Validation beanValidation
thx - i synced both parts - so it will be in r3. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/6 Rudy De Busscher rdebussc...@gmail.com [ExtVal] BeanAware constraint validators for Model Validation beanValidation Hi, The Constraint Validator for BeanValidation constraints on properties can be defined in a context repository. The * BeanValidationModuleValidationInterceptorInternals.validate* method makes use of code that checks if a bean is defined in a context that can be used. The *ModelValidationPhaseListener* makes use of a slightly different aproach which leads to the fact that no beans could be used. A small change to the ModelValidationPhaseListener.validateTarget method solves this problem. I haven't tested the fix extensively but with my small test, I was able to use a bean for the constraint validator defined on a class. *ModelValidationPhaseListener.validateTarget* return ExtValBeanValidationContext.getCurrentInstance() .getValidatorFactory().usingContext() .messageInterpolator(ExtValBeanValidationContext.getCurrentInstance().getMessageInterpolator()) .getValidator() .validate(validationTarget, groups); should become ValidatorFactory validatorFactory = ExtValBeanValidationContext.getCurrentInstance().getValidatorFactory(); return validatorFactory .usingContext() .messageInterpolator(ExtValBeanValidationContext.getCurrentInstance().getMessageInterpolator()) .constraintValidatorFactory(validatorFactory.getConstraintValidatorFactory()) .traversableResolver(validatorFactory.getTraversableResolver()) .getValidator() .validate(validationTarget, groups); See EXTVAL-86 for the patch. Include it in the x.x.3 release ? regards Rudy.
[jira] Commented: (MYFACES-2559) Google App Engine Support for Myfaces 2
[ https://issues.apache.org/jira/browse/MYFACES-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842354#action_12842354 ] Ali Ok commented on MYFACES-2559: - About javax.crypto.BadPaddingException: Given final block not properly padded: I thought this was about session handling or something and ignored it since it seemed not about Myfaces or GAE. I thought this problem was occured because of this number-guess application. But I am not sure... I didn't get the error using the pattern you said. Finding the correct number didn't resulted in this error. I couldnt find a pattern. It seems random. I see a JIRA issue is fired for this error before. I will work on this problem. Google App Engine Support for Myfaces 2 --- Key: MYFACES-2559 URL: https://issues.apache.org/jira/browse/MYFACES-2559 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.0-beta Environment: Google App Engine Reporter: Ali Ok Assignee: Matthias Weßendorf Priority: Minor Fix For: 2.0.0-beta-3 Attachments: 2559-doc.patch, 2559.patch Google App Engine Support for Myfaces 2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1748) Add pushComponentToEL/popComponentFromEL for tree visiting/invokeOnComponent/processComponent
Add pushComponentToEL/popComponentFromEL for tree
visiting/invokeOnComponent/processComponent
-
Key: TRINIDAD-1748
URL: https://issues.apache.org/jira/browse/TRINIDAD-1748
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 2.0.0-alpha-2
Environment: All
Reporter: Blake Sullivan
Assignee: Blake Sullivan
In order for #{component} to resolve correctly,
pushComponentToEL/popComponentFromEL must be called before retrieving
attributes or invoking callbacks when performing any kind of traversal. While
TRINIDAD-1612 Add support for the new Lifecycle Management Methods (see
spec section 3.1.14) covers this for the normal component processXXX methods,
this JIRA addresses the other forms of component traversal for both the
Trinidad framework itself and its component implementations. In particular,
visitTree, invokeOnComponent and FlattenedComponent, processComponent need to
be addressed/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1748) Add pushComponentToEL/popComponentFromEL for tree visiting/invokeOnComponent/processComponent
[
https://issues.apache.org/jira/browse/TRINIDAD-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Sullivan resolved TRINIDAD-1748.
--
Resolution: Fixed
Fix Version/s: 2.0.0-alpha-2
Fixed in 919945
Add pushComponentToEL/popComponentFromEL for tree
visiting/invokeOnComponent/processComponent
-
Key: TRINIDAD-1748
URL: https://issues.apache.org/jira/browse/TRINIDAD-1748
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 2.0.0-alpha-2
Environment: All
Reporter: Blake Sullivan
Assignee: Blake Sullivan
Fix For: 2.0.0-alpha-2
Attachments: JIRA_1748_Trin2.patch
Original Estimate: 2h
Remaining Estimate: 2h
In order for #{component} to resolve correctly,
pushComponentToEL/popComponentFromEL must be called before retrieving
attributes or invoking callbacks when performing any kind of traversal.
While TRINIDAD-1612 Add support for the new Lifecycle Management Methods
(see spec section 3.1.14) covers this for the normal component processXXX
methods, this JIRA addresses the other forms of component traversal for both
the Trinidad framework itself and its component implementations. In
particular, visitTree, invokeOnComponent and FlattenedComponent,
processComponent need to be addressed/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2589) Partial response writer, delete resolution
Partial response writer, delete resolution -- Key: MYFACES-2589 URL: https://issues.apache.org/jira/browse/MYFACES-2589 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2, 2.0.0-beta, 2.0.0-alpha Environment: Java Reporter: Werner Punz The pprResponseWriter.delete(id) resolves to changesdelete id=id/delete the /changes is missing, I will issue a fix on monday when I commit my work on the PartialResponseWriterImpl, including the unit test which triggered this error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
