Re: Sick leave
Hey Werner, Sorry to hear that! I wish you a speedy recovery. Hope you get well soon! Regards, Jan-Kees Op 20 jan. 2012 16:15 schreef Matt Benson gudnabr...@gmail.com het volgende: Hi Werner, Sorry to hear that you are having health problems. I wish you a speedy recovery. Matt On Fri, Jan 20, 2012 at 2:26 AM, Werner Punz werner.p...@gmail.com wrote: I am currently on sick leave, which means, that I will be able to monitor the mailinglist about once per day, but bugfixes and implementation work will be postponed for a few weeks. The codebase for the jsf.js part is in an excellent state so it should be ok for 2-3 new releases and if something severe erupts in that part I will give consulting to whoever wants to tackle the task. The Ext-Scripting codebase has been now fixed up so that it works with the latest myfaces implementations, a new release will be pending as soon as I am out of the hospital. I will be back in the old state and working again for MyFaces in 2-3 weeks. Werner
Re: [COMMUNITY] MyFaces += Matt Benson
Welcome to the club Matt! Cheers, Jan-Kees 2011/8/16 Grant Smith work.gr...@gmail.com Welcome ! On Tue, Aug 16, 2011 at 12:26 PM, Matt Benson gudnabr...@gmail.comwrote: Thanks all! Matt On Tue, Aug 16, 2011 at 2:18 PM, Leonardo Uribe lu4...@gmail.com wrote: Welcome! Leonardo 2011/8/16 Jakob Korherr jakob.korh...@gmail.com: Welcome, Matt! Regards, Jakob 2011/8/16 Gerhard Petracek gpetra...@apache.org: The MyFaces PMC is proud to announce a new addition to our community. Please welcome Matt Benson as the newest MyFaces committer! Matt is an active member of the MyFaces community, especially in MyFaces Core and MyFaces Extensions Validator. @Matt: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml Welcome regards, Gerhard -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
Re: Proposal: Change groupId of myfaces-impl-ee6 to org.apache.myfaces.core.internal
+1 Good idea! /JK Op 7 jul. 2011 19:42 schreef Gerhard Petracek gerhard.petra...@gmail.com het volgende: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/7 Leonardo Uribe lu4...@gmail.com Hi +1, sounds good. Since it is an internal module that shouldn't and can't be used in a independent way, change its group-id is not a problem. Leonardo Uribe 2011/7/7 Jakob Korherr jakob.korh...@gmail.com: Hi guys, About a year ago we introduced the myfaces-impl-ee6 module, which includes the servlet 3.0 related stuff for myfaces-impl. This means the module is only needed for development reasons and will be shaded into myfaces-impl anyway. However, I noticed that some developers who are not that familiar with MyFaces core don't know what to do with myfaces-impl-ee6. Some even think this is the replacement of myfaces-impl when using java ee 6, which is - of course - complete nonsense. Thus I would like to propose to change the groupId of myfaces-impl-ee6 from org.apache.myfaces.core to org.apache.myfaces.core.internal. IMO this makes it a lot more clear that this module is for internal purposes only! Any objections, better ideas? Regards, Jakob -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] Release of Extensions CDI (CODI) 1.0.0
+1 Regards, Jan-Kees 2011/7/4 Werner Punz werner.p...@gmail.com +1 Am 03.07.11 05:00, schrieb Gerhard Petracek: Hi, I was running the needed tasks to get the 7th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module - CODI Alternative Config and Impl Modules - CODI Bundles - CODI OSGi Bundles - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 1.0.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). --**-- [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. --**-- Thanks, Gerhard [1] https://repository.apache.org/**content/repositories/** orgapachemyfaces-009/https://repository.apache.org/content/repositories/orgapachemyfaces-009/ [2] https://repository.apache.org/**content/repositories/** orgapachemyfaces-009/org/**apache/myfaces/extensions/cdi/** myfaces-extcdi-parent/1.0.0/**myfaces-extcdi-parent-1.0.0-** source-release.ziphttps://repository.apache.org/content/repositories/orgapachemyfaces-009/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/1.0.0/myfaces-extcdi-parent-1.0.0-source-release.zip [3] http://www.apache.org/**foundation/voting.html#**ReleaseVoteshttp://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] how myfaces-commons-resourcehandler should work with suffix mapping enabled
+1 for option 3, but I'm not sure how much time it takes to implement this
option.
(If it's too much effort, option 2 looks okay to me)
Regards,
Jan-Kees
2011/7/4 Rudy De Busscher rdebussc...@gmail.com
I can agree with jacob that Suffix mapping is bad for resource-requests
but the choosen option shouldn't block developers from using suffix mapping
for pages.
As far as I can understand the discussion - +1 for option 2 (option 3 if
we want to have an advanced config version)
Regards
Rudy
On 3 July 2011 02:33, Bruno Aranda brunoara...@gmail.com wrote:
+1 for 3
Between 2 and 4, I still prefer a filter. For me an init param to deal
with such a specific case is more obscure than a filter, but it may be my
intuition,
Cheers,
Bruno
On 3 July 2011 00:20, Gerhard Petracek gerhard.petra...@gmail.comwrote:
i agree with martin and jakob.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/7/2 Jakob Korherr jakob.korh...@gmail.com
Hi,
I totally agree with Martin on the preferred options and the filter
question.
IMO there should not be any filter. Furthermore I really don't
understand why you want suffix mapping to work so badly, Leonardo.
Suffix mapping is bad for resource-requests (maybe even an epic fail),
because a css file is accessed via e.g. style.css.jsf. If the
mime-type is stripped or ignored or whatever, the browser (note there
are pretty bad browsers out there) might think this is a *.jsf file..
And there are some more reasons, that I can explain on request to
everyone interested.
Regards,
Jakob
2011/7/1 Leonardo Uribe lu4...@gmail.com:
Hi Martin
2011/7/1 Martin Marinschek mmarinsc...@apache.org:
Hi Leo,
how is 4 better than 2?
I was thinking on a scenario where some user want some other feature
in myfaces-commons-resourcehandler like gzip compression, i18n locale
appended to request path, library relocation of provide a custom
request path pointing to a Content Delivery Network or just a
directory inside the web application, and he/she is not interested in
solution to the issue presented before.
In such case, suffix mapping alone should work. Note 2 requires a
prefixed mapping (note the assumption that /faces), but 4 does not
enforce that, so it will work on both prefix and suffix mapping, but
if you want a solution for the previous problem you just add the
filter and problem solved. A filter is a simple solution to implement,
and it will work without problem in any scenario. Note in this case
the filter will be used only when suffix mapping is used.
best regards,
Leonardo Uribe
2 is my preferred option, 3 if someone has the time to invest in
this.
I don't see the additional value of 4.
best regards,
Martin
On 6/30/11, Leonardo Uribe lu4...@gmail.com wrote:
+1 for 3.
Option 4. doesn't cause any conflict, so we can just keep that code
as is.
2011/6/30 Leonardo Uribe lu4...@gmail.com:
Hi
To reference images inside a css file in JSF 2.0, users have to
change
its code from this:
.someclass
{
...
background-image:url('myimage.gif');
...
}
to this:
.someclass
{
...
background-image:url(#{resource['mylib:myimage.gif']});
...
}
This means a lot of changes, including override css files and copy
images to other locations.
Some months ago, a new module was added in MyFaces commons, with
the
objective of handle that problem in a gracefully way (just don't
change anything on the css file and make JSF load the images). But
there are different points of view about how to handle it on the
implementation of that module.
Things works well when prefix mapping is used for FacesServlet. But
with suffix mapping, by default all resources have an additional
suffix added on its request path. So, the resource url looks
something
like this:
http://
[server][port]/[webapp]/javax.faces.resource/mylib/image.gif.jsf
breaking the css file.
The intention is allow suffix mapping for jsf files, but prefix
mapping for resource links. There are the following alternatives:
1. Enforce prefix mapping for jsf applications using this module
and
do not support suffix mapping at all.
2. Add a prefix mapping entry for FacesServlet and create a web
config
init param to indicate that mapping will be used to handle
resources.
If such param is no present, assume /faces as prefix mapping
used.
3. Add a prefix mapping entry for FacesServlet and detect it
automatically, parsing web.xml file and in servlet 3.0 use
ServletRegistration. A web config init param anyway should be
provided
for handle portlets case.
4. Use a special filter and detect if was setup automatically,
looking
on application map if the filter was set or not and a web config
init
param to know the mapping
Re: [jira] [Commented] (MYFACES-3130) [PERF] Avoid unnecessary AbstractList$Itr instances
+1! I thought RandomAccess was implemented by way more classes, but looking at the list of implementors, I guess checking for RandomAccess is the best choice. 2011/5/14 Jakob Korherr (JIRA) dev@myfaces.apache.org [ https://issues.apache.org/jira/browse/MYFACES-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13033496#comment-13033496] Jakob Korherr commented on MYFACES-3130: +1 for that Jan-Kees. But I would check for (instanceof RandomAccess) rather than ArrayList (see [1]). [1] http://download.oracle.com/javase/1,5.0/docs/api/java/util/RandomAccess.html [PERF] Avoid unnecessary AbstractList$Itr instances --- Key: MYFACES-3130 URL: https://issues.apache.org/jira/browse/MYFACES-3130 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Environment: myfaces core trunk Reporter: Martin Kočí Attachments: MYFACES-3130-example.patch Similar issue: MYFACES-3129 loop from java 5: for (Object object: objects) creates new instance of AbstractList$Itr, if objects are instance of ArrayList. Similar situation is with explicit .iterator() call. In my testcases, it is about ~ 100 000 instances per request/response. Creation itself is cheap, but triggers GC lately. I suggest to use old index-style for (i = 0; i childCount; i++) if possible. Are there any rawbacks of index-based iteration? Children is List and as implementation detail we know that it is instance of ArrayList. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
True, but it should only be invoked when the renderer(kit) changes, right?
That shouldn't happen in most cases. And in the case when it does, we pay a
penalty and the page is a bit slower. Doesn't sound like a big deal to
me...?
Regards,
Jan-Kees
2011/5/13 Jakob Korherr jakob.korh...@gmail.com
OK great, thanks Leo!
but caching is valid for all encode* method then. Any ideas how to
detect this component will be rendered in this lifecycle and cache
renderer even for getClientId? stateManagement calls getClientId
(checkIds) before component.encodeBegin. Can we use visitTree method for
that?
we could use visitTree(), but note that this could be very expensive ;)
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Leonardo Uribe píše v Pá 13. 05. 2011 v 14:59 -0500:
Hi
+1 to both changes.
That means: replace StateHelper with attribute as MYFACES-3136 suggests,
right?
I agree with you about rendererType is always an
String, there is not any mention on the spec saying rendererType could
receive EL expressions. If someone wants to change a renderer, it uses
a RenderKit wrapper or just define another RenderKitId to be used for
the current application.
Please note this description of UIViewRoot.getRenderKitId :
... Return the render kit identifier of the RenderKit associated with
this view. Unless explicitly set, as in
ViewHandler.createView(javax.faces.context.FacesContext,
java.lang.String), the returned value will be null. ...
and setRenderKitId:
... Set the render kit identifier of the RenderKit associated with
this view. This method may be called at any time between the end of
Apply Request Values phase of the request processing lifecycle (i.e.
when events are being broadcast) and the beginning of the Render
Response phase. ...
So any caching must preserve this behavior.
Thats very interesting, with this behaviour it is possible to change
renderkit in actionListener for example. But it also means that renderer
cannot be be cached UIComponentBase:
1) UIComponent.decode - caches renderer
2) INVOKE_APPLICATION - changes renderKit
3) UIComponent.encodeBegin - uses old cached renderer
but caching is valid for all encode* method then. Any ideas how to
detect this component will be rendered in this lifecycle and cache
renderer even for getClientId? stateManagement calls getClientId
(checkIds) before component.encodeBegin. Can we use visitTree method for
that?
Kočičák
regards,
Leonardo
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
trinidad caches Renderer instance in UIXComponentBase so they at least
suppose that rendererType cannot change during one render/response and
no need for evaluate it in every getRendererType() call - see
MYFACES-3144.
Other libs I'll check.
Regards,
Kočičák
Jakob Korherr píše v Pá 13. 05. 2011 v 16:44 +0200:
Hmm, ok.
I also can't think of a scenario where you would use something like
this right now. But I'll think of it and do some research..
Martin, could you take a look at some of the prominent JSF component
libs (like Primefaces, Trinidad, Tomahawk, Tobago, RichFaces,
IceFaces) and search in their code for something like this? If you
don't find anything there, then it should be pretty safe to remove
the
ValueExpression support from rendererType!
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
from spec:
.. Because the components themselves store only a rendererType
property
(a logical identifier of a particular Renderer) ..
rendererType = Identifier of the Renderer instance (from the set
of
Renderer rendererType String instances supported by the RenderKit
associated with the component tree we are processing.
The default value of the rendererType property must be set to ...
(always String in spec)
JavaDoc: setRendererType - rendererType = Logical identifier of the
type
of Renderer to use, or null for components that render themselves
It seems to me that rendererType is String-only, not
ValueExpression.
Similar attributes are componentType and componentFamily -those are
String-only I think.
Internally in code I don't see
component.setValueExpression(rendererType, ve).
a:component rendererType=#{bean.getRendererType} / is not
possible.
About state saving and rendererType I found nothing.
Jakob Korherr píše v Pá 13. 05. 2011 v 16:11 +0200:
Hi Martin,
Have you checked the JSF 2.1 and 2.0 specs yet?
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
two questions :
1) can UIComponent.rendererType be ValueExpression? If yes, in
which
situation is useful to use it?
2) should be rendereType saved
Re: [VOTE] Release of Extensions CDI (CODI) 0.9.5
+1 Regards, Jan-Kees 2011/5/11 Hazem Saleh haz...@apache.org +1 On Wed, May 11, 2011 at 10:02 AM, Leonardo Uribe lu4...@gmail.com wrote: +1 2011/5/10 Mark Struberg strub...@yahoo.de: puh, finally found the 2 hours to verify the release. +1 * tested with 2 real world projects * signature verified * sha1 + md5 ok * source distribution builds * rat check ok LieGrue, strub --- On Mon, 5/9/11, Werner Punz werner.p...@gmail.com wrote: From: Werner Punz werner.p...@gmail.com Subject: Re: [VOTE] Release of Extensions CDI (CODI) 0.9.5 To: dev@myfaces.apache.org Date: Monday, May 9, 2011, 8:42 PM +1 Am 09.05.11 22:32, schrieb Jakob Korherr: +1 Regards, Jakob 2011/5/9 Gerhard Petracekgerhard.petra...@gmail.com: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/5/9 Gerhard Petracekgpetra...@apache.org Hi, I was running the needed tasks to get the 6th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module - CODI Distribution Modules - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 0.9.5 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-032/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-032/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/0.9.5/myfaces-extcdi-parent-0.9.5-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Visualize and share your social networks 2D and 3D: http://www.mapmysocial.com
[jira] [Commented] (MYFACES-3130) [PERF] Avoid unnecessary AbstractList$Itr instances
[ https://issues.apache.org/jira/browse/MYFACES-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13032347#comment-13032347 ] Jan-Kees van Andel commented on MYFACES-3130: - One comment. Since we know some of the collections where the performance gain is substantial, I suggest to put some instanceof ArrayList checks in the code and log a warning that an ArrayList is more suitable. I know it's not strictly necessary, but at least it warns users for bad performance. About the concurrentmodificationexception, why not just do a list.toArray() and then loop over that array? It might even improve performance (not tested)... [PERF] Avoid unnecessary AbstractList$Itr instances --- Key: MYFACES-3130 URL: https://issues.apache.org/jira/browse/MYFACES-3130 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Environment: myfaces core trunk Reporter: Martin Kočí Attachments: MYFACES-3130-example.patch Similar issue: MYFACES-3129 loop from java 5: for (Object object: objects) creates new instance of AbstractList$Itr, if objects are instance of ArrayList. Similar situation is with explicit .iterator() call. In my testcases, it is about ~ 100 000 instances per request/response. Creation itself is cheap, but triggers GC lately. I suggest to use old index-style for (i = 0; i childCount; i++) if possible. Are there any rawbacks of index-based iteration? Children is List and as implementation detail we know that it is instance of ArrayList. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release of Extensions CDI (CODI) 0.9.4
+1 Regards, Jan-Kees 2011/4/4 Rudy De Busscher rdebussc...@gmail.com +1 Regards Rudy On 4 April 2011 09:44, Mark Struberg strub...@yahoo.de wrote: +1 LieGrue, strub --- On Sun, 4/3/11, Werner Punz werner.p...@gmail.com wrote: From: Werner Punz werner.p...@gmail.com Subject: Re: [VOTE] Release of Extensions CDI (CODI) 0.9.4 To: dev@myfaces.apache.org Date: Sunday, April 3, 2011, 8:17 PM +1 Werner Am 03.04.11 22:16, schrieb Leonardo Uribe: +1 2011/4/3 Hazem Saleh haz...@apache.org mailto:haz...@apache.org +1 On Sun, Apr 3, 2011 at 8:58 AM, Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com wrote: +1 Regards, Jakob 2011/4/2 Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/4/2 Gerhard Petracek gpetra...@apache.org mailto:gpetra...@apache.org Hi, I was running the needed tasks to get the 5th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module - CODI Distribution Modules - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 0.9.4 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-062/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-062/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/0.9.4/myfaces-extcdi-parent-0.9.4-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Visualize and share your social networks 2D and 3D: http://www.mapmysocial.com http://www.mapmysocial.com/
[jira] Created: (MYFACES-3049) Bean Validation doesn't work with Glassfish el-impl-2.2
Bean Validation doesn't work with Glassfish el-impl-2.2
---
Key: MYFACES-3049
URL: https://issues.apache.org/jira/browse/MYFACES-3049
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.4
Environment: Tomcat 2.0.29
Reporter: Jan-Kees van Andel
I have this expression in my Facelet: #{newPaymentBean.payment.toAccount}
payment resolves to the following:
@Entity
public class Payment implements Serializable {
// More stuff...
@NotNull @AccountNumber private String toAccount;
// More stuff...
}
When debugging in javax.faces.validator._BeanValidatorUELUtils, I noticed the
following on line 47 ValueReference valueReference =
valueExpression.getValueReference(elCtx);:
* With Glassfish EL, valueReference.property is null. This causes the
BeanValidator to return at line 161, and to skip validation.
valueReference.base points to the Payment object btw.
* With JUEL 2.2.3, valueReference.property is toAccount, which is correct
AFAIK.
I'm not sure whether this is a MyFaces or EL issue. I remember that when I
wrote the BeanValidator, that the spec literally said what to do. See:
http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/validator/BeanValidator.html#validate(javax.faces.context.FacesContext,
javax.faces.component.UIComponent, java.lang.Object)
So I guess this is an EL implementation issue, but I filed it nevertheless, at
least for archiving purposes...
WDYT?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3049) Bean Validation doesn't work with Glassfish el-impl-2.2
[
https://issues.apache.org/jira/browse/MYFACES-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997347#comment-12997347
]
Jan-Kees van Andel commented on MYFACES-3049:
-
Not sure if we can do this. You added a null-check already to prevent BV to
validate for example Collections. So adding this fallback will probably break
this, right?
Bean Validation doesn't work with Glassfish el-impl-2.2
---
Key: MYFACES-3049
URL: https://issues.apache.org/jira/browse/MYFACES-3049
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.4
Environment: Tomcat 2.0.29
Reporter: Jan-Kees van Andel
I have this expression in my Facelet: #{newPaymentBean.payment.toAccount}
payment resolves to the following:
@Entity
public class Payment implements Serializable {
// More stuff...
@NotNull @AccountNumber private String toAccount;
// More stuff...
}
When debugging in javax.faces.validator._BeanValidatorUELUtils, I noticed the
following on line 47 ValueReference valueReference =
valueExpression.getValueReference(elCtx);:
* With Glassfish EL, valueReference.property is null. This causes the
BeanValidator to return at line 161, and to skip validation.
valueReference.base points to the Payment object btw.
* With JUEL 2.2.3, valueReference.property is toAccount, which is correct
AFAIK.
I'm not sure whether this is a MyFaces or EL issue. I remember that when I
wrote the BeanValidator, that the spec literally said what to do. See:
http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/validator/BeanValidator.html#validate(javax.faces.context.FacesContext,
javax.faces.component.UIComponent, java.lang.Object)
So I guess this is an EL implementation issue, but I filed it nevertheless,
at least for archiving purposes...
WDYT?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3049) Bean Validation doesn't work with Glassfish el-impl-2.2
[
https://issues.apache.org/jira/browse/MYFACES-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997359#comment-12997359
]
Jan-Kees van Andel commented on MYFACES-3049:
-
Yep, you're right. And I guess we should log a warning (maybe once, to prevent
trashing the log) to show the user that something is wrong with the
configuration (b/c it also hurts performance).
Bean Validation doesn't work with Glassfish el-impl-2.2
---
Key: MYFACES-3049
URL: https://issues.apache.org/jira/browse/MYFACES-3049
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.4
Environment: Tomcat 2.0.29
Reporter: Jan-Kees van Andel
I have this expression in my Facelet: #{newPaymentBean.payment.toAccount}
payment resolves to the following:
@Entity
public class Payment implements Serializable {
// More stuff...
@NotNull @AccountNumber private String toAccount;
// More stuff...
}
When debugging in javax.faces.validator._BeanValidatorUELUtils, I noticed the
following on line 47 ValueReference valueReference =
valueExpression.getValueReference(elCtx);:
* With Glassfish EL, valueReference.property is null. This causes the
BeanValidator to return at line 161, and to skip validation.
valueReference.base points to the Payment object btw.
* With JUEL 2.2.3, valueReference.property is toAccount, which is correct
AFAIK.
I'm not sure whether this is a MyFaces or EL issue. I remember that when I
wrote the BeanValidator, that the spec literally said what to do. See:
http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/validator/BeanValidator.html#validate(javax.faces.context.FacesContext,
javax.faces.component.UIComponent, java.lang.Object)
So I guess this is an EL implementation issue, but I filed it nevertheless,
at least for archiving purposes...
WDYT?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-3049) Bean Validation doesn't work with Glassfish el-impl-2.2
[
https://issues.apache.org/jira/browse/MYFACES-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan-Kees van Andel resolved MYFACES-3049.
-
Resolution: Fixed
Fix Version/s: 2.0.5-SNAPSHOT
Fixed. Added the check, fallback and warning as discussed with Jakob.
Bean Validation doesn't work with Glassfish el-impl-2.2
---
Key: MYFACES-3049
URL: https://issues.apache.org/jira/browse/MYFACES-3049
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.4
Environment: Tomcat 2.0.29
Reporter: Jan-Kees van Andel
Assignee: Jan-Kees van Andel
Fix For: 2.0.5-SNAPSHOT
I have this expression in my Facelet: #{newPaymentBean.payment.toAccount}
payment resolves to the following:
@Entity
public class Payment implements Serializable {
// More stuff...
@NotNull @AccountNumber private String toAccount;
// More stuff...
}
When debugging in javax.faces.validator._BeanValidatorUELUtils, I noticed the
following on line 47 ValueReference valueReference =
valueExpression.getValueReference(elCtx);:
* With Glassfish EL, valueReference.property is null. This causes the
BeanValidator to return at line 161, and to skip validation.
valueReference.base points to the Payment object btw.
* With JUEL 2.2.3, valueReference.property is toAccount, which is correct
AFAIK.
I'm not sure whether this is a MyFaces or EL issue. I remember that when I
wrote the BeanValidator, that the spec literally said what to do. See:
http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/validator/BeanValidator.html#validate(javax.faces.context.FacesContext,
javax.faces.component.UIComponent, java.lang.Object)
So I guess this is an EL implementation issue, but I filed it nevertheless,
at least for archiving purposes...
WDYT?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [myfaces site] community information
Hey, I like the way it's written. Well structured and the Overview table gives a nice overview. Also the Getting Started guide is well readable. There seems to be a bit overlap with some other Wiki pages, but I don't think that's a big issue... So I think the format is good. If more depth is needed, we can always add some extra references to more in-depth articles or Wikis. Regards, Jan-Kees 2011/2/17 Jakob Korherr jakob.korh...@gmail.com Hi Bart, I just read the Welcome to the Apache MyFaces Project site and I really like it, especially the brief history and the project overview table. Great work :) The other stuff also looks pretty good, but I want the read it in more detail in the next days. Regards, Jakob 2011/2/17, Bart Kummel b...@kummelweb.nl: Hi all, I did not get any reply on my previous mail yet. Before I continue adding documentation to the Draft pages on the wiki, I would really appreciate to hear if I'm going in the right direction so far. I'm not looking for detailed, in-depth documentation reviews yet. I'd just like to hear if this is the kind of stuff you're looking for. Do I have enough details? Or too much details perhaps? Please let me know! I will be on vacation for a week, starting tomorrow. I've planned to continue the documentation work after I return. Best regards, Bart Kummel On Sat, Feb 12, 2011 at 16:28, Bart Kummel b...@kummelweb.nl wrote: Hi all, Today, I have been adding some initial stuff to http://wiki.apache.org/myfaces/Drafts/Site/ and some pages below that. Most of the texts are slightly adapted texts from my book. Please let me know what you think about this. Feel free to edit the pages to correct errors or add useful info. I hope to add some more stuff in the weeks to come. FYI: I have signed an ICLA aggreement and sent it to the Apache secretary. I got a confirmation that it was received. Best regards, Bart On Sat, Feb 5, 2011 at 17:55, Bart Kummel b...@kummelweb.nl wrote: Hi all, This sounds good from my perspective as an author. I'll discuss this with the publisher first now. I'll keep y'all posted. Best regards, Bart On Fri, Feb 4, 2011 at 18:21, Gerhard gerhard.petra...@gmail.com wrote: imo pinging the legal mailing list is a great idea. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/2/4 Mark Struberg strub...@yahoo.de Hi! First of all: thanks Bart, that would be way cool if you could help us with pimping our documentation! For the legal question: Actually contains of 2 parts: All people who like to write articles in our Wiki need to have a CLA [1] on file. This is just to make sure that the ASF cannot get blamed for 'stealing' things from somewhere. Just send the signedscanned iCLA to secret...@apache.org and that's all from the ASF side. The other legal aspect is if you can reuse parts of your book. Please ask for the ok of your publisher. Usually that's not a big deal because they are happy about such ads ;) But it has to be done, just to make sure. All: I know the wiki/CMS is a community project, but if the contribution is homogenuous and reaches a certain size, then I think we can also add a preposition containing something like Parts of this article are taken from and based upon Bart Kummels Book 'Apache MyFaces 1.2 Web Application Development', packtpub publishing 2009. Not sure how we express the grant to publish it on our wiki though... All, is this ok from a community perspective? Bart i,s this ok from an Authors perspective? Any more input? Or should we check with legal or board to be sure? LieGrue, strub [1] http://www.apache.org/licenses/icla.txt --- On Fri, 2/4/11, Gerhard gerhard.petra...@gmail.com wrote: From: Gerhard gerhard.petra...@gmail.com Subject: Re: [myfaces site] community information To: MyFaces Development dev@myfaces.apache.org Date: Friday, February 4, 2011, 3:58 PM as far as i know the publisher supports open-source projects.however, we have to think about possible issues.maybe a patch with Grant license to ASF for inclusion in ASF works (as per the Apache License §5) would be a good idea (before we commit the final text). regards,gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/2/4 Gerhard gerhard.petra...@gmail.com great to hear that you will have time for an initial brainstorming! regards,gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/2/4 Bart Kummel
Re: [TRINIDAD] Time for a new Trindiad Beta Release
Hey Andy, You can also do an svn relocate from http to https. In that case you don't have to checkout everything again. Might save some time... See: http://svnbook.red-bean.com/en/1.1/re27.html My 2 cents... /JK 2011/2/14 Scott O'Bryan darkar...@gmail.com Andy, make sure you check out using HTTPS instead of http. If the repo is listed as http it won't let you commit. I'll see what I can do when I get into work. On Feb 14, 2011, at 7:27 AM, Andy Schwartz andy.g.schwa...@gmail.com wrote: On Sun, Feb 13, 2011 at 9:46 PM, Scott O'Bryan darkar...@gmail.com wrote: We're waiting for you Andy.. :D Woops. Sorry! what's the JIRA #? https://issues.apache.org/jira/browse/TRINIDAD-2030 Also, are your committer rights all set up? If so, go ahead and test and commit. If not, then I'll do it.. Hrm... I was able to commit to MyFaces core last week from my home machine. Trying to commit to Trinidad now I am seeing: $ svn commit -F ~/log.txt svn: Commit failed (details follow): svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/repos/asf/!svn/act/dff71d8f-1d0b-420e-b014-78a21f1e16ea' This made me think that the svn might be using (incorrect) cached credentials, so I tried adding --no-auth-cache but got the same result. Argh. Scott - would you mind committing my patch so that we can move forward with the beta release while I figure out what the heck is going on with my svn access? Andy
Re: [Cloud] Apache MyFaces and CloudBees
Hey, Actually, I'm working on this example today. I have some spare time today, because of issues at the office. So I hope to get some functionality done and an initial commit out to Apache-Extras. But I'm starting to find out that the biggest real world aspect of this example is the planning. :-) When I can spend some hours, I make a lot of progress, so I'm just going to try to dedicate some time to this. So +1 on using the current demo until the other one is ready, or maybe keep both, if possible. /JK 2011/2/7 Matthias Wessendorf mat...@apache.org Hi, Gerhard and I were on a different thread, with Sacha Labourey (CEO of CloudBees), regarding Hudson/Jenkins builds hosted @CloudBees, the Hudson admins at Apache are now in details with Sacha on that... During that thread I asked Sacha if it would be possible for the Apache MyFaces project (and others) to host their demos on CloudBees' Run@Cloud service. Here is what Sacha suggested: snip I suggest, just sign up for the service, pick a proper domain name (such as apache-myfaces) and forward me your registration e-mail and I'll make sure you don't get billed (the service should stop being free at the end of the month, that way we don't trigger a bill). Then, after a month or so, we take a decision on whether that works for you or not and how we could best move forward. /snip The PMC already discussed this briefly and we thought it's a good opertunity for us to show that Apache MyFaces is ready for the cloud! Please note that this is NO replacement of our current demos, that are hosted by our friends from Irian!! Last week there was a discussion about Jan-Kees' real-world example, which uses: MyFaces/CDI/CoDI/JPA2 - This is very similar to [1]. Not sure how far Jan-Kees is, but sounds like it's ready soon. IMO we should use that example there - if it takes a bit longer, we can go with [1], for the next few days. WDYT ? Greetings, Matthias [1] https://github.com/matzew/modern-ee-app20 Greetings, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Real world MyFaces 2.0 webapp
Hey, What do you exactly mean with style? The layout-style or the code-style? But sure, I can use any style I guess. I still need to commit the first version, but it's hard to dedicate time to this stuff, since it's not work related for me, but I'm gonna commit it this/next week, even though it's far from finished and doesn't yet conform to my personal quality standards. But then at least it's committed. /JK 2011/2/3 Gerhard gerhard.petra...@gmail.com hi jan-kees, some weeks ago i extracted our basic style for our demos at apache-extras. it would be great if the real-world example uses the myfaces-style as well. btw. it might be a good idea to bundle the resources - we could release it and all demos just use it as dependency. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/11/28 David Jencks david_jen...@yahoo.com On Nov 28, 2010, at 4:50 AM, Jan-Kees van Andel wrote: Hey, Dunno how this OWB config creeped in. I guess I copy pasted the wrong openwebbeans.properties into the project. It's empty now. CODI is also in now and I'm starting to use it, but since I have been a bit CODI-ignorant lately, I guess I'm not using it to it's full extent. About Bean Validation, we could also use ExtVal in combination with BV to support more advanced use cases, but I'm not going to add it until I need it. When committed, anyone can add this stuff... About BVAL, I didn't use it because it's still incubating and I'm not looking forward to debugging all kinds of crazy integration issues. I want to keep focus on delivering an app and maybe afterwards migrate it to BVAL. What's the current state of the library? BVal works great in geronimo 3 and has been passing standalone tck for months and generally the in-geronimo tck issues have not been with bval but problems with other integrations such as OWB. For maximum portability (?) at least officially you might target the app to a javaee 6 web profile container which would include servlets, jsf, web beans, bean validation and ejb 3 lite already. Or you might try packaging it in two ways, one as a web profile app and one as a servlet app with all the extra support included in the war. david jencks BTW, it's not a *real* real-world app (it's not running in production for a client). I'm not allowed to do that. But it's more an example of how it could look like. Are you all okay with my idea to commit it into a sandbox? Regards, Jan-Kees 2010/11/27 Mark Struberg strub...@yahoo.de big +1 for the real world app useOwbSpecificXmlConfig=true This will be _completely_ removed from OWB in the very near future! This has been the 'old' XML config from the original webbeans spec. I'd also suggest to use Apache bval instead of hibernate validator as JSR-303 impl. This is also the default impl OpenJPA uses by in it's tests. LieGrue, strub --- On Sat, 11/27/10, Gerhard gerhard.petra...@gmail.com wrote: From: Gerhard gerhard.petra...@gmail.com Subject: Re: Real world MyFaces 2.0 webapp To: MyFaces Development dev@myfaces.apache.org Date: Saturday, November 27, 2010, 6:01 PM hi, the codi issue you saw happens due to an owb config bug (see org.apache.webbeans.useOwbSpecificXmlConfig=true) imo we should just use portable features. regards,gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/11/27 Gerhard gerhard.petra...@gmail.com hi, we could also use it for extval, codi,... tests. regards,gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/11/27 Jan-Kees van Andel jankeesvanan...@gmail.com Hey folks, Somewhere in the past I started working on a real world example webapp. I guess it's already a year ago. :-) But now I have some free time to work on this again. Currently I use MyFaces 2.0 (of course), OpenWebBeans and OpenJPA 2.0. I also use Hibernate Validator. I got a strange error with CODI, so I skipped it for now to stay up-to-speed, but I guess we should get that one in. My goal with this example app was to bridge the gap between the current set of example apps and the real world issues that application developers struggle with.It could also be a nice example of a joint effort between multiple Apache projects, which would be good for the professional image of Apache. So, this example app has a pretty big domain model, security, layered architecture, etc. Also stuff like logging, caching and performance is being taken care of, so people can compare their app with this one. And this app can serve as a living documentation in which the answers to Frequently Asked Questions can be found. 2 things:1 Since
Re: [COMMUNITY] MyFaces += Andy Schwartz
Hey Andy, Welcome to the club! Regards, Jan-Kees 2011/1/31 Matthias Wessendorf mat...@apache.org The Myfaces PMC is proud to announce a new addition to our community. Please welcome Andy Schwartz as the newest MyFaces committer! Andy is an active member of the myfaces community, especially on the Trinidad subproject. @Andy: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Getting started to contribute to MyFaces
Hi, There are several ways to contribute: - On the mailinglists, participating in discussions and answering questions. - By contributing bugfixes for issues in the Jira ( https://issues.apache.org/jira/browse/MYFACES), but this might be difficult, since most bugs have specification implications or other subtle consequences. Fixing one bug might cause other bugs. O.t.o.h. it's a good way to get to know the codebase. - By contributing new features, for example in CODI. - By contributing documentation enhancements. It all depends on where your interests are. I.e. do you like working on the core or are you more into the extensions? Regards, Jan-Kees 2011/2/1 Thiwanka Somasiri asthiwa...@gmail.com Hi, I am a newbie to the MyFaces project and I need to know from which point I should start contributing to the project. Can anyone tell me what I should do first? thanks. -- Regards A.S.Thiwanka Somasiri Skype : executionerwild MSN : thi...@ymail.com thi...@ymail.com
Re: [apache-extras] myfaces examples
Hey, My GoogleCode username: jankeesvanandel /JK 2010/12/21 Gerhard gerhard.petra...@gmail.com as far as i know there is a mercurial plugin for hudson. imo we should contact the infrastructure team. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/12/21 Jakob Korherr jakob.korh...@gmail.com I just found out that hudson does not support mercurial. So if we want to use the projects for integration tests on hudson, -1 from me for mercurial. Regards, Jakob 2010/12/21 Rudy De Busscher rdebussc...@gmail.com: rdebusscher Regards Rudy. On 21 December 2010 11:52, Mark Struberg strub...@yahoo.de wrote: mstruberg, since struberg without the 'm' was already taken it seems :( LieGrue, strub --- On Tue, 12/21/10, Gerhard gerhard.petra...@gmail.com wrote: From: Gerhard gerhard.petra...@gmail.com Subject: Re: [apache-extras] myfaces examples To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, December 21, 2010, 10:43 AM i've created [1] and [2]. @committers:please post your google user-names and i'll add them. regards,gerhard [1] http://code.google.com/a/apache-extras.org/p/myfaces-extval-examples/[2]http://code.google.com/a/apache-extras.org/p/myfaces-extval-examples/%5B2%5D http://code.google.com/a/apache-extras.org/p/myfaces-codi-examples/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/12/21 Matthias Wessendorf mat...@apache.org +1 On Tue, Dec 21, 2010 at 11:12 AM, Jakob Korherr jakob.korh...@gmail.com wrote: +1 I like the idea. This way community members (!= committers) can contribute examples (and/or test cases) a lot easier. Regards, Jakob 2010/12/20 Rudy De Busscher rdebussc...@gmail.com: +1 for extra examples. With mercurial, I had already some 'strange' things (like directories not visible in pre-commit list but still commited, ...) but probably better for forking/branching. So no opinion about the technology used. Regards Rudy. On 18 December 2010 12:21, Werner Punz werner.p...@gmail.com wrote: If we have the choice between svn and Mercurial thesn please go for Mercurial. Merc is not my personally preferred rcs (which is git) but it is way better than SVN and a very good RCS. I think it should be no problem for most people to install Merc and do a checkout especially since it has better Windows support than GIT. Werner Am 18.12.10 11:42, schrieb Gerhard: hi @ all, imo we should host some examples at apache-extras. it would be easier for contributors to donate their examples. we have the choice between svn and mercurial. the advantage of svn is that most contributors are familiar with svn. however, with mercurial it's easier for contributors to fork the repository and to contribute their examples. moreover, it's easier to mirror the repository e.g. to bitbucket which offers more features. furthermore, it would be nice to have one repository per subproject/topic. e.g. myfaces-extval-examples, myfaces-codi-examples, myfaces-stacks-examples, ..., myfaces-helpline (for easier communication on the users-list) that would allow a clear separation concerning the wiki and the issue tracker. - +1 for mercurial and one repository per subproject/topic. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Commented: (EXTCDI-92) ConversationUtils.cacheWindowId() ignores session invalidation
[ https://issues.apache.org/jira/browse/EXTCDI-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12974363#action_12974363 ] Jan-Kees van Andel commented on EXTCDI-92: -- Just ran the test again, but now I get the following stack trace when I invalidate the session: javax.enterprise.context.ContextNotActiveException: WebBeans context with scope type annotation @SessionScoped does not exist within current thread org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:309) org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:124) org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:95) org.javassist.tmp.java.lang.Object_$$_javassist_16.getCurrentWindowContext(Object_$$_javassist_16.java) org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.storeCurrentViewIdAsOldViewId(ConversationUtils.java:222) org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.storeCurrentViewIdAsOldViewId(ConversationUtils.java:215) org.apache.myfaces.extensions.cdi.jsf.impl.navigation.AccessScopeAwareNavigationHandler.handleNavigation(AccessScopeAwareNavigationHandler.java:49) org.apache.myfaces.extensions.cdi.jsf2.impl.navigation.CodiNavigationHandler.handleNavigation(CodiNavigationHandler.java:78) org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:125) org.apache.myfaces.extensions.cdi.jsf.impl.security.SecurityViolationAwareActionListener.processAction(SecurityViolationAwareActionListener.java:49) org.apache.myfaces.extensions.cdi.jsf.impl.config.view.ViewControllerActionListener.processAction(ViewControllerActionListener.java:60) org.apache.myfaces.extensions.cdi.jsf.impl.listener.action.CodiActionListener.processAction(CodiActionListener.java:52) javax.faces.component.UICommand.broadcast(UICommand.java:120) javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:969) javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:275) javax.faces.component.UIViewRoot._process(UIViewRoot.java:1281) javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:707) org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:34) org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:171) org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.execute(CodiLifecycleWrapper.java:71) javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) ConversationUtils.cacheWindowId() ignores session invalidation -- Key: EXTCDI-92 URL: https://issues.apache.org/jira/browse/EXTCDI-92 Project: MyFaces CODI Issue Type: Bug Components: JEE-JSF20-Module Affects Versions: 0.9.0 Environment: MyFaces Core 2.0.3 trunk, OWB 1.0.0, Tomcat 6.0.29 with Glassfish EL libs Reporter: Jan-Kees van Andel Attachments: EXTCDI-92.patch A while ago, I raised issue MYFACES-2979. I now wanted to fix and commit it, but I don't get this exception anymore, because I added CODI to my application a while ago. Reason: After invalidating, CODI re-initializes the Session, so it's not null anymore and the DebugPhaseListener stuff doesn't throw an exception anymore. However, I don't think this behavior is desirable. After all, I've invalidated the session in my application code, so I don't want any framework to re-initialize it without questioning. I can't come up with an example of anything that really breaks because of this, but it's not very nice and efficient. It happens in the following method: org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils#cacheWindowId() on line 191. Wdyt? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Result (was: [VOTE] release for myfaces core 2.0.3)
+1 on a bugfix release in January /JK On 17 Dec 2010 18:08, Gerhard gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/12/17 Leonardo Uribe lu4...@gmail.com Hi +1 on release in January. regards, Leonardo 2010/12/17 Werner Punz werner.p...@gmail.com Ok +1 we can do that, the new release infrastructure really is cheap for rolling a release. Werner Am 17.12.10 14:07, schrieb Mark Struberg: yes +1, maybe do just stabilising in the next few weeks and postpone all new features / performance tuning after this 2.0.4 release. LieGrue, strub --- On Fri, 12/17/10, Jakob Korherrjakob.korh...@gmail.com wrote: From: Jakob Korherrjakob.korh...@gmail.com Subject: Re: Result (was: [VOTE] release for myfaces core 2.0.3) To: MyFaces Developmentdev@myfaces.apache.org Date: Friday, December 17, 2010, 12:28 PM IMO we can have 2.0.4 out early January +1 on that. We should roll out the 2.0.3 release, because we already have a pretty big gap between 2.0.2 and 2.0.3. Regards, Jakob 2010/12/17 Matthias Wessendorfmat...@apache.org: with the new infrastructure, votes/releases are cheap. release often, release early... IMO we can have 2.0.4 out early January On Fri, Dec 17, 2010 at 11:03 AM, Werner Punzwerner.p...@gmail.com wrote: Hi Leo, I know the vote has passed but is the problem Marc Encountered with f:viewParams not serious enough to stop the release and redo another vote after it is fixed? Sorry to intercept here, but I think we should not do a release until this is cleared up especially since 2.0.2 was not affected by it. Werner Am 17.12.10 04:10, schrieb Leonardo Uribe: Hi Thanks to all people who vote We have 9 +1 Grant Smith Jakob Korherr Werner Punz Mark Struberg Bruno Aranda Jan-Kees van Andel Gerhard Petracek Matthias Wessendorf Leonardo Uribe so we can continue with the necessary steps to release myfaces core 2.0.3 regards, Leonardo Uribe -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [REVOTE] Apache MyFaces Extension Scripting 1.0
+1! Regards, Jan-Kees 2010/12/14 Gerhard gerhard.petra...@gmail.com +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/12/14 Mark Struberg strub...@yahoo.de +1 LieGrue, strub --- On Tue, 12/14/10, Jakob Korherr jakob.korh...@gmail.com wrote: From: Jakob Korherr jakob.korh...@gmail.com Subject: Re: [REVOTE] Apache MyFaces Extension Scripting 1.0 To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, December 14, 2010, 4:23 PM +1 on the release! Aside from the pom.xml, everything looks fine. Regards, Jakob 2010/12/14 Werner Punz werner.p...@gmail.com: Ok Jakob pointed out that https://repository.apache.org/content/repositories/orgapachemyfaces-017/org/apache/myfaces/extensions/scripting/extscript-core-java6/1.0/extscript-core-java6-1.0.pom does not have any license header. Since I fixed that in the java classes and all xhtml files, I do not want to stop the vote just for a missing license in a build file. This has happend in myfaces in the past as well. I just wanted to point it out. I will keep the vote open unless a bigger issue arises. I will fix it post 1.0 however asap. Werner Am 14.12.10 16:25, schrieb Werner Punz: Hi,after a a stopped voting due to missing licensing headers, I have fixed the issue and am going to restart the vote again. I have running the needed tasks to get the 1.0 release of Apache MyFaces Extension Scripting out. Apache MyFaces Extension Scripting provides scripting Language support and dynamic reloading for Apache MyFaces 2.0.x and 1.2.x. For more info about the project and the artifacts take a loot at the site on ([4]). Please note that this vote concerns all of the following parts: Maven artifact group org.apache.myfaces.extensions.scripting v1.0 and all its subprojects The artifacts were deployed on nexus repo [1] and [2] The corresponding tag can be found under: [6] The release notes could be found at [5]. Please take a look at the 1.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Werner Punz [1] https://repository.apache.org/content/repositories/orgapachemyfaces-017/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-017/org/apache/myfaces/extensions/scripting/extscript-root/1.0/extscript-root-1.0-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes [4] http://people.apache.org/~werpu/ext-script-site/ [5] https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314862styleName=TextprojectId=12310964 [6] http://svn.apache.org/repos/asf/myfaces/extensions/scripting/tags/extscript-root-1.0 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] Release for Apache MyFaces Extensions Scripting 1.0
Hey, -1, because of missing license headers in a couple of Java files (like: ExtensionEventListener.java) and also a Groovy file: GroovyGlobalReloadingStrategy.groovy. For the rest it looks great. /JK 2010/12/13 Gerhard gerhard.petra...@gmail.com +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/12/13 Werner Punz werner.p...@gmail.com Hi, I was running the needed tasks to get the 1.0 release of Apache MyFaces Extension Scripting out. Apache MyFaces Extension Scripting provides scripting Language support and dynamic reloading for Apache MyFaces 2.0.x and 1.2.x. For more info about the project and the artifacts take a loot at the site on ([4]). Please note that this vote concerns all of the following parts: Maven artifact group org.apache.myfaces.extensions.scripting v1.0 and all its subprojects The artifacts were deployed on nexus repo [1] and [2] The corresponding tag can be found under: [6] The release notes could be found at [5]. Please take a look at the 1.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Werner Punz [1] https://repository.apache.org/content/repositories/orgapachemyfaces-002/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-002/org/apache/myfaces/extensions/scripting/extscript-root/1.0/extscript-root-1.0-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes [4] http://people.apache.org/~werpu/ext-script-site/ [5] https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314862styleName=TextprojectId=12310964 [6] http://svn.apache.org/repos/asf/myfaces/extensions/scripting/tags/extscript-root-1.0
Re: [VOTE] release for myfaces core 2.0.3
+1 Regards, Jan-Kees 2010/12/14 Gerhard gerhard.petra...@gmail.com +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/12/14 Matthias Wessendorf mat...@apache.org +1 On Tue, Dec 14, 2010 at 5:59 AM, Leonardo Uribe lu4...@gmail.com wrote: +1 2010/12/13 Leonardo Uribe lu4...@gmail.com Hi, I was running the needed tasks to get the 2.0.3 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.4 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.3 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.3 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-012/org/apache/myfaces/core/ https://repository.apache.org/content/repositories/orgapachemyfaces-011/org/apache/myfaces/shared/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces203binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12315976 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (EXTCDI-92) ConversationUtils.cacheWindowId() ignores session invalidation
ConversationUtils.cacheWindowId() ignores session invalidation -- Key: EXTCDI-92 URL: https://issues.apache.org/jira/browse/EXTCDI-92 Project: MyFaces CODI Issue Type: Bug Components: JEE-JSF20-Module Affects Versions: 0.9.0 Environment: MyFaces Core 2.0.3 trunk, OWB 1.0.0, Tomcat 6.0.29 with Glassfish EL libs Reporter: Jan-Kees van Andel A while ago, I raised issue MYFACES-2979. I now wanted to fix and commit it, but I don't get this exception anymore, because I added CODI to my application a while ago. Reason: After invalidating, CODI re-initializes the Session, so it's not null anymore and the DebugPhaseListener stuff doesn't throw an exception anymore. However, I don't think this behavior is desirable. After all, I've invalidated the session in my application code, so I don't want any framework to re-initialize it without questioning. I can't come up with an example of anything that really breaks because of this, but it's not very nice and efficient. It happens in the following method: org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils#cacheWindowId() on line 191. Wdyt? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces builder plugin 1.0.8
+1 Sorry, I did not see that Jakob fixed the issue... /JK 2010/12/6 Grant Smith work.gr...@gmail.com +1 On Sun, Dec 5, 2010 at 8:51 PM, Gerhard gerhard.petra...@gmail.comwrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/12/6 Leonardo Uribe lu4...@gmail.com Hi Somebody else who wants to vote? we need just one +1 PMC vote to release these artifacts. Note without this artifacts, it is not possible to release myfaces core 2.0.3 regards, Leonardo Uribe 2010/12/2 Mark Struberg strub...@yahoo.de +1 (for both the statement and the release) the relativePath is only a warning in maven3 and should be set if the referenced parent pom is usually a part of the reactor build. LieGrue, strub --- On Thu, 12/2/10, Jakob Korherr jakob.korh...@gmail.com wrote: From: Jakob Korherr jakob.korh...@gmail.com Subject: Re: [VOTE] release for myfaces builder plugin 1.0.8 To: MyFaces Development dev@myfaces.apache.org Date: Thursday, December 2, 2010, 11:48 AM Hi, The mentioned problem originates in the fact that the plugin-parent is not the enclosing project of the plugins. To fix this, the plugin-poms have to specify a relativePath element in the parent section that references the correct pom. This is a feature of maven 3 and not a bug, because otherwise there could be build problems. I have just committed the necessary changes to fix this problem, however I think it is not that important and we can continue with the vote (Note that the workaround is use Maven 2). Regards, Jakob 2010/12/1 Leonardo Uribe lu4...@gmail.com: Hi It is not a problem. Maybe there is something wrong with Maven 3 (I'm still in maven 2). In theory, for any plugin, it should compile parent module first and then the plugin, but it seems there is a problem with that maven version, so we can continue with the vote. Anyway, I'll set all parent plugin versions to 1.0.4. regards, Leonardo 2010/12/1 Jan-Kees van Andel jankeesvanan...@gmail.com +0 I just checked out MyFaces on a new, clean laptop with an empty Maven repo. With an empty repo I can't build the maven-plugins project. When I first manually install the maven-plugin-parent module and then build maven-plugins, it works okay. I vote a +0 because I'm not sure if it's just an unimportant Maven 3 issue and I could easily work around it. I haven't yet looked at the cause. It could indicate a dependency issue. This is the error I get: [ERROR] The project org.apache.myfaces.buildtools:myfaces-i18n-plugin:1.0.1-SNAPSHOT (/Users/jankeesvanandel/projects/work/myfaces/build-tools/maven2-plugins/myfaces-i18n-plugin/pom.xml) has 1 error [ERROR] Non-resolvable parent POM: Could not find artifact org.apache.myfaces.buildtools:myfaces-plugin-parent:pom:1.0.5-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 24, column 11 - [Help 2] Regards, Jan-Kees Regards, Jan-Kees 2010/12/1 Jakob Korherr jakob.korh...@gmail.com +1 Everything looks good! Regards, Jakob 2010/11/30 Leonardo Uribe lu4...@gmail.com: +1 2010/11/30 Leonardo Uribe lu4...@gmail.com Hi, I was running the needed tasks to get the 1.0.8 release of Apache MyFaces Builder Plugin out. This release includes some minor changes necessary to build myfaces core 2.0.x and other improvements like: - MYFACES-2955 Allow projects using myfaces builder plugin to be open on Netbeans IDE 6.8 - MYFACES-2956 build-metadata goal does not take into account exclude generated source directory on myfaces-builder-plugin - MYFACES-2963 Set default templates automatically when jsfVersion is 20 or 2.0 with myfaces-builder-plugin - MYFACES-2867 Migrate to Velocity 1.6 - MYFACES-2938 Allow @JSFValidator and @JSFConverter to define custom tagHandler class - MFCOMMONS-17 Add facelet function findComponent (fix to allow put additional stuff on generated facelets-taglib) - MYFACES-2962 Descriptions of components, attributes, etc. are missing in taglib.xml files generated by MyFaces Builder Plugin Testing instructions are available at [3]. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.buildtools artifact myfaces-builder-plugin v1.0.8 [1] 2. Maven artifact group org.apache.myfaces.buildtools artifact myfaces-builder-annotations v1.0.7 [1] The artifacts were deployed to a nexus repository ([1]). Please take a look at the 1.0.8 artifacts and vote! Please note: This vote is majority
Re: [VOTE] release for myfaces builder plugin 1.0.8
+0 I just checked out MyFaces on a new, clean laptop with an empty Maven repo. With an empty repo I can't build the maven-plugins project. When I first manually install the maven-plugin-parent module and then build maven-plugins, it works okay. I vote a +0 because I'm not sure if it's just an unimportant Maven 3 issue and I could easily work around it. I haven't yet looked at the cause. It could indicate a dependency issue. This is the error I get: [ERROR] The project org.apache.myfaces.buildtools:myfaces-i18n-plugin:1.0.1-SNAPSHOT (/Users/jankeesvanandel/projects/work/myfaces/build-tools/maven2-plugins/myfaces-i18n-plugin/pom.xml) has 1 error [ERROR] Non-resolvable parent POM: Could not find artifact org.apache.myfaces.buildtools:myfaces-plugin-parent:pom:1.0.5-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 24, column 11 - [Help 2] Regards, Jan-Kees Regards, Jan-Kees 2010/12/1 Jakob Korherr jakob.korh...@gmail.com +1 Everything looks good! Regards, Jakob 2010/11/30 Leonardo Uribe lu4...@gmail.com: +1 2010/11/30 Leonardo Uribe lu4...@gmail.com Hi, I was running the needed tasks to get the 1.0.8 release of Apache MyFaces Builder Plugin out. This release includes some minor changes necessary to build myfaces core 2.0.x and other improvements like: - MYFACES-2955 Allow projects using myfaces builder plugin to be open on Netbeans IDE 6.8 - MYFACES-2956 build-metadata goal does not take into account exclude generated source directory on myfaces-builder-plugin - MYFACES-2963 Set default templates automatically when jsfVersion is 20 or 2.0 with myfaces-builder-plugin - MYFACES-2867 Migrate to Velocity 1.6 - MYFACES-2938 Allow @JSFValidator and @JSFConverter to define custom tagHandler class - MFCOMMONS-17 Add facelet function findComponent (fix to allow put additional stuff on generated facelets-taglib) - MYFACES-2962 Descriptions of components, attributes, etc. are missing in taglib.xml files generated by MyFaces Builder Plugin Testing instructions are available at [3]. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.buildtools artifact myfaces-builder-plugin v1.0.8 [1] 2. Maven artifact group org.apache.myfaces.buildtools artifact myfaces-builder-annotations v1.0.7 [1] The artifacts were deployed to a nexus repository ([1]). Please take a look at the 1.0.8 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-029/org/apache/myfaces/buildtools/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/buildtools/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://wiki.apache.org/myfaces/BuilderPluginRelease108 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Real world MyFaces 2.0 webapp
Hey, Dunno how this OWB config creeped in. I guess I copy pasted the wrong openwebbeans.properties into the project. It's empty now. CODI is also in now and I'm starting to use it, but since I have been a bit CODI-ignorant lately, I guess I'm not using it to it's full extent. About Bean Validation, we could also use ExtVal in combination with BV to support more advanced use cases, but I'm not going to add it until I need it. When committed, anyone can add this stuff... About BVAL, I didn't use it because it's still incubating and I'm not looking forward to debugging all kinds of crazy integration issues. I want to keep focus on delivering an app and maybe afterwards migrate it to BVAL. What's the current state of the library? BTW, it's not a *real* real-world app (it's not running in production for a client). I'm not allowed to do that. But it's more an example of how it could look like. Are you all okay with my idea to commit it into a sandbox? Regards, Jan-Kees 2010/11/27 Mark Struberg strub...@yahoo.de big +1 for the real world app useOwbSpecificXmlConfig=true This will be _completely_ removed from OWB in the very near future! This has been the 'old' XML config from the original webbeans spec. I'd also suggest to use Apache bval instead of hibernate validator as JSR-303 impl. This is also the default impl OpenJPA uses by in it's tests. LieGrue, strub --- On Sat, 11/27/10, Gerhard gerhard.petra...@gmail.com wrote: From: Gerhard gerhard.petra...@gmail.com Subject: Re: Real world MyFaces 2.0 webapp To: MyFaces Development dev@myfaces.apache.org Date: Saturday, November 27, 2010, 6:01 PM hi, the codi issue you saw happens due to an owb config bug (see org.apache.webbeans.useOwbSpecificXmlConfig=true) imo we should just use portable features. regards,gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/11/27 Gerhard gerhard.petra...@gmail.com hi, we could also use it for extval, codi,... tests. regards,gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/11/27 Jan-Kees van Andel jankeesvanan...@gmail.com Hey folks, Somewhere in the past I started working on a real world example webapp. I guess it's already a year ago. :-) But now I have some free time to work on this again. Currently I use MyFaces 2.0 (of course), OpenWebBeans and OpenJPA 2.0. I also use Hibernate Validator. I got a strange error with CODI, so I skipped it for now to stay up-to-speed, but I guess we should get that one in. My goal with this example app was to bridge the gap between the current set of example apps and the real world issues that application developers struggle with.It could also be a nice example of a joint effort between multiple Apache projects, which would be good for the professional image of Apache. So, this example app has a pretty big domain model, security, layered architecture, etc. Also stuff like logging, caching and performance is being taken care of, so people can compare their app with this one. And this app can serve as a living documentation in which the answers to Frequently Asked Questions can be found. 2 things:1 Since everybody has a different idea of what a good app looks like, I expect a lot of discussions on the mailing list. But I think this is a good thing, because those discussions are also valuable for developers. Based on those discussions, they can choose the proper solution for their context. Those discussions can for example be referenced from the source code. 2 Where to put the code? My idea for now was to create a top level sandbox directory within MyFaces because this clearly indicates that it's a work in progress and outsiders shouldn't look at it yet. But then at least it's in Apache version control. I can also put it into GoogleCode or GitHub, but I prefer Apache, because I think more people will find it there. Status:I currently have a working app with some pages. I want to write some additional pages before I commit it. Of course every line of code may be subject to discussion, but I prefer concrete discussions based on working code. That's why I'd prefer a bigger initial commit, incl. a Wiki page with architectural decisions etc. Wdyt? Regards,Jan-Kees
Real world MyFaces 2.0 webapp
Hey folks, Somewhere in the past I started working on a real world example webapp. I guess it's already a year ago. :-) But now I have some free time to work on this again. Currently I use MyFaces 2.0 (of course), OpenWebBeans and OpenJPA 2.0. I also use Hibernate Validator. I got a strange error with CODI, so I skipped it for now to stay up-to-speed, but I guess we should get that one in. My goal with this example app was to bridge the gap between the current set of example apps and the real world issues that application developers struggle with. It could also be a nice example of a joint effort between multiple Apache projects, which would be good for the professional image of Apache. So, this example app has a pretty big domain model, security, layered architecture, etc. Also stuff like logging, caching and performance is being taken care of, so people can compare their app with this one. And this app can serve as a living documentation in which the answers to Frequently Asked Questions can be found. 2 things: 1 Since everybody has a different idea of what a good app looks like, I expect a lot of discussions on the mailing list. But I think this is a good thing, because those discussions are also valuable for developers. Based on those discussions, they can choose the proper solution for their context. Those discussions can for example be referenced from the source code. 2 Where to put the code? My idea for now was to create a top level sandbox directory within MyFaces because this clearly indicates that it's a work in progress and outsiders shouldn't look at it yet. But then at least it's in Apache version control. I can also put it into GoogleCode or GitHub, but I prefer Apache, because I think more people will find it there. Status: I currently have a working app with some pages. I want to write some additional pages before I commit it. Of course every line of code may be subject to discussion, but I prefer concrete discussions based on working code. That's why I'd prefer a bigger initial commit, incl. a Wiki page with architectural decisions etc. Wdyt? Regards, Jan-Kees
[jira] Created: (MYFACES-2979) Session invalidation in Development Stage causes error in OpenWebBeans
Session invalidation in Development Stage causes error in OpenWebBeans
--
Key: MYFACES-2979
URL: https://issues.apache.org/jira/browse/MYFACES-2979
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.3-SNAPSHOT
Environment: MyFaces 2.0.3-SNAPSHOT in Dev mode, OpenWebBeans 1.0.0,
Tomcat 6.0.29 (with Glassfish EL 2.2)
Reporter: Jan-Kees van Andel
I have a logout method, shown below:
public String logout() {
final FacesContext fc = FacesContext.getCurrentInstance();
final ExternalContext externalContext = fc.getExternalContext();
try {
externalContext.invalidateSession();
externalContext.redirect(http://www.google.nl;);
} catch (IOException e) {
log.error(Error redirecting after logout, e);
} finally {
fc.responseComplete();
}
return null;
}
When I invoke this method, I get the following Exception from OpenWebBeans:
javax.enterprise.context.ContextNotActiveException: WebBeans context with scope
type annotation @SessionScoped does not exist within current thread
at
org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:309)
at
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:124)
at
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:95)
at
org.apache.myfaces.examples.ebanking.web.bean.SessionBean_$$_javassist_2.getCustomer(SessionBean_$$_javassist_2.java)
at sun.reflect.GeneratedMethodAccessor37.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:302)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:175)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:142)
at org.apache.el.parser.AstValue.getValue(AstValue.java:123)
at org.apache.el.parser.AstEmpty.getValue(AstEmpty.java:45)
at org.apache.el.parser.AstNot.getValue(AstNot.java:42)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
at
org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:85)
at
javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:260)
at
javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1007)
at javax.faces.component.UIComponent.isVisitable(UIComponent.java:289)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:752)
at
javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:991)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:778)
at
javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:991)
at
org.apache.myfaces.view.facelets.tag.ui.DebugPhaseListener._doTreeVisit(DebugPhaseListener.java:310)
at
org.apache.myfaces.view.facelets.tag.ui.DebugPhaseListener.afterPhase(DebugPhaseListener.java:286)
at
org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:111)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:185)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)
This happens because the DebugPhaseListener starts visiting the tree and, in
the process, needs to resolve a value expression, which points to an OWB
session bean.
It only happens when the DebugPhaseListener is installed. In production mode
everything is fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2979) Session invalidation in Development Stage causes error in OpenWebBeans
[
https://issues.apache.org/jira/browse/MYFACES-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12934293#action_12934293
]
Jan-Kees van Andel commented on MYFACES-2979:
-
IMHO, that would be an unwanted side effect of the PhaseListener.
I'm not sure what the spec says about this (I guess nothing), but recreating a
session within the same request that invalidated it, would be pretty bad
behavior if you ask me...
The annoying bit is, if we choose to add a check in the PhaseListener, there
might be other checks we need to add there.
I suggest to fix it in the PhaseListener, to keep it as much side-effect-free
as possible.
Session invalidation in Development Stage causes error in OpenWebBeans
--
Key: MYFACES-2979
URL: https://issues.apache.org/jira/browse/MYFACES-2979
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.3-SNAPSHOT
Environment: MyFaces 2.0.3-SNAPSHOT in Dev mode, OpenWebBeans 1.0.0,
Tomcat 6.0.29 (with Glassfish EL 2.2)
Reporter: Jan-Kees van Andel
I have a logout method, shown below:
public String logout() {
final FacesContext fc = FacesContext.getCurrentInstance();
final ExternalContext externalContext = fc.getExternalContext();
try {
externalContext.invalidateSession();
externalContext.redirect(http://www.google.nl;);
} catch (IOException e) {
log.error(Error redirecting after logout, e);
} finally {
fc.responseComplete();
}
return null;
}
When I invoke this method, I get the following Exception from OpenWebBeans:
javax.enterprise.context.ContextNotActiveException: WebBeans context with
scope type annotation @SessionScoped does not exist within current thread
at
org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:309)
at
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:124)
at
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:95)
at
org.apache.myfaces.examples.ebanking.web.bean.SessionBean_$$_javassist_2.getCustomer(SessionBean_$$_javassist_2.java)
at sun.reflect.GeneratedMethodAccessor37.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:302)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:175)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:142)
at org.apache.el.parser.AstValue.getValue(AstValue.java:123)
at org.apache.el.parser.AstEmpty.getValue(AstEmpty.java:45)
at org.apache.el.parser.AstNot.getValue(AstNot.java:42)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
at
org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:85)
at
javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:260)
at
javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1007)
at javax.faces.component.UIComponent.isVisitable(UIComponent.java:289)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:752)
at
javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:991)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:778)
at
javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:991)
at
org.apache.myfaces.view.facelets.tag.ui.DebugPhaseListener._doTreeVisit(DebugPhaseListener.java:310)
at
org.apache.myfaces.view.facelets.tag.ui.DebugPhaseListener.afterPhase(DebugPhaseListener.java:286)
at
org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:111)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:185)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)
This happens because the DebugPhaseListener starts visiting the tree and, in
the process, needs to resolve a value expression, which points to an OWB
session bean.
It only happens when the DebugPhaseListener is installed. In production mode
everything is fine.
--
This message is automatically generated by JIRA
Re: [CORE] 2.0.3 release ?
+1 on first fixing the Safari issues and Geronimo/JBoss integration. Those three are big improvements and I guess they don't take much time to finish, right? Next week my MyFaces 2.0 iPad app will be on a big screen at the Devoxx keynote! I'd like to use the 2.0.3-SNAPSHOT for this, with Werner's Safari fix. Are there any outstanding issues in this version I need to pay attention to? /JK 2010/11/8 Werner Punz werner.p...@gmail.com Am 06.11.10 10:40, schrieb Matthias Wessendorf: Hi, I was wondering if there are any outstanding issue, or if we should/could think about a 2.0.3 release for myfaces core. Thanks! Matthias Hi, I want to get a bugfix in for the ipad, which I can commit today, I guess I will postpone the other stuff I have been preparing in jsf.js for 2.0.4 then. Werner
[jira] Created: (MYFACES-2965) MyFaces 2.0.2 AJAX crashes Safari on iPad
MyFaces 2.0.2 AJAX crashes Safari on iPad - Key: MYFACES-2965 URL: https://issues.apache.org/jira/browse/MYFACES-2965 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.2 Environment: iPad Safari Reporter: Jan-Kees van Andel Assignee: Werner Punz If you go to http://ipad.parleys.com/parleys-frontend-ipad-1.0/ on your iPad, and then click on the button Latest, Top Rated or some other button that invokes an AJAX request, the browser crashes and goes back to the desktop. A simple debugging session pointed me to the jsf.ajax.request() invocation, but that's still pretty broad. Reverting to 2.0.1 solved the issue. The code can be viewed online at: http://code.google.com/p/parleys-html5/source/browse/#svn/trunk/web-ipad/src/main/webapp Talked offline with Werner about the issue and we think it's somewhere in the 2.0.2 optimizations. Werner's first guess: If you want to check yourself you can set an alert in replacenode in Dom.js and see if the code is reached And see if it finishes. I am 100 percent sure the problem is there. But it is just sixth sense on my part. So just a guessing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2965) MyFaces 2.0.2 AJAX crashes Safari on iPad
[ https://issues.apache.org/jira/browse/MYFACES-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12929360#action_12929360 ] Jan-Kees van Andel commented on MYFACES-2965: - Werner has been debugging his AJAX code. This is the result: ah main difference between android and apple both of them run their own javascript engine they are not the same it is the exists check for send as binary it runs now gotta send that bug to apple all i do is 'undefined' == typeof xhr.sendAsBinary || null == xhr.sendAsBinary apparently that is enough to crash the xhr object of safari as soon as send is called this is a stupid bug on apples side either way I will add mobile safari detection and remove that code for mobile safari mobile safari should be sendAsBinary enabled anyway MyFaces 2.0.2 AJAX crashes Safari on iPad - Key: MYFACES-2965 URL: https://issues.apache.org/jira/browse/MYFACES-2965 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.2 Environment: iPad Safari Reporter: Jan-Kees van Andel Assignee: Werner Punz If you go to http://ipad.parleys.com/parleys-frontend-ipad-1.0/ on your iPad, and then click on the button Latest, Top Rated or some other button that invokes an AJAX request, the browser crashes and goes back to the desktop. A simple debugging session pointed me to the jsf.ajax.request() invocation, but that's still pretty broad. Reverting to 2.0.1 solved the issue. The code can be viewed online at: http://code.google.com/p/parleys-html5/source/browse/#svn/trunk/web-ipad/src/main/webapp Talked offline with Werner about the issue and we think it's somewhere in the 2.0.2 optimizations. Werner's first guess: If you want to check yourself you can set an alert in replacenode in Dom.js and see if the code is reached And see if it finishes. I am 100 percent sure the problem is there. But it is just sixth sense on my part. So just a guessing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [core] FacesEL vs. UEL vs. UEL 2.2
Agreed. I usually don't like numbers in method names, but in this case it's more correct. /JK On 30 sep. 2010, at 23:04, Martin Koci martin.kocicak.k...@gmail.com wrote: Hi, there is a disorder in Expression Lauguage names in myfaces core. Currently myfaces (method javax.faces.validator._ExternalSpecifications.isUnifiedELAvailable() for example) output a log: MyFaces Unified EL support enabled But this is a little misleading: there should be Unified EL 2.2 support enabled because it tests presence of EL 2.2. Unified EL support enabled does not make sence at all because JSF use Unified EL as core technology and that cannot be disabled. There are three major versions of ELs: 1) javax.faces.el - old and depreceated 2) javax.el 2.0, 2.1 (from JSP 2.0, 2.1) 3) javax.el 2.2 from JSP 2.2, part of Java EE 6, EL with method invocations Suggestions: Rename isUnifiedELAvailable to isUnifiedEL22Available, TagValueExpressionUEL to TagValueExpressionUEL22 and so on. For EL 2.3 (not released yet) we can add similar methods/classes. Change log to MyFaces Unified EL 2.2 support enabled (method invocations are available). I'll add similiar log MyFaces Faces EL (javax.faces.el) support disabled as part of disabling old technologies WDYT ? Kočičák
[jira] Created: (MYFACES-2932) More error logging when Bean Validation throws an exception at startup
More error logging when Bean Validation throws an exception at startup -- Key: MYFACES-2932 URL: https://issues.apache.org/jira/browse/MYFACES-2932 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.2 Environment: Any Reporter: Jan-Kees van Andel When the Bean Validation implementation fails to startup, for example because it is misconfigured by the developer, or because of some dependency issue (missing slf4j jar or something), the Bean Validator automatically turns itself off. The error is logged as fine, because in many cases the developer doesn't care about this behavior. For example, if bean validation api is provided, but impl is not. In these cases, logging an error is not desirable. But maybe this should be increased to info, to ease debugging in the cases where the developer is interested in why bean validation fails to startup. I guess we change the logging to info, especially because the block of code is guarded by a Class.forName() check, which takes care of the obvious case that Bean Validation is unavailable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jsr-314-open] JSF gathering @ JavaOne (was Re: MyFaces @JavaOne?)
+1 for Thursday. I think my Thursday night is still free. How about meeting at the Hilton, after my talk? According to the current schedule, it's in the Continental Parlor 1/2/3 in the Hilton from 15:30 to 16:30. /JK 2010/9/21 Edward Burns edward.bu...@oracle.com On 9/20/10 23:13 , Kito Mann wrote: We're thinking Thursday might be good for some drinks, if anyone is still around. That would be better for me, actually. I double booked myself for Wednesday night. Kito, thanks for taking point on this one. Ed
[jira] Commented: (MYFACES-2889) [PERF] Remove String.intern() calls in FlashELResolver and ImplicitObjectResolver
[ https://issues.apache.org/jira/browse/MYFACES-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901152#action_12901152 ] Jan-Kees van Andel commented on MYFACES-2889: - True, but in these two cases, the (interned) Strings are only used for Map lookups. And AFAIK, interning has no effect on the performance of the hashcode method... [PERF] Remove String.intern() calls in FlashELResolver and ImplicitObjectResolver - Key: MYFACES-2889 URL: https://issues.apache.org/jira/browse/MYFACES-2889 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.2-SNAPSHOT Environment: JBoss AS 6 M4, Parleys.com JSF2 app Reporter: Jan-Kees van Andel I've been doing some profiling and I see pretty much activity in FlashELResolver.castAndIntern() and ImplicitObjectResolver.castAndIntern(). When I replace the return s.intern() lines by return s, both methods have (of course) much better performance. But I'm pretty sure someone put them there with a reason, like memory footprint. However, I don't see any difference in memory footprint. Any ideas? Do we want to keep the intern() calls? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2889) [PERF] Remove String.intern() calls in FlashELResolver and ImplicitObjectResolver
[PERF] Remove String.intern() calls in FlashELResolver and ImplicitObjectResolver - Key: MYFACES-2889 URL: https://issues.apache.org/jira/browse/MYFACES-2889 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.2-SNAPSHOT Environment: JBoss AS 6 M4, Parleys.com JSF2 app Reporter: Jan-Kees van Andel I've been doing some profiling and I see pretty much activity in FlashELResolver.castAndIntern() and ImplicitObjectResolver.castAndIntern(). When I replace the return s.intern() lines by return s, both methods have (of course) much better performance. But I'm pretty sure someone put them there with a reason, like memory footprint. However, I don't see any difference in memory footprint. Any ideas? Do we want to keep the intern() calls? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Hudson
+1 I didn't know of any Apache Hudson instance. But if we have one, a big yes! /JK 2010/8/20 Grant Smith grantsm...@apache.org Any interest in migrating the builds over to Hudson [1] ? I'm willing to do the legwork and the transition from Continuum. Thanks, Grant. [1] http://hudson.apache.org -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
Re: [DISCUSS] getting rid of all java.net maven repositories
I believe I added this JBoss repo a long time ago because of the Bean Validation API which was not yet released. But I guess this API should at this time also be inside some Geronimo JAR? It might be worthwile to check which one. That would save a repo. Let's see. Eemmm. Yes, it's there. See: http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-validation_1.0_spec/1.0/ So I guess we can safely get rid of the JBoss repo. /JK 2010/8/19 Mark Struberg strub...@yahoo.de s/tomcat/tomahawk/ ;) - Original Message From: Mark Struberg strub...@yahoo.de To: MyFaces Development dev@myfaces.apache.org Sent: Thu, August 19, 2010 7:15:44 PM Subject: Re: [DISCUSS] getting rid of all java.net maven repositories I also found out that we use 4 different versions of shale-test in tomahawk. And shale-test-1.0.3 is pulling in the dev.java.net repository. I now removed all repositories from tomcat and until yet it at least builds fine. We btw also have a repository.jboss.org repo in myfaces-core. But this is way better maintained than the dev.java.net one. Another point would be to better utilise dependencyManagement and pluginManagement. Is it really necessary to use 3 different maven-builder-plugin versions in tomahawk? LieGrue, strub - Original Message From: Michael Kurz michi.k...@gmx.at To: dev@myfaces.apache.org Sent: Thu, August 19, 2010 6:00:00 PM Subject: Re: [DISCUSS] getting rid of all java.net maven repositories Am 19.08.2010 16:58, schrieb Mark Struberg: I just figured that we still pretty often use the java.net maven repositories. They are not well maintained and often lead to weird problems. Today I tried to compile tomahawk and got a weird exception that shale-master-1.pom is broken. Had the same problem some time ago. I think what happened was that the specified repository location issued a redirect which was, for whatever reason, stored in my local pom file! I think what I did then was to manually download the pom. Also, if we use Java JSR spec APIs we should always rely on geronimo spec jars [1] instead of pulling them from the java.net repo! Geronimo spec jars are always IP cleared which is _not_ guaranteed in the java.net repo. +1 We should upgrade tomahawk to myfaces-parent-9 and try to get rid of arbitrary repositories. +1 Michi
Re: GSoC Final
Hi Ali, Nice work dude! Are you supposed to give a live presentation on your project? In that case, the code snippets and images are really tiny and probably not very good readable. You might want to make those a bit bigger. Oh and BTW, slide 14 is good (favorite team: NL). This week I'm gonna try to integrate it in my side project ( http://code.google.com/p/parleys-html5/). I'm doing a talk about this project at JavaOne. I'll mention your work there. Regards, Jan-Kees 2010/8/16 Bruno Aranda brunoara...@gmail.com Good job Ali and congrats! I have some troubles when clicking on the View sources links in the examples. Other than that is great! Cheers, Bruno On 16 August 2010 00:19, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Ali, You really did a great job for your GSoC project. Thanks for all your work! I'll be around and participate in the development of MyFaces. I'll continue to work on Html5 support too. There are great stuff I cannot find time to work on during 3 month GSoC period. That's just great - I am looking forward to it! Regards, Jakob 2010/8/15 Ali Ok al...@aliok.com.tr Hi, GSoC final is tomorrow. So here is my final work (I mean during the GSoC period): SVN folder (tagged for GSoC final) : http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/tags/gsoc_final/ Project website : http://people.apache.org/~aliok/GSoC/tagged/html5-comp-lib-project/target/site/index.html Slides : http://people.apache.org/~aliok/GSoC/tagged/slide/MyFaces2-Html5-Comp-Lib-Tagged.ppt Online showcase : http://html5-comp-lib-showcase-snapshot.latest.aliok-com-tr-test.appspot.com/index.jsf I'll be around and participate in the development of MyFaces. I'll continue to work on Html5 support too. There are great stuff I cannot find time to work on during 3 month GSoC period. I want to thank all of you for your help and feedback during GSoC. Special thanks to my mentor, Matthias, for his guidance and help. Best wishes, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: MyFaces @JavaOne?
Ah nice, see you there! Other JSF folks going as well? /JK 2010/8/16 Matthias Wessendorf mat...@apache.org Howdy, Ali and I are speaking on Thursday, What's cool in Apache MyFaces (containing CODI, Trinidad mobile, HTML5...) -Matthias On Mon, Aug 16, 2010 at 10:05 AM, Jakob Korherr jakob.korh...@gmail.com wrote: As far as I know, Matthias and Ali will also be there! 2010/8/16 Werner Punz werner.p...@gmail.com Am 16.08.10 09:31, schrieb Jan-Kees van Andel: Hi, Just wondering, are any of you guys heading to JavaOne this year? It's not as big as last years, but still a very cool conference I think. Anyway, I'm going and I'm doing a talk with Stephan Janssen about our project on Thursday: The JavaServer Faces (JSF) 2.0 and HTML5 Version of Parleys.com Other MyFaces (or regular JSF) folks attending/speaking at J1? Regards, Jan-Kees I think Matthias is there, isn´t he, I am not sure if somone from Irian is there as well. -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: MyFaces @JavaOne?
I didn't, mainly because I'm pretty sure there are others who know downtown SFO better than I do. But if there is a suggestion, I'll make sure I'll be there. BTW. I'm not sure if everyone (Mojarra, EG, etc...) reads the MyFaces Dev list? /JK 2010/8/16 Kito Mann kito.m...@virtua.com Hey guys, I'l be there all week, and I'm doing a JavaServer Faces Antipatterns and Best Practices session Monday morning. Any suggestions for a JSF night at a bar? --- Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3 Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17 On Mon, Aug 16, 2010 at 9:59 AM, Ali Ok al...@aliok.com.tr wrote: - *Dan Allen* - *Ed Burns* - Hazem - *David Geary* - *Alexander Smirnov,* - *Roger Kitain* are other JSF folks I know, apart from mentioned people before. Cheers, On Mon, Aug 16, 2010 at 4:17 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: Ah nice, see you there! Other JSF folks going as well? /JK 2010/8/16 Matthias Wessendorf mat...@apache.org Howdy, Ali and I are speaking on Thursday, What's cool in Apache MyFaces (containing CODI, Trinidad mobile, HTML5...) -Matthias On Mon, Aug 16, 2010 at 10:05 AM, Jakob Korherr jakob.korh...@gmail.com wrote: As far as I know, Matthias and Ali will also be there! 2010/8/16 Werner Punz werner.p...@gmail.com Am 16.08.10 09:31, schrieb Jan-Kees van Andel: Hi, Just wondering, are any of you guys heading to JavaOne this year? It's not as big as last years, but still a very cool conference I think. Anyway, I'm going and I'm doing a talk with Stephan Janssen about our project on Thursday: The JavaServer Faces (JSF) 2.0 and HTML5 Version of Parleys.com Other MyFaces (or regular JSF) folks attending/speaking at J1? Regards, Jan-Kees I think Matthias is there, isn´t he, I am not sure if somone from Irian is there as well. -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: MyFaces @JavaOne?
LOL, was too lazy to type San Francisco. I'll only hang out at SFO if my flight is late, like last time... 2010/8/16 Matthias Wessendorf mat...@apache.org SFO == airport; most of us are not hanging out there ;-) On Mon, Aug 16, 2010 at 6:19 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: I didn't, mainly because I'm pretty sure there are others who know downtown SFO better than I do. But if there is a suggestion, I'll make sure I'll be there. BTW. I'm not sure if everyone (Mojarra, EG, etc...) reads the MyFaces Dev list? /JK 2010/8/16 Kito Mann kito.m...@virtua.com Hey guys, I'l be there all week, and I'm doing a JavaServer Faces Antipatterns and Best Practices session Monday morning. Any suggestions for a JSF night at a bar? --- Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3 Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17 On Mon, Aug 16, 2010 at 9:59 AM, Ali Ok al...@aliok.com.tr wrote: Dan Allen Ed Burns Hazem David Geary Alexander Smirnov, Roger Kitain are other JSF folks I know, apart from mentioned people before. Cheers, On Mon, Aug 16, 2010 at 4:17 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: Ah nice, see you there! Other JSF folks going as well? /JK 2010/8/16 Matthias Wessendorf mat...@apache.org Howdy, Ali and I are speaking on Thursday, What's cool in Apache MyFaces (containing CODI, Trinidad mobile, HTML5...) -Matthias On Mon, Aug 16, 2010 at 10:05 AM, Jakob Korherr jakob.korh...@gmail.com wrote: As far as I know, Matthias and Ali will also be there! 2010/8/16 Werner Punz werner.p...@gmail.com Am 16.08.10 09:31, schrieb Jan-Kees van Andel: Hi, Just wondering, are any of you guys heading to JavaOne this year? It's not as big as last years, but still a very cool conference I think. Anyway, I'm going and I'm doing a talk with Stephan Janssen about our project on Thursday: The JavaServer Faces (JSF) 2.0 and HTML5 Version of Parleys.com Other MyFaces (or regular JSF) folks attending/speaking at J1? Regards, Jan-Kees I think Matthias is there, isn´t he, I am not sure if somone from Irian is there as well. -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Proposal to stop using SVN Keywords - (was: MyFaces shipping with JBoss AS6?)
Hey, I'm not a big fan of code ownership either, but the proposal was just to remove the redundant stuff. If there is a consensus about removing the @author tag too, that's fine with me. Removing all this stuff at once is easier than having multiple runs where we remove one thing at a time. Anyone who likes to keep the @author tags in? I don't really understand what you mean with config file? Do you mean the metadata of each file/directory? I'm not sure if we can easily clean up this stuff, without the risk of corrupting the repo or checkout... /JK 2010/8/11 Matthias Wessendorf mat...@apache.org On Tue, Aug 10, 2010 at 11:55 PM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Hello, why we need the @author tag? I don't like code owner ship. well, some do. I am fine without. In fact a lot of Apache project do so, since there is no code-ownership. SVN has still all the information Does your request mean we don't allow the svn:keywords=Date Author Id Revision HeadURL in the Subversion config file? I am sure the talk is *only* inside the Java files, and not removing the metadata of the file. -M Regards Bernd On Tue, Aug 10, 2010 at 10:00 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: Hi, Sure. For example, take a look at: http://svn.apache.org/repos/asf/myfaces/core/trunk/api/src/main/java/javax/faces/FacesException.java If we remove the SVN stuff, we'll end up with this JavaDoc comment: /** * see Javadoc of a href= http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/index.html;JSF Specification/a * * @author Manfred Geiler */ Or for example: http://svn.apache.org/repos/asf/myfaces/core/trunk/api/src/main/java/javax/faces/application/Application.java This would become: /** * . * * @author Manfred Geiler * @author Stan Silvert */ One last example, a class added in 2.0: http://svn.apache.org/repos/asf/myfaces/core/trunk/api/src/main/java/javax/faces/application/ResourceHandler.java Which would end up like: /** * @author Simon Lessard * @since 2.0 */ What do you think? BTW. I'm thinking of the best way to do this. I guess the best bet is to do a massive find-replace on one project at a time. Generating a patch file would be a nice way to check for possible errors... Regards, Jan-Kees 2010/8/10 Leonardo Uribe lu4...@gmail.com Hi Could you provide an explicit example about how the header of java files should be? best regards, Leonardo -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2861) Remove commons-discovery dependency
[ https://issues.apache.org/jira/browse/MYFACES-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896779#action_12896779 ] Jan-Kees van Andel commented on MYFACES-2861: - Hey Leo, From my understanding, the added value of commons-discovery and commons-beanutils is pretty limited. It might be an idea to think about selectively copying some files from both projects into MyFaces? AFAIK, Discovery is only used to find the LifecycleFactory. We might be able to replace this with the Service Provider mechanism. I'm not sure about all usages of Beanutils though... /JK Remove commons-discovery dependency --- Key: MYFACES-2861 URL: https://issues.apache.org/jira/browse/MYFACES-2861 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.1 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Commons-discovery has a dependency to commons-logging. That cause a transitive dependency to myfaces-impl. To prevent this dependency, we need to move that code into our codebase and refactor it so it uses jul instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2861) Remove commons-discovery dependency
[ https://issues.apache.org/jira/browse/MYFACES-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896781#action_12896781 ] Jan-Kees van Andel commented on MYFACES-2861: - Hi Martin, I don't think that will work, since logging is something you can't exclude easily. Most classes initialize a logger during (class/object) initialization, so you'll end up with a NoClassDef at runtime. I think we're gonna need the transitive dependency... /JK Remove commons-discovery dependency --- Key: MYFACES-2861 URL: https://issues.apache.org/jira/browse/MYFACES-2861 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.1 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Commons-discovery has a dependency to commons-logging. That cause a transitive dependency to myfaces-impl. To prevent this dependency, we need to move that code into our codebase and refactor it so it uses jul instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2871) Remove redundant SVN keywords from class JavaDocs
Remove redundant SVN keywords from class JavaDocs - Key: MYFACES-2871 URL: https://issues.apache.org/jira/browse/MYFACES-2871 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.1 Reporter: Jan-Kees van Andel Assignee: Jan-Kees van Andel Priority: Minor Almost all class file JavaDocs now contain SVN keywords. These are redundant and after a simple poll on the mailinglist, the conclusion is to remove them from the files. Reference back to the original thread: http://markmail.org/thread/tfwvqms4xko3uq2k Still need to decide how to get rid of this stuff. I think a massive find-replace works fine, but there is always a slight risk of big merge conflicts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Proposal to stop using SVN Keywords - (was: MyFaces shipping with JBoss AS6?)
Hi, The issue has been filed: https://issues.apache.org/jira/browse/MYFACES-2871 About the guidelines Michael referred to: - I suggest to completely get rid of all SVN related stuff. - I think it's ok to keep the @author tags. - Also the @since tags seem useful to me. In other words, drop all SVN stuff and keep the rest in place. /JK https://issues.apache.org/jira/browse/MYFACES-2871 2010/8/10 Werner Punz werner.p...@gmail.com +1 of removing this, the info is in svn anyway, why duplicate it? Werner Am 09.08.10 21:43, schrieb Jan-Kees van Andel: Hi, What do you guys think about pruning the SVN keywords in the source files? Matthias pointed out a nice example of an issue you run into with this stuff. 1 Not everybody has (the same) svn:keywords on every file. 2 When 1, it will get out of sync. 3 Unreadable version numbers are pretty useless information (at least for me). 4 If you need to know something about the revision history, SVN itself is a much better place to look. 5 (I think) it looks messy in the source code. Note that I'm not talking about removing everything in a major refactoring. For now, I'm just proposing a convention for new code. I'm also not proposing to remove the @author JavaDoc tag. That's a useful one. I'm talking about the latest modification by $Author and @version $Revision: 799929 $ $Date:...$ stuff. What do you guys think? Regards, Jan-Kees 2010/8/9 Jan-Kees van Andel jankeesvanan...@gmail.com mailto:jankeesvanan...@gmail.com Yeah, I know. I'm so quick. I can edit files back in time. ;-) /JK 2010/8/9 Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org + * @author Leonardo Uribe (latest modification by $Author: jankeesvanandel $) + * @version $Revision: 799929 $ $Date: 2009-08-01 16:29:33 -0500 (sáb, 01 ago 2009) $ did you copy that into your IDE template for new files? :-) -M On Mon, Aug 9, 2010 at 7:25 PM, Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com wrote: Hi Stan I have attached a proposal for this issue on: https://issues.apache.org/jira/browse/MYFACES-2860 It includes the patch to be applied on myfaces, the project created to do the integration, and the jsf deployer used in JBoss AS6 to give a try. It could be good to know what do yo think about it. best regards, Leonardo Uribe -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Proposal to stop using SVN Keywords - (was: MyFaces shipping with JBoss AS6?)
Hi, Sure. For example, take a look at: http://svn.apache.org/repos/asf/myfaces/core/trunk/api/src/main/java/javax/faces/FacesException.java If we remove the SVN stuff, we'll end up with this JavaDoc comment: /** * see Javadoc of a href= http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/index.html;JSF Specification/a * * @author Manfred Geiler */ Or for example: http://svn.apache.org/repos/asf/myfaces/core/trunk/api/src/main/java/javax/faces/application/Application.java This would become: /** * . * * @author Manfred Geiler * @author Stan Silvert */ One last example, a class added in 2.0: http://svn.apache.org/repos/asf/myfaces/core/trunk/api/src/main/java/javax/faces/application/ResourceHandler.java Which would end up like: /** * @author Simon Lessard * @since 2.0 */ What do you think? BTW. I'm thinking of the best way to do this. I guess the best bet is to do a massive find-replace on one project at a time. Generating a patch file would be a nice way to check for possible errors... Regards, Jan-Kees 2010/8/10 Leonardo Uribe lu4...@gmail.com Hi Could you provide an explicit example about how the header of java files should be? best regards, Leonardo
Re: MyFaces shipping with JBoss AS6?
Yeah, I know. I'm so quick. I can edit files back in time. ;-) /JK 2010/8/9 Matthias Wessendorf mat...@apache.org + * @author Leonardo Uribe (latest modification by $Author: jankeesvanandel $) + * @version $Revision: 799929 $ $Date: 2009-08-01 16:29:33 -0500 (sáb, 01 ago 2009) $ did you copy that into your IDE template for new files? :-) -M On Mon, Aug 9, 2010 at 7:25 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Stan I have attached a proposal for this issue on: https://issues.apache.org/jira/browse/MYFACES-2860 It includes the patch to be applied on myfaces, the project created to do the integration, and the jsf deployer used in JBoss AS6 to give a try. It could be good to know what do yo think about it. best regards, Leonardo Uribe -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Proposal to stop using SVN Keywords - (was: MyFaces shipping with JBoss AS6?)
Hi, What do you guys think about pruning the SVN keywords in the source files? Matthias pointed out a nice example of an issue you run into with this stuff. 1 Not everybody has (the same) svn:keywords on every file. 2 When 1, it will get out of sync. 3 Unreadable version numbers are pretty useless information (at least for me). 4 If you need to know something about the revision history, SVN itself is a much better place to look. 5 (I think) it looks messy in the source code. Note that I'm not talking about removing everything in a major refactoring. For now, I'm just proposing a convention for new code. I'm also not proposing to remove the @author JavaDoc tag. That's a useful one. I'm talking about the latest modification by $Author and @version $Revision: 799929 $ $Date:...$ stuff. What do you guys think? Regards, Jan-Kees 2010/8/9 Jan-Kees van Andel jankeesvanan...@gmail.com Yeah, I know. I'm so quick. I can edit files back in time. ;-) /JK 2010/8/9 Matthias Wessendorf mat...@apache.org + * @author Leonardo Uribe (latest modification by $Author: jankeesvanandel $) + * @version $Revision: 799929 $ $Date: 2009-08-01 16:29:33 -0500 (sáb, 01 ago 2009) $ did you copy that into your IDE template for new files? :-) -M On Mon, Aug 9, 2010 at 7:25 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Stan I have attached a proposal for this issue on: https://issues.apache.org/jira/browse/MYFACES-2860 It includes the patch to be applied on myfaces, the project created to do the integration, and the jsf deployer used in JBoss AS6 to give a try. It could be good to know what do yo think about it. best regards, Leonardo Uribe -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: MyFaces shipping with JBoss AS6?
Hi, Great news! It would be very nice if JBoss ships with MyFaces 2. This also opens up possibilities to do some enhancements to increase developer productivity in JBoss, like better resource reloading and so on. Or doing some things more efficient by plugging into the JBoss infrastructure. Just thinking out loud... :) One thing about the JBoss SVN link Stan sent. I took a quick peek at the license header in a Java file and saw that it's LGPL licensed. AFAIK, this is not compatible with ASL, so I suggest to not look at the code while implementing the stuff Stan asked for. WDYT? Regards, Jan-Kees 2010/8/5 Matthias Wessendorf mat...@apache.org Hello Stan, welcome back. We do understand that you can not make any promise on that topic. The fact that some folks at JBoss are thinking about shipping MyFaces (as an alternative option) is a good news for this entire community here. Especially it is a great motivation for the folks that did the main work on ensuring Apache MyFaces 2.x is a great success. On the missing pieces: I am sure that there will be some interested in working on them. Thanks, Matthias Wessendorf PMC Chair Apache MyFaces On Wed, Aug 4, 2010 at 8:42 PM, ssilv...@redhat.com wrote: Hi guys, Would you like to see MyFaces Core ship with JBoss AS6? If so, read on. If you've been around MyFaces awhile, you probably remember that JBoass AS used to ship with MyFaces instead of Mojarra. It was regrettable, but at the time Mojarra was far ahead spec-wise and the powers that be decided my time would be better spent integrating Mojarra instead of improving MyFaces. However, with JBoss AS6 M4, this is no longer an either or proposition. Both MyFaces and Mojarra can live side-by-side. The application can decide which implementation to use: http://community.jboss.org/wiki/JSFonJBossAS6 What's more, changing the default JSF implementation for AS6 is just a matter of changing the defaultJSFConfig property in an XML file. I've talked internally at JBoss about adding MyFaces to the JBoss AS community distribution. Some were for it, and some were very, very for it. Nobody so far is against it. The good part is that I don't think it's a lot of work. It's probably just three or four classes that implement SPI's that I'm guessing MyFaces already has. So this is where the MyFaces Dev group comes in. MyFaces Core 2.0 will run OK on JBoss AS6 right now. However, there is some integration work that is needed for full JEE5 and JEE6 compliance. We need: * An injection provider SPI similar to Mojarra's com.sun.faces.spi.InjectionProvider. * The JBoss/MyFaces implementation of the SPI. I expect this will be very similar to org.jboss.web.jsf.integration.injection.JBossDelegatingInjectionProvider. * An AnnotationProvider SPI similar to Mojarra's com.sun.faces.spi.AnnotationProvider. * A JBoss/MyFaces implementation of the SPI similar to org.jboss.web.jsf.integration.config.JBossAnnotationProvider. * A ServletContextListener class to call for initialization. I expect this will extend from MyFacesServletContextListener and be very similar to org.jboss.web.jsf.integration.config.JBossMojarra20ConfigureListener. If MyFaces Dev decides to take this on, then the code will probably live at Apache and I'll bring it into JBoss AS using Maven. I don't have time to write and maintain the code myself but I'm happy to help out with guidance and to do some refactoring of my code to make this easier. BTW, the JBoss/Mojarra integration code lives here: http://anonsvn.jboss.org/repos/jbossas/projects/jboss-jsf-int/trunk/jboss-faces/ Lastly, let me say that I can't make hard promises right now. I don't know if someone at JBoss/RedHat will come along and nix the idea. However, even if we can't ship MyFaces you will have all the integration points ready and have an easy way to drop in MyFaces whenever you want to use it with JBoss AS. WDYT?? -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: MyFaces shipping with JBoss AS6?
MyFaces has an AnnotationConfigurator [1] which scans the classpath using a simple bytecode scanning mechanism [2] (comparable with the one in Javassist). It's pretty fast, but it's true that classes might be scanned twice. Regards, Jan-Kees [1] http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/config/annotation/AnnotationConfigurator.java [2] http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/config/annotation/_ClassByteCodeAnnotationFilter.java 2010/8/5 ssilv...@redhat.com Quoting David Jencks david_jen...@yahoo.com: I haven't and wont look at the mojarra code but I think you are looking for org.apache.myfaces.config.annotation.LifecycleProvider Looks like that takes care of spec section 5.4 (injection, @PreDestroy, @PostConstruct). How do you deal with section 11.5? This is for finding resource annotations like @ManagedBean or @FacesValidator. I'm assuming that MyFaces does this on its own, but if so it would mean that a lot of stuff gets scanned multiple times by various components like Tomcat. Stan Geronimo has been trying to get everyone to standardize on this style of interface as it lets the implementor support constructor injection transparently. Geronimo's implementations of this use xbean-reflect which provides a handy way to stuff in all the properties and get a fully configured object back. thanks david jencks On Aug 5, 2010, at 5:12 AM, Matthias Wessendorf wrote: Somehow I think there was already work/discussion about it, based on a Tomcat interface. It for sure does bring back some fragile memory. Let me think... On Thu, Aug 5, 2010 at 2:09 PM, Matthias Wessendorf mat...@apache.org wrote: Well, looking at the RI is for sure not OK. I didn't see a problem with the previous provided links (the JBoss code), however I have not opened any of the provided links yet. -Matthias On Thu, Aug 5, 2010 at 1:54 PM, ssilv...@redhat.com wrote: That's OK. I guess I can do the SPI implementations on my end but it might not make it into JBoss AS6 GA. Let's concentrate on the MyFaces SPI's for now. How does MyFaces handle the SPI's like Mojarra has? I'm sure it's OK to look at Mojarra code since it's GPL2, right? If not, you can look at JavaDoc. We need something similar to: com.sun.faces.spi.InjectionProvider https://mojarra.dev.java.net/source/browse/mojarra/trunk/jsf-ri/src/main/java/com/sun/faces/spi/InjectionProvider.java com.sun.faces.spi.AnnotationProvider https://mojarra.dev.java.net/source/browse/mojarra/trunk/jsf-ri/src/main/java/com/sun/faces/spi/AnnotationProvider.java Stan Quoting Matthias Wessendorf mat...@apache.org: At Apache we can not have code that contains (L)GPL code; or depends on it. We had discussion(s) about this in the past. The below link contains references to other (Apache) documents: http://markmail.org/message/qtc4g6vsracgzbok -Matthias On Thu, Aug 5, 2010 at 9:55 AM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: Hi, Great news! It would be very nice if JBoss ships with MyFaces 2. This also opens up possibilities to do some enhancements to increase developer productivity in JBoss, like better resource reloading and so on. Or doing some things more efficient by plugging into the JBoss infrastructure. Just thinking out loud... :) One thing about the JBoss SVN link Stan sent. I took a quick peek at the license header in a Java file and saw that it's LGPL licensed. AFAIK, this is not compatible with ASL, so I suggest to not look at the code while implementing the stuff Stan asked for. WDYT? Regards, Jan-Kees 2010/8/5 Matthias Wessendorf mat...@apache.org Hello Stan, welcome back. We do understand that you can not make any promise on that topic. The fact that some folks at JBoss are thinking about shipping MyFaces (as an alternative option) is a good news for this entire community here. Especially it is a great motivation for the folks that did the main work on ensuring Apache MyFaces 2.x is a great success. On the missing pieces: I am sure that there will be some interested in working on them. Thanks, Matthias Wessendorf PMC Chair Apache MyFaces On Wed, Aug 4, 2010 at 8:42 PM, ssilv...@redhat.com wrote: Hi guys, Would you like to see MyFaces Core ship with JBoss AS6? If so, read on. If you've been around MyFaces awhile, you probably remember that JBoass AS used to ship with MyFaces instead of Mojarra. It was regrettable, but at the time Mojarra was far ahead spec-wise and the powers that be decided my time would be better spent integrating Mojarra instead of improving MyFaces. However, with JBoss AS6 M4, this is no longer an either or proposition. Both MyFaces and Mojarra can live side-by-side. The application can decide which implementation to use: http://community.jboss.org/wiki/JSFonJBossAS6 What's more
[jira] Commented: (MYFACES-2858) pointless oamsubmit inline rendering
[ https://issues.apache.org/jira/browse/MYFACES-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12895224#action_12895224 ] Jan-Kees van Andel commented on MYFACES-2858: - No opinion regarding externalizing the scripts. I think it's a good idea. What I did notice a while ago, was that those scripts are very annoying when doing AJAX. I didn't look at it in detail, but it looked like they messed up the event handling. pointless oamsubmit inline rendering Key: MYFACES-2858 URL: https://issues.apache.org/jira/browse/MYFACES-2858 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.2-SNAPSHOT Reporter: Werner Punz We have had several functions rendered inline for ages, namely appendHiddenInput oamSubmit, the autoscroll stuff etc... I personally think the rendering of those functions as inline scripts is pointless, blows up the browsers tremendously and prevents that the affected scripts can be browser cached. A quick look at the code revealed that there is basically nothing which would prevent to externalize the scripts. My main problem is where to we handle the auto append code. My personal guess is we probably simply should add it as a resource definitions to the commandLink, Button etc.. renderers, any ideas regarding this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2858) pointless oamsubmit inline rendering
[ https://issues.apache.org/jira/browse/MYFACES-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12895258#action_12895258 ] Jan-Kees van Andel commented on MYFACES-2858: - Never mind. I'll report my thingy in a separate issue. It's not related to your externalization. Sorry for the unclear comment. :-) pointless oamsubmit inline rendering Key: MYFACES-2858 URL: https://issues.apache.org/jira/browse/MYFACES-2858 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.2-SNAPSHOT Reporter: Werner Punz We have had several functions rendered inline for ages, namely appendHiddenInput oamSubmit, the autoscroll stuff etc... I personally think the rendering of those functions as inline scripts is pointless, blows up the browsers tremendously and prevents that the affected scripts can be browser cached. A quick look at the code revealed that there is basically nothing which would prevent to externalize the scripts. My main problem is where to we handle the auto append code. My personal guess is we probably simply should add it as a resource definitions to the commandLink, Button etc.. renderers, any ideas regarding this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Myfaces vs. mojarra restore view performance
Hey, I'm very interested in the details behind those 750ms. Can you post the hotspots? Like: number of invocations, ms. self time and ms. total time. Thanks. Regards, Jan-Kees 2010/8/2 Martin Koci martin.k...@aura.cz Hi, our profiling results show that myfaces are significantly slower in restore view phase: com.sun.faces LifeCycle .. restoreView : 80 ms o.a.m.RestoreViewExecutor : 750ms! This result is perfectly reproducible in our case. I profile it on a application real application - I cannot post test case here. Configuration: myfaces or mojarra from trunk, partial state saving, a view with more than 200 UIInput components. Is it a known problem? I will provide more detailed profiling results later. Regards, Martin Kočí
Re: Use maven-shade-plugin to prevent duplicate code
If it helps to make Shared obsolete you have my +1! :-) /JK 2010/7/26 Jakob Korherr jakob.korh...@gmail.com Hi guys, Working on the tests for FlashImpl, I ran into a problem with the AbstractAttributeMap (MYFACES-2840). After fixing it, I needed to copy my changes over to myfaces-test to be able to use the new version in the test case (MYFACESTEST-21). And this copying really sucks... If you think about it there are many, many, many different places in the whole MyFaces project where we have duplicate code, for example package-private, unspecified classes on myfaces-api which also exist in myfaces-impl, classes of myfaces-impl which are used for the mock implementations of myfaces-test, or the biggest one: the shared project. An introduction to the maven-shade-plugin: This plugin lets you use a dependency to another project and then at build time it copies all needed classes to the created jar file, removes the dependency from the pom.xml and changes the imports in the class files. Thus you work with the real classes at development time and then at build time the used classes are copied into the artifact and the development dependency is gone. Furthermore you can make all kinds of alterations to those classes (e.g. change package). We successfully use the maven-shade-plugin in MyFaces CODI to reuse functionaltiy between the JSF 1.2 and 2.0 modules. In addition, I have locally already used it to fix MYFACESTEST-21: I use it to get the AbstractAttributeMap and all its related classes from myfaces-impl to myfaces-test. And it really works like a calm. However I have to be honest, one thing currently has a bug: filters are only applied to the binary and not also to the sources jar (see http://jira.codehaus.org/browse/MSHADE-83), but I already provided a patch and a test case for it, so I guess it will be fixed very soon. So if there are no objects, I would like to introduce the maven-shade-plugin on myfaces-test at first, to show you guys how awesome it is. Afterwards, and of course if you all like it, I would really like to use it on several places in MyFaces. This would for example be the chance to get rid of the shared project once and for all. Opinions, suggestions and tomatoes are welcome! Regards, Jakob -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Use maven-shade-plugin to prevent duplicate code
I think you're right. The only real solution is a nice and clean Shared project. Otherwise the dependencies will become very tangled. /JK Sent from my iPad Op 26 jul. 2010 om 23:10 heeft Leonardo Uribe lu4...@gmail.com het volgende geschreven: Hi 2010/7/26 Jakob Korherr jakob.korh...@gmail.com This code is just some wrappers and it is not expected this will change in the future. So the question is why bother us in this case? In this case use maven-shade-plugin is not worth. Actually and quite frankly it really is worth it. It is very easy and if you understand it, it is even easier than just copy past, because you don't have to change packages manually. Furthermore, if you look at those classes, they have been refactored a couple of times from the very beginning (myfaces 1.1). In addition, there will surely be myfaces-test versions for JSF 2.1 (and 2.2, 3.0,...) and then you will always have to copy those classes and hope nothing will change. If you use the shade-plugin, you can throw your worries away! Myfaces-test uses myfaces-builder-plugin unpack goal to share code between versions, so the wrappers will be only on myfaces-test12. I'm worried about a possible circular dependency between myfaces core and myfaces test. The wrappers are on myfaces-core, but myfaces-test requires core wrappers to be build, but we require myfaces-test on core to run some tests, so which one should be compiled first? which one should be released first?. When you execute maven release plugin, it is necessary to change versions to the release ones, so do that will cause a lot of problems on release. regards, Leonardo Regards, Jakob 2010/7/26 Mark Struberg strub...@yahoo.de I think you are both right. I can understand that copying code is really ugly, but otoh Leos argument is also pretty strong. There is a solution for this. Cut off the shared parts and move it into an own module. This sounds easy but isn't always doable. But it might be worth a try. LieGrue, strub From: Jakob Korherr jakob.korh...@gmail.com To: MyFaces Development dev@myfaces.apache.org Sent: Mon, July 26, 2010 10:32:31 PM Subject: Re: Use maven-shade-plugin to prevent duplicate code Why would you like to have any duplicate code? This should not be anyone's target in my opinion... 2010/7/26 Leonardo Uribe lu4...@gmail.com Hi Yes, it is true, that myfaces-test is used for testing myfaces core, but in theory, myfaces-test should be used to test jsf stuff without rely on a specific jsf implementation. In this case I think (and it is my personal opinion) it is better to have some duplicate code and keep things simple. Use maven-shade-plugin to deal with shared code is another different history. regards, Leonardo Uribe 2010/7/26 Jakob Korherr jakob.korh...@gmail.com Actually this already is the case: MyFaces-test is used for testing MyFaces core. Regards, Jakob 2010/7/26 Rudy De Busscher rdebussc...@gmail.com Hi Jakob, So it was never the idea that MyFaces Test (and maybe the GSOC testing effort) will be used to supply the test infrastructure for MyFaces Core? In that case : MyFaces Core can supply code. Regards Rudy. On 26 July 2010 22:01, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Rudy, Yes we totally have to be careful with circular dependencies, but it should not be that big problem. Actually I think that the opposite is true. MyFaces core is the JSF implementation and MyFaces test provides the Mock classes for JSF, and for implementing these Mock classes it can reuse some functionality already present in MyFaces core (e.g. the real classes which should be mocked). IMO this is the way it should be. Regards, Jakob 2010/7/26 Rudy De Busscher rdebussc...@gmail.com Hi all, I agree, duplicated code has to be avoided and when the maven-shade-plugin can help, the better. but I think we have to define which project supplies code for which other project (so that we don't get a spaghetti (using the tomatoes ;) or get circular dependencies.). I know that MyFaces core exists much longer then MyFaces Test but I find it more logic that the MyFaces Test supplies code for the MyFaces Core project. my 2c. Regards Rudy On 26 July 2010 21:40, Matthias Wessendorf mat...@apache.org wrote: On Mon, Jul 26, 2010 at 9:30 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hehe, yeah I maybe forgot 10 many. I can provide a wiki page for the general idea and the approach used on myfaces-test. +1 Then everyone can adopt this idea and see how it works. great. I have that on my agenda as well, for Trinidad but a new release is more important, today... RIP _shared? :) -- yes! I thought so. Yes! :) Regards, Jakob 2010/7/26 Matthias Wessendorf mat...@apache.org On Mon,
[jira] Issue Comment Edited: (TOMAHAWK-1529) ConcurrentModificationException when using t:selectManyPickList and h:selectOneMenu
[
https://issues.apache.org/jira/browse/TOMAHAWK-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12891983#action_12891983
]
Jan-Kees van Andel edited comment on TOMAHAWK-1529 at 7/24/10 10:12 AM:
I'm pretty sure it has nothing to do with MyFaces...
I've seen issues like this one very often in the field. Most of the time the
cause was a direct remove action on the collection (not remove() on the
iterator) while iterating it.
You're passing in a Transformer into CollectionUtils.collect(), somewhere in
com.utmb.web.beans.searchController.getsrch1revvals. I can't see the line
number in the stack trace, but it should be there.
I'm very curious what this Transformer looks like. And of course a bit of
context, like the getsrch1revvals method...
was (Author: jankeesvanandel):
I'm pretty sure it has nothing to do with MyFaces...
I've seen issues like this one very often in the field. Most of the time the
cause was a direct remove action on the collection (not remove() on the
iterator) while iterating it.
You're passing in a Transformer into CollectionUtils.collect(), somewhere in
com.utmb.web.beans.searchController.getsrch1revvals. I can't see the line
number in the stack trace, but it should be there.
I'm very curious what this Transformer looks like.
ConcurrentModificationException when using t:selectManyPickList and
h:selectOneMenu
---
Key: TOMAHAWK-1529
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1529
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.10-SNAPSHOT
Environment: Solaris 5.8, Java HotSpot(TM) Server VM (build
1.5.0_05-b05, mixed mode)
Tomcat 6.0.26 running with Security Manager
MyFaces 1.1.7
Reporter: suresh t
I have a backend bean supporting jsf page. It has many components similar to
one shown below. where srch1vals is a ArrayList of SelectItem s
h:selectOneMenu id=search_search1
immediate=true value=#{searchController.vSrch1}
styleClass=selectOneMenu
f:selectItems
value=#{searchController.srch1vals} /
/h:selectOneMenu
There is one other components selectManyPickList that has value
set to srch1revvals. srch1revvals clones srch1vals in the Get accesor using
CollectionUtils.collect() method.
t:selectManyPicklist id=select_pick1
size=5 value=#{searchController.selectedPicks}
valueChangeListener=#{searchController.selectionChanged}
rendered=#{searchController.searchvalsResults}
f:selectItems
value=#{searchController.srch1revvals} /
/t:selectManyPicklist
I am getting occasional ConcurrentModificationException as follows.
Jul 6, 2010 4:35:38 PM org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.util.ConcurrentModificationException
at
java.util.AbstractList$Itr.checkForComodification(AbstractList.java:4
49)
at java.util.AbstractList$Itr.next(AbstractList.java:420)
at
org.apache.commons.collections.CollectionUtils.collect(CollectionUtil
s.java:631)
at
org.apache.commons.collections.CollectionUtils.collect(CollectionUtil
s.java:610)
at
org.apache.commons.collections.CollectionUtils.collect(CollectionUtil
s.java:575)
at com.utmb.web.beans.searchController.getsrch1revvals(Unknown Source)
at sun.reflect.GeneratedMethodAccessor780.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.myfaces.el.PropertyResolverImpl.getProperty(PropertyResolv
erImpl.java:459)
at
org.apache.myfaces.el.PropertyResolverImpl.getValue(PropertyResolverI
mpl.java:85)
at
org.apache.myfaces.el.ELParserHelper$MyPropertySuffix.evaluate(ELPars
erHelper.java:539)
at org.apache.commons.el.ComplexValue.evaluate(ComplexValue.java:145)
at
org.apache.myfaces.el.ValueBindingImpl.getValue(ValueBindingImpl.java
:386)
at
javax.faces.component.UISelectItems.getValue(UISelectItems.java:108)
at
org.apache.myfaces.shared_tomahawk.util.SelectItemsIterator.hasNext(S
electItemsIterator.java:127)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.internalGe
tSelectItemList(RendererUtils.java:462)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.getSelectI
temList(RendererUtils.java:448)
at
org.apache.myfaces.custom.picklist.HtmlPicklistRenderer.encodeEnd
[jira] Commented: (TOMAHAWK-1529) ConcurrentModificationException when using t:selectManyPickList and h:selectOneMenu
[
https://issues.apache.org/jira/browse/TOMAHAWK-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12891983#action_12891983
]
Jan-Kees van Andel commented on TOMAHAWK-1529:
--
I'm pretty sure it has nothing to do with MyFaces...
I've seen issues like this one very often in the field. Most of the time the
cause was a direct remove action on the collection (not remove() on the
iterator) while iterating it.
You're passing in a Transformer into CollectionUtils.collect(), somewhere in
com.utmb.web.beans.searchController.getsrch1revvals. I can't see the line
number in the stack trace, but it should be there.
I'm very curious what this Transformer looks like.
ConcurrentModificationException when using t:selectManyPickList and
h:selectOneMenu
---
Key: TOMAHAWK-1529
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1529
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.10-SNAPSHOT
Environment: Solaris 5.8, Java HotSpot(TM) Server VM (build
1.5.0_05-b05, mixed mode)
Tomcat 6.0.26 running with Security Manager
MyFaces 1.1.7
Reporter: suresh t
I have a backend bean supporting jsf page. It has many components similar to
one shown below. where srch1vals is a ArrayList of SelectItem s
h:selectOneMenu id=search_search1
immediate=true value=#{searchController.vSrch1}
styleClass=selectOneMenu
f:selectItems
value=#{searchController.srch1vals} /
/h:selectOneMenu
There is one other components selectManyPickList that has value
set to srch1revvals. srch1revvals clones srch1vals in the Get accesor using
CollectionUtils.collect() method.
t:selectManyPicklist id=select_pick1
size=5 value=#{searchController.selectedPicks}
valueChangeListener=#{searchController.selectionChanged}
rendered=#{searchController.searchvalsResults}
f:selectItems
value=#{searchController.srch1revvals} /
/t:selectManyPicklist
I am getting occasional ConcurrentModificationException as follows.
Jul 6, 2010 4:35:38 PM org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.util.ConcurrentModificationException
at
java.util.AbstractList$Itr.checkForComodification(AbstractList.java:4
49)
at java.util.AbstractList$Itr.next(AbstractList.java:420)
at
org.apache.commons.collections.CollectionUtils.collect(CollectionUtil
s.java:631)
at
org.apache.commons.collections.CollectionUtils.collect(CollectionUtil
s.java:610)
at
org.apache.commons.collections.CollectionUtils.collect(CollectionUtil
s.java:575)
at com.utmb.web.beans.searchController.getsrch1revvals(Unknown Source)
at sun.reflect.GeneratedMethodAccessor780.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.myfaces.el.PropertyResolverImpl.getProperty(PropertyResolv
erImpl.java:459)
at
org.apache.myfaces.el.PropertyResolverImpl.getValue(PropertyResolverI
mpl.java:85)
at
org.apache.myfaces.el.ELParserHelper$MyPropertySuffix.evaluate(ELPars
erHelper.java:539)
at org.apache.commons.el.ComplexValue.evaluate(ComplexValue.java:145)
at
org.apache.myfaces.el.ValueBindingImpl.getValue(ValueBindingImpl.java
:386)
at
javax.faces.component.UISelectItems.getValue(UISelectItems.java:108)
at
org.apache.myfaces.shared_tomahawk.util.SelectItemsIterator.hasNext(S
electItemsIterator.java:127)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.internalGe
tSelectItemList(RendererUtils.java:462)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.getSelectI
temList(RendererUtils.java:448)
at
org.apache.myfaces.custom.picklist.HtmlPicklistRenderer.encodeEnd(Htm
lPicklistRenderer.java:161)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:
775)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChil
d(RendererUtils.java:431)
at
org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlGridRendererBas
e.renderChildren(HtmlGridRendererBase.java:229)
at
org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlGridRendererBas
e.encodeEnd(HtmlGridRendererBase.java:101)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:
775
Re: [COMMUNITY] MyFaces += Ali Ok
Hey Ali, Congratulations, good luck with all your work and a very warm welcome! Regards, Jan-Kees 2010/7/22 Matthias Wessendorf mat...@apache.org The Myfaces PMC is proud to announce a new addition to our community. Please welcome Ali Ok as the newest MyFaces committer! Ali is an active member of the myfaces community, especially on MyFaces core and the HTML5 (gsoc) subproject. @Ali: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] make use of new apache.snapshots repo and apache-parent-7 features
+1 /JK 2010/7/20 Martin Marinschek mmarinsc...@apache.org +1, best regards, Martin On Tue, Jul 20, 2010 at 10:42 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/20 Mark Struberg strub...@yahoo.de +1 LieGrue, strub From: Leonardo Uribe lu4...@gmail.com To: MyFaces Development dev@myfaces.apache.org Sent: Tue, July 20, 2010 4:37:09 AM Subject: [VOTE] make use of new apache.snapshots repo and apache-parent-7 features Hi Some days ago, Mark Struberg suggest some changes to use the new apache.snapshots and apache-parent-7 features. Now that myfaces core 2.0.1 has been released, we can start with this process. By upgrading to apache-parent-7 and using the features provided there, we would gain significant benefits: *) Apache wide homogenic release tasks (at least for all projects using maven) *) _real_ source distribution packages and signing (ASF projects must be rebuildable from the source packages) *) Using Nexus for staging makes the release process a lot easier *) move to the new official apache.snapshots repository. The old one really makes a lot troubles under the hood... Some work has been done on MYFACES-2790 too. We need an official vote to do this change. So please vote +1 if you want this changes be included in myfaces master pom (note this changes will affect all myfaces projects, so the following release procedures could change). regards, Leonardo Uribe -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (MYFACES-2827) CCE if component values are not of type String
[ https://issues.apache.org/jira/browse/MYFACES-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12889834#action_12889834 ] Jan-Kees van Andel commented on MYFACES-2827: - I can't imagine the String assumption being wrong, so can you please add some info regarding how you got that Long into your component? Like: - Are you in a JEE6 container (with the new Unified EL)? - Are you using bean validation inside a composite component? - Do you have some code to show what you're doing? CCE if component values are not of type String -- Key: MYFACES-2827 URL: https://issues.apache.org/jira/browse/MYFACES-2827 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.1 Reporter: Mark Struberg Somehow I did get a Long into my component. This leads to the following Exception: java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.String at javax.faces.validator.BeanValidator.validate(BeanValidator.java:145) at javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:173) at javax.faces.component.UIInput.validateValue(UIInput.java:425) at javax.faces.component.UIInput.validate(UIInput.java:537) at javax.faces.component.UIInput.processValidators(UIInput.java:240) at javax.faces.component.UIData.process(UIData.java:1043) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2827) CCE if component values are not of type String
[
https://issues.apache.org/jira/browse/MYFACES-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12889863#action_12889863
]
Jan-Kees van Andel edited comment on MYFACES-2827 at 7/19/10 9:52 AM:
--
So, I guess the fix for this issue is to remove some code from BeanValidator.
The current code is:
final Class? valueBaseClass = base.getClass();
final String valueProperty = (String) reference.getProperty();
if (valueBaseClass == null || valueProperty == null)
{
return;
}
// Initialize Bean Validation.
final ValidatorFactory validatorFactory =
createValidatorFactory(context);
final javax.validation.Validator validator =
createValidator(validatorFactory);
final BeanDescriptor beanDescriptor =
validator.getConstraintsForClass(valueBaseClass);
if (!beanDescriptor.isBeanConstrained())
{
return;
}
But we can rewrite it to:
final Class? valueBaseClass = base.getClass();
if (valueBaseClass == null)
{
return;
}
// Initialize Bean Validation.
final ValidatorFactory validatorFactory =
createValidatorFactory(context);
final javax.validation.Validator validator =
createValidator(validatorFactory);
final BeanDescriptor beanDescriptor =
validator.getConstraintsForClass(valueBaseClass);
if (!beanDescriptor.isBeanConstrained())
{
return;
}
final String valueProperty = (String) reference.getProperty();
According to the spec, we should be able to remove the null-check on
valueProperty.
was (Author: jankeesvanandel):
So, I guess the fix for this issue is to add some extra code to
BeanValidator to check if the targeted object is a constrained object.
The current code is:
final Class? valueBaseClass = base.getClass();
final String valueProperty = (String) reference.getProperty();
if (valueBaseClass == null || valueProperty == null)
{
return;
}
// Initialize Bean Validation.
final ValidatorFactory validatorFactory =
createValidatorFactory(context);
final javax.validation.Validator validator =
createValidator(validatorFactory);
final BeanDescriptor beanDescriptor =
validator.getConstraintsForClass(valueBaseClass);
if (!beanDescriptor.isBeanConstrained())
{
return;
}
But we might be able to rewrite it to:
final Class? valueBaseClass = base.getClass();
if (valueBaseClass == null)
{
return;
}
// Initialize Bean Validation.
final ValidatorFactory validatorFactory =
createValidatorFactory(context);
final javax.validation.Validator validator =
createValidator(validatorFactory);
final BeanDescriptor beanDescriptor =
validator.getConstraintsForClass(valueBaseClass);
if (!beanDescriptor.isBeanConstrained())
{
return;
}
final String valueProperty = (String) reference.getProperty();
According to the spec, we should be able to remove the null-check on
valueProperty.
CCE if component values are not of type String
--
Key: MYFACES-2827
URL: https://issues.apache.org/jira/browse/MYFACES-2827
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.1
Reporter: Mark Struberg
Assignee: Jakob Korherr
Somehow I did get a Long into my component. This leads to the following
Exception:
java.lang.ClassCastException: java.lang.Long cannot be cast to
java.lang.String
at javax.faces.validator.BeanValidator.validate(BeanValidator.java:145)
at
javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:173)
at javax.faces.component.UIInput.validateValue(UIInput.java:425)
at javax.faces.component.UIInput.validate(UIInput.java:537)
at javax.faces.component.UIInput.processValidators(UIInput.java:240)
at javax.faces.component.UIData.process(UIData.java:1043)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2827) CCE if component values are not of type String
[
https://issues.apache.org/jira/browse/MYFACES-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12889863#action_12889863
]
Jan-Kees van Andel commented on MYFACES-2827:
-
So, I guess the fix for this issue is to add some extra code to BeanValidator
to check if the targeted object is a constrained object.
The current code is:
final Class? valueBaseClass = base.getClass();
final String valueProperty = (String) reference.getProperty();
if (valueBaseClass == null || valueProperty == null)
{
return;
}
// Initialize Bean Validation.
final ValidatorFactory validatorFactory =
createValidatorFactory(context);
final javax.validation.Validator validator =
createValidator(validatorFactory);
final BeanDescriptor beanDescriptor =
validator.getConstraintsForClass(valueBaseClass);
if (!beanDescriptor.isBeanConstrained())
{
return;
}
But we might be able to rewrite it to:
final Class? valueBaseClass = base.getClass();
if (valueBaseClass == null)
{
return;
}
// Initialize Bean Validation.
final ValidatorFactory validatorFactory =
createValidatorFactory(context);
final javax.validation.Validator validator =
createValidator(validatorFactory);
final BeanDescriptor beanDescriptor =
validator.getConstraintsForClass(valueBaseClass);
if (!beanDescriptor.isBeanConstrained())
{
return;
}
final String valueProperty = (String) reference.getProperty();
According to the spec, we should be able to remove the null-check on
valueProperty.
CCE if component values are not of type String
--
Key: MYFACES-2827
URL: https://issues.apache.org/jira/browse/MYFACES-2827
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.1
Reporter: Mark Struberg
Assignee: Jakob Korherr
Somehow I did get a Long into my component. This leads to the following
Exception:
java.lang.ClassCastException: java.lang.Long cannot be cast to
java.lang.String
at javax.faces.validator.BeanValidator.validate(BeanValidator.java:145)
at
javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:173)
at javax.faces.component.UIInput.validateValue(UIInput.java:425)
at javax.faces.component.UIInput.validate(UIInput.java:537)
at javax.faces.component.UIInput.processValidators(UIInput.java:240)
at javax.faces.component.UIData.process(UIData.java:1043)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2827) CCE if component values are not of type String
[ https://issues.apache.org/jira/browse/MYFACES-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12889870#action_12889870 ] Jan-Kees van Andel commented on MYFACES-2827: - I see I made a mistake. I guess that's what you get when looking at code through a web interface instead of an IDE... ;-) valueProperty must be a String because we need to pass it to the validateValue() method as a String. This is the JSR303 API, so we can't change this. For reference: http://download.oracle.com/docs/cd/E17410_01/javaee/6/api/javax/validation/Validator.html#validateValue(java.lang.Class, java.lang.String, java.lang.Object, java.lang.Class...) With regards ot Jakob's comment: check if reference.getProperty() is a String before doing the whole initialisation We can do this, but what do we do in this case? Just skip the call to validateValue()? I must say, it sounds reasonable on first thought, because we can't validate it anyway. Also, this situation should never occur in the case of a Bean, since the property name in a Bean is always a String. If it's not a String == it's not a Bean == we don't have to Bean-validate it... So +1, but I'm probably not seeing all consequences right now. I guess we should just fix it this way and see how it turns out in practice. Mark can do the regression testing. ;-) CCE if component values are not of type String -- Key: MYFACES-2827 URL: https://issues.apache.org/jira/browse/MYFACES-2827 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.1 Reporter: Mark Struberg Assignee: Jakob Korherr Attachments: MYFACES-2827.patch Somehow I did get a Long into my component. This leads to the following Exception: java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.String at javax.faces.validator.BeanValidator.validate(BeanValidator.java:145) at javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:173) at javax.faces.component.UIInput.validateValue(UIInput.java:425) at javax.faces.component.UIInput.validate(UIInput.java:537) at javax.faces.component.UIInput.processValidators(UIInput.java:240) at javax.faces.component.UIData.process(UIData.java:1043) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Mark issues for JSF 2.1
+1 on the first option. /JK 2010/7/8 Jakob Korherr jakob.korh...@gmail.com Hi guys, Since there are currently some issues in the JIRA, which we can't fix now, because they require a spec behavior change, but which should be fixed for JSF 2.1, I was thinking of some way to mark them. There are two options: 1) Simply create a 2.1.0 version and change the Affects Version/s of those issues to 2.1.0 2) Create a parent issue and convert all those issues to sub-tasks Frankly I would prefer the first option. What do you guys think? Regards, Jakob -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Created: (MYFACES-2784) NPE when I forget to add an interface to a composite component
NPE when I forget to add an interface to a composite component
--
Key: MYFACES-2784
URL: https://issues.apache.org/jira/browse/MYFACES-2784
Project: MyFaces Core
Issue Type: Bug
Reporter: Jan-Kees van Andel
When I write a composite component like the following:
?xml version=1.0 encoding=UTF-8?
ui:composition ...
div
h2Spaces/h2
ul
ui:repeat value=#{spacesBean.spaces} var=space
li
parleys:spaceLink space=#{space}
renderThumbnail=true renderLabel=true/
/li
/ui:repeat
/ul
/div
/ui:composition
I get a NPE on line 1101 in ApplicationImpl, because there is no component
metadata. Of course I made a mistake here, but a NPE isn't very helpful. :)
There is a SEVERE: Cannot found composite bean descriptor
UIComponent.BEANINFO_KEY in the logs, but it's swallowed by a huge stack trace.
I suggest to throw a descriptive exception instead of logging the message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: jsf-uncompressed.js in dev mode does not work out entirely
I've been out for a while, so it might be a stupid question. Do you serve the script via a servlet or is the file served directly? I ask because last year I did some performance tests for a client and having a servlet write a string is very expensive, compared to serving a static file. 100ms vs.10ms in my test environment. For this reason, I enhanced my maven build to package all script files into one big, compressed one which was put into the webroot and served directly, when in production mode. When in dev mode, I served the separate, raw files. This (among other things) made the application very fast. (I used a yuicompressor maven plugin) I didn't use jsf, but a custom framework, but I think this should be doable in myfaces too. Or maybe it already does? My 2 cents... Regards, Jan-Kees Sent from my HTC. On 25 Jun 2010 22:39, Leonardo Uribe lu4...@gmail.com wrote: Hi Werner I think we should activate it with a web config param. Debug using the real scripts in firefox is really useful. The idea could be provide a jsf-uncompressed.js file with all scripts as default on dev mode, but have a config param like org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS by default false. regards, Leonardo 2010/6/25 Werner Punz werner.p...@gmail.com Hello I have been doing some performance tuning for the last day on our jsf.js scripts. So ...
Re: [GSOC] HTML5 Prototype hx:inputFileUpload
+1. I'd suggest to use whatever gets the job done. It's about the RenderKit after all. Support for older Servlet specs can be added later... /JK 2010/5/31 Matthias Wessendorf mat...@apache.org for the server-side implementation of this, I am fine in just using Servlet 3.0's upload API. -Matthias On Mon, May 31, 2010 at 3:00 PM, Ali Ok al...@aliok.com.tr wrote: Hi all, Here is the wiki https://cwiki.apache.org/confluence/display/MYFACES/GSoC+HTML5+inputFileUpload+Prototype about hx:inputFileUpload. Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [ExtVal] Code coverage and suitable tools
I remember Apache having a Clover license. Not sure though. We might use it... It looks like the Maven plugin is ASL licensed. http://docs.atlassian.com/maven-clover2-plugin/2.3.1/license.html Regards, Jan-Kees 2010/5/26 Gerhard Petracek gerhard.petra...@gmail.com hi rudy, imo we should have such a tool for all sub-projects of myfaces. maybe as a part of the gsoc project [1]. (we can also add it after the gsoc project is finished. if there is an issue with the license, we have to add it as external add-on.) regards, gerhard [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg44776.html http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/5/26 Rudy De Busscher rdebussc...@gmail.com @All, To ensure maximum code coverage of the JUnit tests for the next release of ExtVal, I was looking at some code coverage tools. It seems that there aren't much which have a license compatible with Apache (Or am I missing something?). So I made a try with Cobertura (maven plugin has Apache Licence, cobertura itself is GNU General Public License) I created an Ant buildfile that copies all source codes from the various projects and then does a mvn cobertura:cobertura. It is only a try so you need to set the maven home directory on your computer in the build file (mine was D:/apache-maven-2.0.9, look for the mavenHome attribute) You can try it yourself by unzipping the attached file in the trunk of the svn checkout you have locally and run the ant command in the newly created cobertura directory. Comments about licensing and other experiences with this topic are off course very welcome. regards Rudy.
[jira] Commented: (MYFACES-2737) Cache FacesContext on UIComponentBase instances
[
https://issues.apache.org/jira/browse/MYFACES-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12872100#action_12872100
]
Jan-Kees van Andel commented on MYFACES-2737:
-
I agree with Martin. It looks good.
Normally I'm quite keen on concurrency bugs (like putting non-threadsafe
classes in the session), but this approach where you manually keep the
FacesContext instance request scoped, looks safe.
How many FacesContext.getCurrentInstance calls do you expect to save by this
approach?
Cache FacesContext on UIComponentBase instances
---
Key: MYFACES-2737
URL: https://issues.apache.org/jira/browse/MYFACES-2737
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Affects Versions: 2.0.0
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Attachments: MYFACES-2737-1.patch
Right now, the implementation of UIComponentBase.getFacesContext() is this:
@Override
protected FacesContext getFacesContext()
{
return FacesContext.getCurrentInstance();
}
I think it is possible to create a variable like this:
private transient FacesContext _facesContext;
and change the current implementation to:
void setCachedFacesContext(FacesContext facesContext)
{
_facesContext = facesContext;
}
@Override
protected FacesContext getFacesContext()
{
if (_facesContext == null)
{
return FacesContext.getCurrentInstance();
}
else
{
return _facesContext;
}
}
Then we do this on methods like processXXX, encodeXXX (not on encodeAll),
visitTree and invokeOnComponent:
@Override
public void processDecodes(FacesContext context)
{
try
{
setCachedFacesContext(context);
/*.. do what is required */
}
finally
{
popComponentFromEL(context);
setCachedFacesContext(null);
}
In few words, set and release temporally the variable while those operations
are executed. This change will reduce the amount of calls to
FacesContext.getCurrentInstance() without side effects, because we are
caching only on safe places and enclosing everything in a try finally block.
If no objections I'll commit this code soon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Extended Debug Tree - MYFACES-2676
Sounds plausible, we already do the same thing with the ExternalContexts
class.
It's blazing fast, but the question is: Are we allowed to and do we want to
cache the instance?
If the spec doesn't dictate otherwise, I'm in favor of caching it.
Another idea is to cache it in the ServletContext. It's not as fast as a
static final field, but still pretty fast and can be inspected and modified
through appserver tooling.
Regards,
Jan-Kees
2010/5/19 Gerhard Petracek gerhard.petra...@gmail.com
we don't have to cache the faces-context.
we can use e.g. an interface with a static final field.
usage (example):
if(Boolean.TRUE.equals(InternalProjectStage.IS_DEV_MODE))
{
//...
}
- there is just one evaluation.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/5/19 Leonardo Uribe lu4...@gmail.com
Hi
The problem in this case is the only place we can store this information
is the component instance itself. So, at least there is one lookup per
component.
If we try to cache facesContext, unfortunately there is not safe way to
clean this reference (portlet case), so there is a risk of use old instances
of this object in this case.
regards,
Leonardo Uribe
2010/5/19 Gerhard Petracek gerhard.petra...@gmail.com
hi,
as long as we don't want to change the project stage dynamically, we can
just store e.g. a marker as static information.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/5/19 Jakob Korherr jakob.korh...@gmail.com
Hi Martin,
Indeed, we have to call FacesContext.getCurrentInstance() everytime.
So I guess it will be better to remove the code from UIInput!
Regards,
Jakob
2010/5/19 Martin Marinschek mmarinsc...@apache.org
Hi Jakob,
The problem with this is that the code on UIInput checks the
ProjectStage
everytime setSubmittedValue() or setValue() are called, which is very
often
and could make MyFaces a bit slower, I guess. If we remove this code
on
UIInput, the debug output will stay mostly the same except for the
call
stack, because this will be gone.
The question now is if we should leave it the way it currently is
(with the
code on UIInput and the possibility to display the call stack) or if
we
should remove the code from UIInput (which means no slowdown on
setSubmittedValue() and setValue() but loosing the call stack). What
do you
guys think? Any opinions/objections?
for me it is a question how fast this getProjectStage() derivation is.
If that means to call FacesContext.getCurrentInstance() all the time,
the impact is considerable (thread-local resolution). In this case it
might be better to not have this information...
Martin
Regards,
Jakob
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
[jira] Commented: (MYFACES-2714) Include uncompressed jsf.js file and use it when development mode is used
[ https://issues.apache.org/jira/browse/MYFACES-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12868098#action_12868098 ] Jan-Kees van Andel commented on MYFACES-2714: - For archiving, this is the email conversation: -- Jan-Kees van Andel aan MyFaces details weergeven 15 mei (2 dagen geleden) The plan sounds good, but let's not forget the performance penalty of loading multiple javascript files when in production mode. No objections for loading multiple files in development mode. Maybe, we should even (from a security perspective) completely deny access to the debug versions of the scripts when in production mode. My 2 cents... Regards, Jan-Kees -- Michael Concini aan MyFaces details weergeven 15 mei (2 dagen geleden) I think Jan-Kees has a good point on denying access to the debug versions when in production mode. At least by default it might be good to deny access. -- Definitely +1 from my side regarding this, debug versions should definitely be for development mode only. Werner -- Hi I have attached a patch (MYFACES-2714-3.patch) that do what was suggested by Werner, including do not allow retrieve the javascript sources on production. Please, take a look at this one and if no objections, I'll commit the code. regards, Leonardo Uribe Include uncompressed jsf.js file and use it when development mode is used - Key: MYFACES-2714 URL: https://issues.apache.org/jira/browse/MYFACES-2714 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.0 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: MYFACES-2714-2.patch, MYFACES-2714-3.patch Reading some blogs about jsf 2.0, I notice mojarra include an uncompressed jsf.js file and use it when development mode is used. It is difficult to debug myfaces javascript for users and I think it is worth to do it too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2714) Include uncompressed jsf.js file and use it when development mode is used
[ https://issues.apache.org/jira/browse/MYFACES-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12868108#action_12868108 ] Jan-Kees van Andel commented on MYFACES-2714: - Hi Leonardo, I don't see any issues, except two small ones: 1 The SNAPSHOT dependency for the JS plugin 2 The line: log.fine(Cannot evaluate EL expression +convertToExpression(expressionList)+ in resource + getLibraryName()+:+getResourceName()); looks like it swallows EL errors. I see that an event is published, but it looks like some information is lost in the event. Log.error might be more appropriate. But, I must admit, I have only looked at the code, I haven't tested it in a running application. I'm +1 on committing this patch. Include uncompressed jsf.js file and use it when development mode is used - Key: MYFACES-2714 URL: https://issues.apache.org/jira/browse/MYFACES-2714 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.0 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: MYFACES-2714-2.patch, MYFACES-2714-3.patch Reading some blogs about jsf 2.0, I notice mojarra include an uncompressed jsf.js file and use it when development mode is used. It is difficult to debug myfaces javascript for users and I think it is worth to do it too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (MYFACES-2714) Include uncompressed jsf.js file and use it when development mode is used
The plan sounds good, but let's not forget the performance penalty of loading multiple javascript files when in production mode. No objections for loading multiple files in development mode. Maybe, we should even (from a security perspective) completely deny access to the debug versions of the scripts when in production mode. My 2 cents... Regards, Jan-Kees 2010/5/15 Werner Punz (JIRA) dev@myfaces.apache.org [ https://issues.apache.org/jira/browse/MYFACES-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12867846#action_12867846] Werner Punz commented on MYFACES-2714: -- Actually lets do it step by step, first get Leos big combined file as debug file in, once I have ext-scripting 1.0 out (which is currently the next todo onm y list) we can work on the other more fine grained solution, after all, there is no rush to do this. If anyone wants to start to work on this, feel free, after all this is opensource code, everyone can lay their hands on it. Cheers Werner Include uncompressed jsf.js file and use it when development mode is used - Key: MYFACES-2714 URL: https://issues.apache.org/jira/browse/MYFACES-2714 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.0 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: MYFACES-2714-2.patch Reading some blogs about jsf 2.0, I notice mojarra include an uncompressed jsf.js file and use it when development mode is used. It is difficult to debug myfaces javascript for users and I think it is worth to do it too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] become shared 4.0.x branch trunk
+1 /JK 2010/5/7 Bruno Aranda brunoara...@gmail.com +1 On 7 May 2010 15:46, Leonardo Uribe lu4...@gmail.com wrote: 2010/5/7 Jakob Korherr jakob.korh...@gmail.com +1 It will make things easier! However we have to be careful to not forget to change _every_ reference to shared trunk and 4.0.x_trunk (e.g. from orchestra, portlet-bridge, implee6,...). There are no svn references to shared in any different place (svn references are different to maven ones), so we are ok. Regards, Jakob 2010/5/7 Mark Struberg strub...@yahoo.de +1 I think this will be easier in the end. I did fall into this hole the 2nd time already ;) txs and LieGrue, strub --- Leonardo Uribe lu4...@gmail.com schrieb am Fr, 7.5.2010: Von: Leonardo Uribe lu4...@gmail.com Betreff: Re: [VOTE] become shared 4.0.x branch trunk An: MyFaces Development dev@myfaces.apache.org Datum: Freitag, 7. Mai, 2010 16:08 Uhr +1 2010/5/7 Leonardo Uribe lu4...@gmail.com Hi Right now, shared trunk points to jsf 1.1 version (in this case 2.0.x) and since most of the development is on JSF 2.0 branch we should change so the 4.0.x branch will be trunk. Also, the link on current module points to trunk and in this case jsf 1.1 branch. The change requires first a vote to be done. Please vote +1 if you want to make shared 4.0.x branch trunk, and create a current11 module so you can build jsf 1.1 sources like current12. regards, Leonardo Uribe [1] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Created: (EXTSCRIPT-130) JSF 2.0 composite components are not picked up
JSF 2.0 composite components are not picked up -- Key: EXTSCRIPT-130 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-130 Project: MyFaces Extensions Scripting Issue Type: Bug Components: MyFaces 2.0 Extension Affects Versions: Beta-1 Environment: Windows Vista x64, Java 1.6.0_14, Maven Jetty Plugin Reporter: Jan-Kees van Andel Assignee: Werner Punz When I change (or add) a composite component, the change is not picked up. After a server restart the file is loaded. Normal Facelet files are picked up correctly, also included files, like the page template. I have configured all entries in web.xml and both JSF and Facelets are in development mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Ext-Scripting Final Logo
All changes are in here: http://wiki.apache.org/myfaces/Extensions/Scripting/Setup?action=diffrev2=24rev1=19 /JK 2010/4/20 Werner Punz werner.p...@gmail.com Am 20.04.10 19:37, schrieb Jan-Kees van Andel: I used the docs last Sunday to get going, but I of course already knew a thing or two about the framework. Besides some small things that I have already fixed on the Wiki, I think the docs are good. But again, the opinion of someone who hasn't used Ext-Scripting before would be useful. Ok before I have to dig through the wiki history, since the pages are mostly legacy now (I have not yet deleted them) do you know what you fixed so that I can add it to the docs? (PS feel free to fix it directly in the docs, since you have committer rights anway) Werner Oh, btw. nice logo! /JK 2010/4/20 Werner Punz werner.p...@gmail.com mailto: werner.p...@gmail.com Btw. guys I would need a favor, can anyone have a quick look over the documentation, if the information is enough to get people started? I am very nitpicky regarding having good documentation, but I am sort of blind regarding my own stuff. Werner Am 20.04.10 17:04, schrieb Bruno Aranda: Great job! I like it, Cheers, Bruno On 20 April 2010 16:01, Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com wrote: It looks _very_ great and, of course, totally fits into the myfaces design. Regards, Jakob 2010/4/20 Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com mailto:werner.p...@gmail.com mailto:werner.p...@gmail.com Hello everyone, Adonis (who designed the other Logos) has given me a final logo it looks now like following: http://people.apache.org/~werpu/ext-script-site/images/extscriptlogo.png http://people.apache.org/%7Ewerpu/ext-script-site/images/extscriptlogo.png respectively in conjunction with the documentation: http://people.apache.org/~werpu/ext-script-site/ http://people.apache.org/%7Ewerpu/ext-script-site/ I think the logo is more than perfect and fits into our design. Werner -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Ext-Scripting Final Logo
I used the docs last Sunday to get going, but I of course already knew a thing or two about the framework. Besides some small things that I have already fixed on the Wiki, I think the docs are good. But again, the opinion of someone who hasn't used Ext-Scripting before would be useful. Oh, btw. nice logo! /JK 2010/4/20 Werner Punz werner.p...@gmail.com Btw. guys I would need a favor, can anyone have a quick look over the documentation, if the information is enough to get people started? I am very nitpicky regarding having good documentation, but I am sort of blind regarding my own stuff. Werner Am 20.04.10 17:04, schrieb Bruno Aranda: Great job! I like it, Cheers, Bruno On 20 April 2010 16:01, Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com wrote: It looks _very_ great and, of course, totally fits into the myfaces design. Regards, Jakob 2010/4/20 Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com Hello everyone, Adonis (who designed the other Logos) has given me a final logo it looks now like following: http://people.apache.org/~werpu/ext-script-site/images/extscriptlogo.png http://people.apache.org/%7Ewerpu/ext-script-site/images/extscriptlogo.png respectively in conjunction with the documentation: http://people.apache.org/~werpu/ext-script-site/ http://people.apache.org/%7Ewerpu/ext-script-site/ I think the logo is more than perfect and fits into our design. Werner -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Commented: (EXTSCRIPT-116) NPE during reload in Maven Jetty Plugin
[
https://issues.apache.org/jira/browse/EXTSCRIPT-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858484#action_12858484
]
Jan-Kees van Andel commented on EXTSCRIPT-116:
--
I might do that. Also a good way to start learning the internals of ExtScript.
But, for now, I'm very happy.
Good enough for an 1.0 release IMHO.
NPE during reload in Maven Jetty Plugin
---
Key: EXTSCRIPT-116
URL: https://issues.apache.org/jira/browse/EXTSCRIPT-116
Project: MyFaces Extensions Scripting
Issue Type: Bug
Components: Core
Affects Versions: 1.0-Beta-2
Reporter: Jan-Kees van Andel
Assignee: Werner Punz
Fix For: 1.0-Beta-2
I'm still trying to find out the best way to use the Maven Jetty Plugin, so I
might be doing something wrong on this side here.
Nevertheless, when I run mvn package on my project while the server is
running (to update dependent libraries to the server), I get the following
error:
[INFO] Restarting webapp
18-apr-2010 21:24:02 org.apache.myfaces.webapp.StartupServletContextListener
dispatchInitializationEvent
INFO: Processing
plugin:org.apache.myfaces.extensions.scripting.servlet.StartupServletContextPluginChainLoader
18-apr-2010 21:24:02 org.apache.myfaces.webapp.StartupServletContextListener
dispatchInitializationEvent
INFO: Processing MyFaces plugins done
18-apr-2010 21:24:02
org.apache.myfaces.extensions.scripting.core.util.WeavingContext getWeaver
WARNING: [EXT-SCRIPTING] Scripting Weaver is not set. Disabling script
reloading subsystem. Make sure you have the scripting servlet filter enabled
in your web.xml
2010-04-18 21:24:02.920::WARN: failed
org.mortbay.jetty.plugin.jetty6pluginwebappcont...@63f5af{/html5parleys,D:\dev\work\idea9\parleys\web-html5\target\parleys-frontend-html5-0.1-SNAPSHOT}
java.lang.NullPointerException
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.weaveDelegate(FacesContextProxy.java:54)
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.init(FacesContextProxy.java:140)
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.factories.ScriptingFacesContextFactory.getFacesContext(ScriptingFacesContextFactory.java:52)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:195)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.destroyFaces(AbstractFacesInitializer.java:204)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextDestroyed(StartupServletContextListener.java:215)
at
org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:599)
at org.mortbay.jetty.webapp.WebAppContext.doStop(WebAppContext.java:498)
at
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStop(Jetty6PluginWebAppContext.java:132)
at
org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:78)
at
org.mortbay.jetty.plugin.Jetty6RunWarExploded.restartWebApp(Jetty6RunWarExploded.java:118)
at
org.mortbay.jetty.plugin.Jetty6RunWarExploded$1.filesChanged(Jetty6RunWarExploded.java:100)
at org.mortbay.util.Scanner.reportBulkChanges(Scanner.java:486)
at org.mortbay.util.Scanner.reportDifferences(Scanner.java:352)
at org.mortbay.util.Scanner.scan(Scanner.java:280)
at org.mortbay.util.Scanner$1.run(Scanner.java:232)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
[ERROR] Error reconfiguring/restarting webapp after change in watched files
java.lang.NullPointerException
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.weaveDelegate(FacesContextProxy.java:54)
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.init(FacesContextProxy.java:140)
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.factories.ScriptingFacesContextFactory.getFacesContext(ScriptingFacesContextFactory.java:52)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:195)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.destroyFaces(AbstractFacesInitializer.java:204)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextDestroyed(StartupServletContextListener.java:215)
at
org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:599)
at org.mortbay.jetty.webapp.WebAppContext.doStop(WebAppContext.java:498)
at
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStop(Jetty6PluginWebAppContext.java:132
[jira] Created: (EXTSCRIPT-114) ExtScript fails to start when Groovy is not available
ExtScript fails to start when Groovy is not available - Key: EXTSCRIPT-114 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-114 Project: MyFaces Extensions Scripting Issue Type: Bug Components: Core Affects Versions: 1.0-Beta-2 Environment: Vista x64, Java 6, jetty-6.1.14 Reporter: Jan-Kees van Andel Assignee: Werner Punz When I don't add the groovy binaries to my Maven dependencies, and I run my app with maven-jetty-plugin, I get the following exception: 2010-04-18 14:46:55.710::WARN: Error starting handlers java.lang.NoClassDefFoundError: groovy/lang/GroovyObject at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) ... I don't want to use Groovy, but I do need the Groovy binaries for ExtScript to start. Maybe this Exception should be used to automatically disable Groovy support? Anyway, I personally don't mind to add Groovy, but I think it should be fixed before the 1.0 release b/c I think other users do mind. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-2663) NPE in UIParameter when value resolves to null
NPE in UIParameter when value resolves to null
--
Key: MYFACES-2663
URL: https://issues.apache.org/jira/browse/MYFACES-2663
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.1-SNAPSHOT
Reporter: Jan-Kees van Andel
When I have a null value in an f:param value=#{expr.that.evaluates.to.null}
/ tag, I get the following NPE when rendering:
java.lang.NullPointerException
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.getOutcomeTargetLinkHref(HtmlRendererUtils.java:1883)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlLinkRendererBase.renderOutcomeLinkStart(HtmlLinkRendererBase.java:742)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlLinkRendererBase.encodeBegin(HtmlLinkRendererBase.java:123)
at
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:430)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:605)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:614)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:614)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1117)
at
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:231)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:122)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:207)
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.render(LifefcycleProxy.java:74)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
I don't know what the spec says or what Mojarra does, but I think we should at
least do better than a NPE, for example appending an empty string to the
parameter list...
Any ideas?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (EXTSCRIPT-115) Better logging when developer specifies a non existent source directory
Better logging when developer specifies a non existent source directory --- Key: EXTSCRIPT-115 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-115 Project: MyFaces Extensions Scripting Issue Type: Bug Components: Core Affects Versions: 1.0-Beta-2 Reporter: Jan-Kees van Andel Assignee: Werner Punz When I make a typo in a source directory, like: D:/dev/work/idea9/parleys/web-html5/src/main/jav (notice the missing 'a' at the end) I don't get a message suggesting I made an error, but ExtScript fails silently by not reloading the classes in this directory. There is a javac message in the log: INFO: [EXT-SCRITPING] starting class dependency scan 18-apr-2010 16:53:24 org.apache.myfaces.extensions.scripting.loaders.java.jsr199.JSR199Compiler compile INFO: [EXT-SCRIPTING] Doing a full recompile javacTask: no source files Usage: javacTask options source files use -help for a list of possible options But it's easy to miss it because MyFaces and other frameworks also emit a lot of logging. Something heavier (ERROR level or maybe an initializer exception) might be better, so the user won't get confused/angry. I think such a check is even more appropriate because file paths in Java are always error-prone (I always make mistakes with paths)... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (EXTSCRIPT-116) NPE during reload in Maven Jetty Plugin
NPE during reload in Maven Jetty Plugin
---
Key: EXTSCRIPT-116
URL: https://issues.apache.org/jira/browse/EXTSCRIPT-116
Project: MyFaces Extensions Scripting
Issue Type: Bug
Components: Core
Affects Versions: 1.0-Beta-2
Reporter: Jan-Kees van Andel
Assignee: Werner Punz
I'm still trying to find out the best way to use the Maven Jetty Plugin, so I
might be doing something wrong on this side here.
Nevertheless, when I run mvn package on my project while the server is running
(to update dependent libraries to the server), I get the following error:
[INFO] Restarting webapp
18-apr-2010 21:24:02 org.apache.myfaces.webapp.StartupServletContextListener
dispatchInitializationEvent
INFO: Processing
plugin:org.apache.myfaces.extensions.scripting.servlet.StartupServletContextPluginChainLoader
18-apr-2010 21:24:02 org.apache.myfaces.webapp.StartupServletContextListener
dispatchInitializationEvent
INFO: Processing MyFaces plugins done
18-apr-2010 21:24:02
org.apache.myfaces.extensions.scripting.core.util.WeavingContext getWeaver
WARNING: [EXT-SCRIPTING] Scripting Weaver is not set. Disabling script
reloading subsystem. Make sure you have the scripting servlet filter enabled in
your web.xml
2010-04-18 21:24:02.920::WARN: failed
org.mortbay.jetty.plugin.jetty6pluginwebappcont...@63f5af{/html5parleys,D:\dev\work\idea9\parleys\web-html5\target\parleys-frontend-html5-0.1-SNAPSHOT}
java.lang.NullPointerException
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.weaveDelegate(FacesContextProxy.java:54)
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.init(FacesContextProxy.java:140)
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.factories.ScriptingFacesContextFactory.getFacesContext(ScriptingFacesContextFactory.java:52)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:195)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.destroyFaces(AbstractFacesInitializer.java:204)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextDestroyed(StartupServletContextListener.java:215)
at
org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:599)
at org.mortbay.jetty.webapp.WebAppContext.doStop(WebAppContext.java:498)
at
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStop(Jetty6PluginWebAppContext.java:132)
at
org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:78)
at
org.mortbay.jetty.plugin.Jetty6RunWarExploded.restartWebApp(Jetty6RunWarExploded.java:118)
at
org.mortbay.jetty.plugin.Jetty6RunWarExploded$1.filesChanged(Jetty6RunWarExploded.java:100)
at org.mortbay.util.Scanner.reportBulkChanges(Scanner.java:486)
at org.mortbay.util.Scanner.reportDifferences(Scanner.java:352)
at org.mortbay.util.Scanner.scan(Scanner.java:280)
at org.mortbay.util.Scanner$1.run(Scanner.java:232)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
[ERROR] Error reconfiguring/restarting webapp after change in watched files
java.lang.NullPointerException
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.weaveDelegate(FacesContextProxy.java:54)
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.init(FacesContextProxy.java:140)
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.factories.ScriptingFacesContextFactory.getFacesContext(ScriptingFacesContextFactory.java:52)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:195)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.destroyFaces(AbstractFacesInitializer.java:204)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextDestroyed(StartupServletContextListener.java:215)
at
org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:599)
at org.mortbay.jetty.webapp.WebAppContext.doStop(WebAppContext.java:498)
at
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStop(Jetty6PluginWebAppContext.java:132)
at
org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:78)
at
org.mortbay.jetty.plugin.Jetty6RunWarExploded.restartWebApp(Jetty6RunWarExploded.java:118)
at
org.mortbay.jetty.plugin.Jetty6RunWarExploded$1.filesChanged(Jetty6RunWarExploded.java:100)
at org.mortbay.util.Scanner.reportBulkChanges(Scanner.java:486)
at org.mortbay.util.Scanner.reportDifferences(Scanner.java:352)
at org.mortbay.util.Scanner.scan(Scanner.java
Re: Ext Scripting Quo Vadis
I have to admit that I haven't used it recently, but my latest experiences with Ext Scripting were very positive. So I think it's a good time to start with a release, also considering the GSoC and branching issues. If I can find some time this week, I'll try to do some testing... Regards, Jan-Kees 2010/4/15 Werner Punz werner.p...@gmail.com Hello I just wanted to know a general opinion here, Ext-Scripting has been in beta stage for a while (while we have tagged one none of us had time to make a full blown release given all our other tasks at hand) But I personally think, since the thing at least for me already works really well (used it again this week for prototyping some JSF2 components at a customer) and I did a lot of bugfixing, that I do not want to do another beta release but want to go for a full blown final release with a bugfix release shortly thereafter. The reason is: a) I personally think it is ready, I want to do some additional testing and fixing as time permits next week, as time permits, but I think it is ok to release it b) I want people start using it, which means they will touch it with a final release c) It would be good to get the release out very close to myfaces sort of as a pushing extra for MyFaces 2.0 (my original timeframe was one month after the myfaces release, it could be shorter now) d) I want to start the work on 1.1 so that we get the infrastructure in place to get spring an and have Bernhard starting on his GSOC project which will bring CDI integration, but that means some refactorings which I cannot do as long as I am in beta here (and I do not want to branch again( I personally think that 1.0 is more or less a proof of concept and foundation, and a valuable asset for component writers (thats probably where 1.0 will be used most), once we have Spring and CDI working people really have something on their hands they can work with. So what is the general opinion on this? Werner
Re: Unit test failing? (was: Re: [VOTE] release for myfaces core 2.0.0)
I just runned the build on Windows Vista x64: D:\dev\work\myfaces2\core_2_0_0mvn --version Maven version: 2.0.10 Java version: 1.6.0_14 OS name: windows vista version: 6.0 arch: amd64 Family: windows The tests worked fine. @Matthias: Can you see which test method is causing the issue and which assertion fails (or which exception is thrown)? /JK 2010/4/15 Matthias Wessendorf mat...@apache.org that's funny :-) What JDK ? 1.5 ? I am on 1.6.x = mat...@woody:~/work/source/Apache/myfaces/trunk$ mvn -v Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_13 Java home: /java/jdk1.6.0_13/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.31-19-generic arch: i386 Family: unix On Thu, Apr 15, 2010 at 8:55 AM, Leonardo Uribe lu4...@gmail.com wrote: Hi In my machine works fine. I compiled sources on both Linux and Windows. regards, Leonardo Uribe 2010/4/15 Matthias Wessendorf mat...@apache.org These two revisions cause the problem: http://svn.apache.org/viewvc?view=revisionrevision=933814 http://svn.apache.org/viewvc?view=revisionrevision=933812 On Thu, Apr 15, 2010 at 7:43 AM, Matthias Wessendorf mat...@apache.org wrote: Yesterday I mentioned the same, on trunk I am on Linux, Werner is on OS X. Jakob/Leo: r u windoze ? Thx, Matthias PS: I changed the subject to not hijack the vote ;-) On Thu, Apr 15, 2010 at 7:37 AM, Werner Punz werner.p...@gmail.com wrote: Before I am giving my vote here, there is still a unit test failure ... Am 15.04.10 06:39, schrieb Matthias Wessendorf: +1 Thanks for running this Sent from my iPod. On 15.04.2010, at 03:48, Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com wrote: +1 2010/4/14 Leonardo Uribe mailto:lu4...@gmail.com lu4...@gmail.com mailto:lu4...@gmail.com Hi, I was running the needed tasks to get the 2.0.0 release of Apache MyFaces core out. Minor fixes were done since the latest proposed artifacts (MYFACES-2658, MYFACES-2659 and MYFACES-2660), so we can continue with the vote. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.1 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.0 [1] 3. Maven artifact group org.apache.myfaces.test v1.0.0-beta-3 [1] The artifacts are deployed to my private Apache account ([1] and [3] for binary and source packages). The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] http://people.apache.org/%7Elu4242/myfaces200 http://people.apache.org/~lu4242/myfaces200http://people.apache.org/%7Elu4242/myfaces200 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/%7Elu4242/myfaces200binsrc http://people.apache.org/~lu4242/myfaces200binsrchttp://people.apache.org/%7Elu4242/myfaces200binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314890 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314890 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314890 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Unit test failing? (was: Re: [VOTE] release for myfaces core 2.0.0)
Hrm, maybe an encoding issue? Also ran the tests from IntelliJ. Worked fine too... /JK 2010/4/15 Werner Punz werner.p...@gmail.com Ok here is some additional information: testsuite failures=2 time=0.037 errors=0 skipped=0 tests=6 name=org.apache.myfaces.renderkit.html.HtmlTextRendererTest properties property name=java.runtime.name value=Java(TM) SE Runtime Environment/ property name=sun.boot.library.path value=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Libraries/ property name=java.vm.version value=14.3-b01-101/ testcase time=0.006 name=testClientBehaviorUserCodeJavaScriptEscaping failure type=junit.framework.AssertionFailedErrorjunit.framework.AssertionFailedError at org.apache.myfaces.renderkit.html.HtmlTextRendererTest.testClientBehaviorUserCodeJavaScriptEscaping(HtmlTextRendererTest.java:215) /failure /testcase testcase time=0.005 name=testClientBehaviorUserCodeJavaScriptDoubleEscaping failure type=junit.framework.AssertionFailedErrorjunit.framework.AssertionFailedError at org.apache.myfaces.renderkit.html.HtmlTextRendererTest.testClientBehaviorUserCodeJavaScriptDoubleEscaping(HtmlTextRendererTest.java:237) /failure Am 15.04.10 09:22, schrieb Jan-Kees van Andel: I just runned the build on Windows Vista x64: D:\dev\work\myfaces2\core_2_0_0mvn --version Maven version: 2.0.10 Java version: 1.6.0_14 OS name: windows vista version: 6.0 arch: amd64 Family: windows The tests worked fine. @Matthias: Can you see which test method is causing the issue and which assertion fails (or which exception is thrown)? /JK 2010/4/15 Matthias Wessendorf mat...@apache.org mailto: mat...@apache.org that's funny :-) What JDK ? 1.5 ? I am on 1.6.x = mat...@woody:~/work/source/Apache/myfaces/trunk$ mvn -v Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_13 Java home: /java/jdk1.6.0_13/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.31-19-generic arch: i386 Family: unix On Thu, Apr 15, 2010 at 8:55 AM, Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com wrote: Hi In my machine works fine. I compiled sources on both Linux and Windows. regards, Leonardo Uribe 2010/4/15 Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org These two revisions cause the problem: http://svn.apache.org/viewvc?view=revisionrevision=933814 http://svn.apache.org/viewvc?view=revisionrevision=933814 http://svn.apache.org/viewvc?view=revisionrevision=933812 http://svn.apache.org/viewvc?view=revisionrevision=933812 On Thu, Apr 15, 2010 at 7:43 AM, Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org wrote: Yesterday I mentioned the same, on trunk I am on Linux, Werner is on OS X. Jakob/Leo: r u windoze ? Thx, Matthias PS: I changed the subject to not hijack the vote ;-) On Thu, Apr 15, 2010 at 7:37 AM, Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com wrote: Before I am giving my vote here, there is still a unit test failure ... Am 15.04.10 06:39, schrieb Matthias Wessendorf: +1 Thanks for running this Sent from my iPod. On 15.04.2010, at 03:48, Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com mailto:lu4...@gmail.com mailto:lu4...@gmail.com wrote: +1 2010/4/14 Leonardo Uribe mailto:lu4...@gmail.com mailto:lu4...@gmail.comlu4...@gmail.com mailto:lu4...@gmail.com mailto:lu4...@gmail.com mailto:lu4...@gmail.com Hi, I was running the needed tasks to get the 2.0.0 release of Apache MyFaces core out. Minor fixes were done since the latest proposed artifacts (MYFACES-2658, MYFACES-2659 and MYFACES-2660), so we can continue with the vote. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.1 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.0 [1] 3. Maven artifact group org.apache.myfaces.test v1.0.0-beta-3 [1] The artifacts are deployed to my private Apache account ([1] and [3] for binary and source packages). The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three
Re: impl build fails - Re: [VOTE] release for myfaces core 2.0.0
I encountered the same error on trunk. You need to change the shared-impl version property to 4.0.1 and then it should work. Regards, Jan-Kees 2010/4/15 Ganesh gan...@j4fry.org Sorry for the inconvenience, for me impl build fails on myfaces/current20 (last tried 10 days ago, worked then). It's propably an oversight on my side, but I would have liked to a quick retest with dojofaces for 2.0.0 ... any ideas? [INFO] Compiling 74 source files to C:\projects\MyFaces_current20\core\impl\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\projects\MyFaces_current20\core\impl\src\main\java\org\apache\myfaces\context\servlet\ServletExternalContextImpl.java:[56,51] package org.apache.myfaces.shared_impl.context.flash does not exist C:\projects\MyFaces_current20\core\impl\src\main\java\org\apache\myfaces\context\ExceptionHandlerFactoryImpl.java:[24,45] cannot find symbol symbol : class ExceptionHandlerImpl location: package org.apache.myfaces.shared_impl.context C:\projects\MyFaces_current20\core\impl\src\main\java\org\apache\myfaces\view\facelets\compiler\TagLibraryConfig.java:[616,65] cannot find symbol symbol : method isValidateXML() location: class org.apache.myfaces.shared_impl.config.MyfacesConfig C:\projects\MyFaces_current20\core\impl\src\main\java\org\apache\myfaces\view\facelets\compiler\TagLibraryConfig.java:[684,61] cannot find symbol symbol : method isValidateXML() location: class org.apache.myfaces.shared_impl.config.MyfacesConfig C:\projects\MyFaces_current20\core\impl\src\main\java\org\apache\myfaces\context\servlet\ServletExternalContextImpl.java:[921,15] cannot find symbol symbol : variable FlashImpl location: class org.apache.myfaces.context.servlet.ServletExternalContextImpl C:\projects\MyFaces_current20\core\impl\src\main\java\org\apache\myfaces\config\FacesConfigurator.java:[543,62] cannot find symbol symbol : method isValidateXML() location: class org.apache.myfaces.shared_impl.config.MyfacesConfig C:\projects\MyFaces_current20\core\impl\src\main\java\org\apache\myfaces\config\FacesConfigurator.java:[772,70] cannot find symbol symbol : method isValidateXML() location: class org.apache.myfaces.shared_impl.config.MyfacesConfig C:\projects\MyFaces_current20\core\impl\src\main\java\org\apache\myfaces\config\FacesConfigurator.java:[806,66] cannot find symbol symbol : method isValidateXML() location: class org.apache.myfaces.shared_impl.config.MyfacesConfig C:\projects\MyFaces_current20\core\impl\src\main\java\org\apache\myfaces\config\FacesConfigurator.java:[864,62] cannot find symbol symbol : method isValidateXML() location: class org.apache.myfaces.shared_impl.config.MyfacesConfig C:\projects\MyFaces_current20\core\impl\src\main\java\org\apache\myfaces\view\facelets\compiler\EndElementInstruction.java:[47,33] cannot find symbol symbol : method renderUnhandledFacesMessages(javax.faces.context.FacesContext) location: class org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 12 seconds [INFO] Finished at: Thu Apr 15 10:14:54 CEST 2010 [INFO] Final Memory: 105M/452M [INFO] Best regards, Ganesh Werner Punz schrieb: Before I am giving my vote here, there is still a unit test failure ... Am 15.04.10 06:39, schrieb Matthias Wessendorf: +1 Thanks for running this Sent from my iPod. On 15.04.2010, at 03:48, Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com wrote: +1 2010/4/14 Leonardo Uribe mailto:lu4...@gmail.comlu4...@gmail.com mailto:lu4...@gmail.com Hi, I was running the needed tasks to get the 2.0.0 release of Apache MyFaces core out. Minor fixes were done since the latest proposed artifacts (MYFACES-2658, MYFACES-2659 and MYFACES-2660), so we can continue with the vote. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.1 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.0 [1] 3. Maven artifact group org.apache.myfaces.test v1.0.0-beta-3 [1] The artifacts are deployed to my private Apache account ([1] and [3] for binary and source packages). The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see
Re: [VOTE] release for myfaces core 2.0.0
I'm with Werner here. If there's an encoding issue (in the distribution, not the test code) I think doing a release will upset a lot of users. So I'm -1 until we know what causes the test failure... I'm gonna take a look at the failing test, but since I don't have any test failures, I'm not sure my effort will be very useful. /JK 2010/4/15 Werner Punz werner.p...@gmail.com Before I am giving my vote here, there is still a unit test failure ... Am 15.04.10 06:39, schrieb Matthias Wessendorf: +1 Thanks for running this Sent from my iPod. On 15.04.2010, at 03:48, Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com wrote: +1 2010/4/14 Leonardo Uribe mailto:lu4...@gmail.comlu4...@gmail.com mailto:lu4...@gmail.com Hi, I was running the needed tasks to get the 2.0.0 release of Apache MyFaces core out. Minor fixes were done since the latest proposed artifacts (MYFACES-2658, MYFACES-2659 and MYFACES-2660), so we can continue with the vote. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.1 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.0 [1] 3. Maven artifact group org.apache.myfaces.test v1.0.0-beta-3 [1] The artifacts are deployed to my private Apache account ([1] and [3] for binary and source packages). The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] http://people.apache.org/%7Elu4242/myfaces200 http://people.apache.org/~lu4242/myfaces200http://people.apache.org/%7Elu4242/myfaces200 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/%7Elu4242/myfaces200binsrc http://people.apache.org/~lu4242/myfaces200binsrchttp://people.apache.org/%7Elu4242/myfaces200binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314890 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314890 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314890
Re: Unit test failing? (was: Re: [VOTE] release for myfaces core 2.0.0)
I did some quick debugging, but I don't see any usual suspect. The string
replace functions don't use special String methods. It's all hand written
and should be platform independent AFAICS.
I quess it's an encoding issue or Jakob's dependency suggestion.
/JK
2010/4/15 Jakob Korherr jakob.korh...@gmail.com
On my machine it all works fine. I'm using Mac OS X 10.6.3, Java 1.6.0_17
and Maven 2.2.1.
Just a guess in the blue - The changes I applied are on shared. Did you
guys remember to rebuild shared before running the test on impl?
Regards,
Jakob
2010/4/15 Werner Punz werner.p...@gmail.com
Could also be a simple encoding issue which is more likely on a second
thought (and as Jan has pointed out), the replaceAll is highly unlikely to
be inconsistent in its weird behavior, never encountered that.
Anyway as I said I will have a look as soon as it is possible for me
(otherwise someone else can quickly check what the cause of the problem
is)
Werner
Am 15.04.10 10:06, schrieb Werner Punz:
Ok the affected part is the escape quoting, which had a bug recently
which Jakob fixed.
inputText.getAttributes().put(onchange, alert('test'));
The test checks for following:
assertTrue(output.contains(apos;alert(\\apos;test\\apos;)apos;));
but the output string I am getting here is:
input id=j_id0 name=j_id0 type=text value=
onchange=jsf.util.chain(document.getElementById(apos;j_id0apos;),
event,apos;alert(apos;testapos;)apos;);/
apos;alert(apos;testapos;)apos; here should be an escaping hence
the test fails rightfully, what however strikes me is why it fails on
some systems and on some it does not, I assume it has to do with the
strange replaceAll behavior java has (which does additional escaping to
the normal one in the replacement part, this might be inconsistent over
various platforms (usually you fall into this trap if you do file
separator operations and then move over to windows)).
But this is just a wild guessing, if no one else is able to fix it I
will have a look in the afternoon, but for now I have to serve a
customer.
Werner
Am 15.04.10 09:30, schrieb Werner Punz:
Ok here is some additional information:
testsuite failures=2 time=0.037 errors=0 skipped=0 tests=6
name=org.apache.myfaces.renderkit.html.HtmlTextRendererTest
properties
property name=java.runtime.name value=Java(TM) SE Runtime
Environment/
property name=sun.boot.library.path
value=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Libraries/
property name=java.vm.version value=14.3-b01-101/
testcase time=0.006
name=testClientBehaviorUserCodeJavaScriptEscaping
failure
type=junit.framework.AssertionFailedErrorjunit.framework.AssertionFailedError
at
org.apache.myfaces.renderkit.html.HtmlTextRendererTest.testClientBehaviorUserCodeJavaScriptEscaping(HtmlTextRendererTest.java:215)
/failure
/testcase
testcase time=0.005
name=testClientBehaviorUserCodeJavaScriptDoubleEscaping
failure
type=junit.framework.AssertionFailedErrorjunit.framework.AssertionFailedError
at
org.apache.myfaces.renderkit.html.HtmlTextRendererTest.testClientBehaviorUserCodeJavaScriptDoubleEscaping(HtmlTextRendererTest.java:237)
/failure
Am 15.04.10 09:22, schrieb Jan-Kees van Andel:
I just runned the build on Windows Vista x64:
D:\dev\work\myfaces2\core_2_0_0mvn --version
Maven version: 2.0.10
Java version: 1.6.0_14
OS name: windows vista version: 6.0 arch: amd64 Family: windows
The tests worked fine.
@Matthias: Can you see which test method is causing the issue and which
assertion fails (or which exception is thrown)?
/JK
2010/4/15 Matthias Wessendorf mat...@apache.org
mailto:mat...@apache.org
that's funny :-)
What JDK ? 1.5 ?
I am on 1.6.x
=
mat...@woody:~/work/source/Apache/myfaces/trunk$ mvn -v
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_13
Java home: /java/jdk1.6.0_13/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux version: 2.6.31-19-generic arch: i386 Family:
unix
On Thu, Apr 15, 2010 at 8:55 AM, Leonardo Uribe lu4...@gmail.com
mailto:lu4...@gmail.com wrote:
Hi
In my machine works fine. I compiled sources on both Linux and
Windows.
regards,
Leonardo Uribe
2010/4/15 Matthias Wessendorf mat...@apache.org
mailto:mat...@apache.org
These two revisions cause the problem:
http://svn.apache.org/viewvc?view=revisionrevision=933814
http://svn.apache.org/viewvc?view=revisionrevision=933814
http://svn.apache.org/viewvc?view=revisionrevision=933812
http://svn.apache.org/viewvc?view=revisionrevision=933812
On Thu, Apr 15, 2010 at 7:43 AM, Matthias Wessendorf
mat...@apache.org mailto:mat...@apache.org
wrote:
Yesterday I mentioned the same, on trunk
I am on Linux, Werner is on OS X.
Jakob/Leo: r u windoze ?
Thx,
Matthias
PS: I changed the subject to not hijack the vote ;-)
On Thu, Apr 15, 2010 at 7:37 AM, Werner Punz
Re: [VOTE] release for myfaces core 2.0.0
With the issue resolved (the release version is ok AFAICS), I withdraw my -1 and re-vote with a +1. /JK 2010/4/15 Jakob Korherr jakob.korh...@gmail.com Again: it works on my machine.. And I guess you may have forgotten to rebuild shared too, because the test tests results of changes on shared. But until this is really sorted out, my vote also is -1. Regards, Jakob 2010/4/15, Werner Punz werner.p...@gmail.com: Ok here it goes officially -1 until we have resolved the issue upon looking at the test, the test is ok and tests correctly, the code causing the test fail is at fault. That should not happen for a release. As I have posted in another mail I currently have to serve a customer if no one else is able to fix it in between I will have a look late in the afternoon. Werner Am 15.04.10 07:37, schrieb Werner Punz: Before I am giving my vote here, there is still a unit test failure ... Am 15.04.10 06:39, schrieb Matthias Wessendorf: +1 Thanks for running this Sent from my iPod. On 15.04.2010, at 03:48, Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com wrote: +1 2010/4/14 Leonardo Uribe mailto:lu4...@gmail.comlu4...@gmail.com mailto:lu4...@gmail.com Hi, I was running the needed tasks to get the 2.0.0 release of Apache MyFaces core out. Minor fixes were done since the latest proposed artifacts (MYFACES-2658, MYFACES-2659 and MYFACES-2660), so we can continue with the vote. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.1 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.0 [1] 3. Maven artifact group org.apache.myfaces.test v1.0.0-beta-3 [1] The artifacts are deployed to my private Apache account ([1] and [3] for binary and source packages). The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] http://people.apache.org/%7Elu4242/myfaces200 http://people.apache.org/~lu4242/myfaces200http://people.apache.org/%7Elu4242/myfaces200 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/%7Elu4242/myfaces200binsrc http://people.apache.org/~lu4242/myfaces200binsrchttp://people.apache.org/%7Elu4242/myfaces200binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314890 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314890 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314890 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release for myfaces core 2.0.0
Sure. Here it is: http://old.nabble.com/Unit-test-failing--%28was%3A-Re%3A--VOTE--release-for-myfaces-core-2.0.0%29-ts28251443.html /JK 2010/4/15 Matthias Wessendorf mat...@apache.org can you post the archived links, so that folks aren't confused ? Thx, Matthias On Thu, Apr 15, 2010 at 11:20 AM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: With the issue resolved (the release version is ok AFAICS), I withdraw my -1 and re-vote with a +1. /JK 2010/4/15 Jakob Korherr jakob.korh...@gmail.com Again: it works on my machine.. And I guess you may have forgotten to rebuild shared too, because the test tests results of changes on shared. But until this is really sorted out, my vote also is -1. Regards, Jakob 2010/4/15, Werner Punz werner.p...@gmail.com: Ok here it goes officially -1 until we have resolved the issue upon looking at the test, the test is ok and tests correctly, the code causing the test fail is at fault. That should not happen for a release. As I have posted in another mail I currently have to serve a customer if no one else is able to fix it in between I will have a look late in the afternoon. Werner Am 15.04.10 07:37, schrieb Werner Punz: Before I am giving my vote here, there is still a unit test failure ... Am 15.04.10 06:39, schrieb Matthias Wessendorf: +1 Thanks for running this Sent from my iPod. On 15.04.2010, at 03:48, Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com wrote: +1 2010/4/14 Leonardo Uribe mailto:lu4...@gmail.com lu4...@gmail.com mailto:lu4...@gmail.com Hi, I was running the needed tasks to get the 2.0.0 release of Apache MyFaces core out. Minor fixes were done since the latest proposed artifacts (MYFACES-2658, MYFACES-2659 and MYFACES-2660), so we can continue with the vote. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.1 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.0 [1] 3. Maven artifact group org.apache.myfaces.test v1.0.0-beta-3 [1] The artifacts are deployed to my private Apache account ([1] and [3] for binary and source packages). The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] http://people.apache.org/%7Elu4242/myfaces200 http://people.apache.org/~lu4242/myfaces200http://people.apache.org/%7Elu4242/myfaces200 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/%7Elu4242/myfaces200binsrc http://people.apache.org/~lu4242/myfaces200binsrchttp://people.apache.org/%7Elu4242/myfaces200binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314890 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314890 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314890 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] release for myfaces core 2.0.0
I agree with Matthias. Removing a class from an API is usually impossible and if Leo has no objections to prepare the release again... But apart from this little thing, a big +1 on the release! Congrats guys! Regards, Jan-Kees 2010/4/14 Matthias Wessendorf mat...@apache.org Hey Leo, awesome! Patch is attached and already committed to trunk -Matthias On Wed, Apr 14, 2010 at 5:37 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Matthias Yes, I think we can include it. Just attach a patch and I'll generate all artifacts. regards, Leonardo Uribe 2010/4/14 Matthias Wessendorf mat...@apache.org Actually I tend to re-vote -1 (b/c of MYFACES-2659)... (not a vote though, just a thought) What do you guys think? BTW. the trunk has some other problems, a test-case fails... On Wed, Apr 14, 2010 at 5:10 PM, Matthias Wessendorf mat...@apache.org wrote: Any chance we can get this into the 2.0.0 release ? https://issues.apache.org/jira/browse/MYFACES-2659 On Wed, Apr 14, 2010 at 4:52 PM, Jakob Korherr jakob.korh...@gmail.com wrote: +1 Regards, Jakob 2010/4/14 Michael Concini mconc...@gmail.com +1 On 4/14/2010 8:29 AM, Bernd Bohmann wrote: +1 Regards Bernd On Wed, Apr 14, 2010 at 11:42 AM, Martin Marinschek martin.marinsc...@gmail.com wrote: +1, great, great. best regards, Martin On Wed, Apr 14, 2010 at 11:31 AM, Bruno Arandabrunoara...@gmail.com wrote: +1 Great news! Thanks! Bruno On 14 April 2010 08:35, Matthias Wessendorfmat...@apache.org wrote: +1 On Wed, Apr 14, 2010 at 9:05 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/4/14 Leonardo Uribelu4...@gmail.com +1 2010/4/14 Leonardo Uribelu4...@gmail.com Hi, I was running the needed tasks to get the 2.0.0 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.1 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.0 [1] 3. Maven artifact group org.apache.myfaces.test v1.0.0-beta-3 [1] The artifacts are deployed to my private Apache account ([1] and [3] for binary and source packages). The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] http://people.apache.org/~lu4242/myfaces200http://people.apache.org/%7Elu4242/myfaces200 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces200binsrchttp://people.apache.org/%7Elu4242/myfaces200binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314890 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [GSoC] Automated webapp tests
You can use the Selenium RC Server [1] to host the browser. You can then remotely invoke this server from your Maven build. The Maven build then doesn't need a browser. (but you're right, Selenium needs a browser *somewhere*) Regards, Jan-Kees [1] http://seleniumhq.org/projects/remote-control/ 2010/4/8 Matthias Wessendorf mat...@apache.org Had a look at JBoss' Arquillian ? -Matthias On Thu, Apr 8, 2010 at 9:55 AM, Martinconi Cosmin cosmin.martinc...@codebeat.ro wrote: Hi Mike, Thanks for the feedback. I did considered Selenium, but after some discussions we concluded that the testing should be done totally automated within maven and without a browser, so that excludes Selenium since it needs a browser running in order to work. Regards, Cosmin On Wed, Apr 7, 2010 at 8:57 PM, Mike Kienenberger mkien...@gmail.com wrote: I'd like to recommend that you also consider Selenium as a test framework. On Wed, Apr 7, 2010 at 10:04 AM, Martinconi Cosmin cosmin.martinc...@codebeat.ro wrote: Hi, I also prepared an application proposal, that I submitted to Google and a wiki page: http://wiki.apache.org/myfaces/GSoC2010_AutomatedTests for the Automated webapp tests for MyFaces Core and extensions issue. You can find the Jira Issue at: https://issues.apache.org/jira/browse/MYFACESTEST-6 I would really appreciate any feedback and comments. Thanks, Cosmin -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [cwiki] spaces
+1 on the whole email. My username is jankeesvanan...@apache.org. Regards, Jan-Kees 2010/4/8 Gerhard Petracek gerhard.petra...@gmail.com hi @ all, the myfaces space is available at [1]. @committers: please post your confluence user-names and i'll add them to the committers-group. if there are no objections, i'll create one space per subproject. [1] will provide some general information and news. further information would be available in the space of the concrete sub-project. for the beginning i'll create new spaces for myfaces-extval and myfaces-codi. regards, gerhard [1] http://cwiki.apache.org/confluence/display/MYFACES/Index http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
