date:20100616

this.id is undefined in jsf.ajax.request (regression from 2.0.0)


 Key: MYFACES-2755
 URL: https://issues.apache.org/jira/browse/MYFACES-2755
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.1
Reporter: Michael Concini


With the new javascript, we now wrapper calls into jsf.ajax.request with a 
function call.  So for example this:

h:commandButton id=incrementButton value=Increment
   onclick=jsf.ajax.request(this, event, { execute: 
this.id, render: 'counter' }); return false;
   actionListener=#{counter.increment} /

would be rendered as this:
input id=incrementButton name=incrementButton type=submit 
value=Increment
onclick=var cf = function(){jsf.ajax.request(this, event, { execute: this.id, 
render: 'counter' }); return false;};var oamSF = function(){};return 
(cf()==false)? false : oamSF(); /


The problem is that we've broken the reference to this.id as it is undefined at 
the function's scope. This works fine in both the 2.0.0 release as well as 
Mojarra.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (MYFACES-2755) this.id is undefined in jsf.ajax.request (regression from 2.0.0)

2010-06-16 Thread Werner Punz (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12879332#action_12879332
 ] 

Werner Punz commented on MYFACES-2755:
--

Ok this is serious, I am getting on it right away.
I hope we can get the fix in in 2.0.1


 this.id is undefined in jsf.ajax.request (regression from 2.0.0)
 

 Key: MYFACES-2755
 URL: https://issues.apache.org/jira/browse/MYFACES-2755
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.1
Reporter: Michael Concini

 With the new javascript, we now wrapper calls into jsf.ajax.request with a 
 function call.  So for example this:
 h:commandButton id=incrementButton value=Increment
onclick=jsf.ajax.request(this, event, { execute: 
 this.id, render: 'counter' }); return false;
actionListener=#{counter.increment} /
 would be rendered as this:
 input id=incrementButton name=incrementButton type=submit 
 value=Increment
 onclick=var cf = function(){jsf.ajax.request(this, event, { execute: 
 this.id, render: 'counter' }); return false;};var oamSF = function(){};return 
 (cf()==false)? false : oamSF(); /
 The problem is that we've broken the reference to this.id as it is undefined 
 at the function's scope. This works fine in both the 2.0.0 release as well as 
 Mojarra.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (MYFACES-2755) this.id is undefined in jsf.ajax.request (regression from 2.0.0)


[ 
https://issues.apache.org/jira/browse/MYFACES-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12879334#action_12879334
 ] 

Michael Concini commented on MYFACES-2755:
--

Thanks Werner.  

FYI, this also looks to affect things like onerror as well. This is not working 
either (statusUpdate is just a simple embedded script in our page).  

h:commandButton id=button1 value=Count 
action=#{incrementdecrement.causeError} 
onclick=jsf.ajax.request(this, event, { render: 'out1', onerror: 
statusUpdate }); return false;/



 this.id is undefined in jsf.ajax.request (regression from 2.0.0)
 

 Key: MYFACES-2755
 URL: https://issues.apache.org/jira/browse/MYFACES-2755
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.1
Reporter: Michael Concini

 With the new javascript, we now wrapper calls into jsf.ajax.request with a 
 function call.  So for example this:
 h:commandButton id=incrementButton value=Increment
onclick=jsf.ajax.request(this, event, { execute: 
 this.id, render: 'counter' }); return false;
actionListener=#{counter.increment} /
 would be rendered as this:
 input id=incrementButton name=incrementButton type=submit 
 value=Increment
 onclick=var cf = function(){jsf.ajax.request(this, event, { execute: 
 this.id, render: 'counter' }); return false;};var oamSF = function(){};return 
 (cf()==false)? false : oamSF(); /
 The problem is that we've broken the reference to this.id as it is undefined 
 at the function's scope. This works fine in both the 2.0.0 release as well as 
 Mojarra.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (MYFACES-2755) this.id is undefined in jsf.ajax.request (regression from 2.0.0)

2010-06-16 Thread Werner Punz (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12879335#action_12879335
 ] 

Werner Punz commented on MYFACES-2755:
--

Ok this is not entirely javascript related at least not in my part of the code 
is the problem here is following:

onclick = jsf.ajax.request(this, event, { execute: this.id, render: 'counter' 
}); return false;
is mapped into

var cf = function(){jsf.ajax.request(this, event, { execute: this.id, render: 
'counter' }); return false;};var oamSF = function(){};return (cf()==false)? 
false : oamSF();

which reassigns the this scope (whoever has written that code did not take that 
into consideration.
the problem then is that this is assigned to the function cf which then tries 
to determine the original this.id id value.

But now that this points towards the function id is undefined.

A quick workaround to fix that problem would be to use one of our impl functions

the call would look like: cf myfaces._impl._util._Lang.hitch(this, 
(){jsf.ajax.request(this, event, { execute: this.id, render: 'counter' }); 
return false;});

this would reassign the this to the original scope. 
if you do not want to go for the helper in our impls Lang package then a 
workaround would be to 
go for following code:

var cf = function(){jsf.ajax.request(this, event, { execute: this.id, render: 
'counter' }); return false;};var oamSF = function(){};return (cf.apply(this, 
[])==false)? false : oamSF.apply(this, []);

This would drag the scope also in.

Cheers Werner

Leonardo or Jakob can you take over you probably know fastest where the related 
code is.









 this.id is undefined in jsf.ajax.request (regression from 2.0.0)
 

 Key: MYFACES-2755
 URL: https://issues.apache.org/jira/browse/MYFACES-2755
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.1
Reporter: Michael Concini

 With the new javascript, we now wrapper calls into jsf.ajax.request with a 
 function call.  So for example this:
 h:commandButton id=incrementButton value=Increment
onclick=jsf.ajax.request(this, event, { execute: 
 this.id, render: 'counter' }); return false;
actionListener=#{counter.increment} /
 would be rendered as this:
 input id=incrementButton name=incrementButton type=submit 
 value=Increment
 onclick=var cf = function(){jsf.ajax.request(this, event, { execute: 
 this.id, render: 'counter' }); return false;};var oamSF = function(){};return 
 (cf()==false)? false : oamSF(); /
 The problem is that we've broken the reference to this.id as it is undefined 
 at the function's scope. This works fine in both the 2.0.0 release as well as 
 Mojarra.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (MYFACES-2755) this.id is undefined in jsf.ajax.request (regression from 2.0.0)


[ 
https://issues.apache.org/jira/browse/MYFACES-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12879340#action_12879340
 ] 

Michael Concini commented on MYFACES-2755:
--

I can try to put together a fix on my end here using the apply(this, []) method.

 this.id is undefined in jsf.ajax.request (regression from 2.0.0)
 

 Key: MYFACES-2755
 URL: https://issues.apache.org/jira/browse/MYFACES-2755
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.1
Reporter: Michael Concini

 With the new javascript, we now wrapper calls into jsf.ajax.request with a 
 function call.  So for example this:
 h:commandButton id=incrementButton value=Increment
onclick=jsf.ajax.request(this, event, { execute: 
 this.id, render: 'counter' }); return false;
actionListener=#{counter.increment} /
 would be rendered as this:
 input id=incrementButton name=incrementButton type=submit 
 value=Increment
 onclick=var cf = function(){jsf.ajax.request(this, event, { execute: 
 this.id, render: 'counter' }); return false;};var oamSF = function(){};return 
 (cf()==false)? false : oamSF(); /
 The problem is that we've broken the reference to this.id as it is undefined 
 at the function's scope. This works fine in both the 2.0.0 release as well as 
 Mojarra.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TOMAHAWK-1521) ExtensionsFilter cacheFileSizeErrors Does Not Work As Advertised

2010-06-16 Thread JZ (JIRA)

[
https://issues.apache.org/jira/browse/TOMAHAWK-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12879344#action_12879344
]

JZ commented on TOMAHAWK-1521:
--

After double checking, I had a typo in the ExtensionsFilter config for the
uploadMaxSize name which meant this was defaulting to the uploadMaxFileSize. I
understand from the above how this creates the non-recoverable error situation,
etc.

However, there that causes an unexpected (to me) situation.

That is, with the uploadMaxSize properly configured, the FileUploadIOException
is caught as expected @ ServletChacheFileSizeErrorsFileUpload:208. The
exception is cast, rethrown, and re-caught just below as a
FileUploadBase.FileSizeLimitExceededException and the request attributes are
set up. No problem.

However ... after handling, the FileItemIterator.hasNext() is called @ line
132, which causes a java.io.Exception (stream closed) which is caught @ line
248, wrapped in a FileUploadException and handled at
MultipartRequestWrapper:176.

Is that, in fact, the intended behaviour? I now have error-level messages in
my log for a situation which was expected and could be handled gracefully.

If it's expected, I'm ok closing as invalid, with apologies for the confusion.

ExtensionsFilter cacheFileSizeErrors Does Not Work As Advertised

Key: TOMAHAWK-1521
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1521
Project: MyFaces Tomahawk
Issue Type: Bug
Components: File Upload
Affects Versions: 1.1.9
Environment: commons-fileupload-1.2.1
Reporter: JZ

With the extensions filter configured with cacheFileSizeErrors=true and
uploadMaxFileSize=1M, I get the stacktrace below when uploading a file larger
than 1M.
This is NOT the expected stack trace.
Note that ServletChacheFileSizeErrorsFileUpload is used.
However, line 108 in that class has a comment which states that the line
throws a SizeLimitExceededException (wrapped by a FileUploadIOException) if
the request is longer than the max size
That is not accurrate. The SizeLimitExceededException is NOT, in fact,
wrapped.
As a result, ServletChacheFileSizeErrorsFileUpload does not trap exceptions
at the right level and the SizeLimitExceededException bubbles up to the
MultipartRequestWrapper (which is the source of the WARN - level stack trace
below).
Basically, this behaviour renders the cacheFileSizeErrors property useless.
Here's the stacktrace:
2010-06-15 15:07:57,234 WARN
org.apache.myfaces.webapp.filter.MultipartRequestWrapper] -
SizeLimitExceededException while uploading file. []
org.apache.commons.fileupload.FileUploadBase$SizeLimitExceededException: the
request was rejected because its size (3506126) exceeds the configured
maximum (1048576)
at
org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.init(FileUploadBase.java:914)
at
org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331)
at
org.apache.myfaces.webapp.filter.servlet.ServletChacheFileSizeErrorsFileUpload.parseRequestCatchingFileSizeErrors(ServletChacheFileSizeErrorsFileUpload.java:108)
at
org.apache.myfaces.webapp.filter.MultipartRequestWrapper.parseRequest(MultipartRequestWrapper.java:131)
at
org.apache.myfaces.webapp.filter.MultipartRequestWrapper.getParameter(MultipartRequestWrapper.java:274)
at
javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:158)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (PORTLETBRIDGE-146) Portlet 2.0 Bridge: renderRedirect after forward must use include


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-146.


Fix Version/s: 2.0.0
   Resolution: Fixed

Did as suggested -- bridge now detects that it has done a forward and hence 
from then on uses include.

 Portlet 2.0 Bridge: renderRedirect after forward must use include
 -

 Key: PORTLETBRIDGE-146
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-146
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 2.0.0


 Currently the bridge always does a dispatch.forward in 
 externalContext.dispatch.  However, because Portlet 2.0 requires the response 
 be committed following the return of a forward if a render redirect occurs 
 during or after such a forward the subsequent dispatch will fail if you try 
 to forward to it.  Instead you must use include.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (PORTLETBRIDGE-147) TCK bug: getRequestHeaderMapActionTest fails if content-length excluded by bridge but in request


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-147.


Fix Version/s: 1.0.0
   2.0.0
   Resolution: Fixed

Updated TCK test to account for content-length in underlying request but the 
bridge says its value is -1

 TCK bug:  getRequestHeaderMapActionTest fails if content-length excluded by 
 bridge but in request
 -

 Key: PORTLETBRIDGE-147
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-147
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 1.0.0, 2.0.0


 By spec the bridge is supposed to exclude the content-length header if 
 getContentLength returns -1.  The getRequestheaderMapActionTest fails if the 
 request contains a content-length header (say its a wsrp call and this header 
 is about the soap message) when it compares that all headers in the request 
 are in the bridge headerMap.  The test should special case this and check 
 that if the header is content-length and its not in the headerMap then to 
 just continue on as this is corerct.

-- 
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 core 2.0.1

2010-06-16 Thread Bernd Bohmann

Hi Leonardo,

thanks a lot. Now it is ok for me.
I added some missing licenses on the 2.0.1 branch.

Regards

Bernd

On Tue, Jun 15, 2010 at 11:14 PM, Leonardo Uribe lu4...@gmail.com wrote:
Hi Bernd

I added in api:

META-INF/licenses/dojo-LICENSE.TXT
META-INF/licenses/j4fry-LICENSE.TXT
META-INF/licenses/facelets-LICENSE.TXT

in impl

META-INF/licenses/glassfish-LICENSE.TXT
META-INF/licenses/facelets-LICENSE.TXT

because the schemas with CDDL license are on impl jar.

The update to NOTICE.txt message was committed too. Anyway to prevent
misunderstandings, I'll wait your response about it.

regards,

Leonardo Uribe

2010/6/15 Bernd Bohmann bernd.bohm...@atanion.com

Hello Leonardo,

looks ok for me.

Can you also add in api

META-INF/licenses/dojo-LICENSE.TXT
META-INF/licenses/j4fry-LICENSE.TXT
META-INF/licenses/glassfish-LICENSE.TXT
META-INF/licenses/facelets-LICENSE.TXT

and in impl

META-INF/licenses/facelets-LICENSE.TXT

an example would be

http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/core/src/main/resources/META-INF/licenses/

I have no time to perform the required changes unit tomorrow afternoon.

Regards

Bernd

On Tue, Jun 15, 2010 at 8:11 PM, Leonardo Uribe lu4...@gmail.com wrote:
Hi

I think the NOTICE.txt file on impl module could be like this:

This product includes software developed by:
The Apache Software Foundation (http://www.apache.org/).

See the file LICENSE.txt
See licenses for accompanying products in the /licenses subdirectory.

This software also includes code from Facelets
(https://facelets.dev.java.net/)
for the purpose of implementing Facelets PDL for JSF 2.0 support.

This product includes schema files developed for the Glassfish Java EE
reference implementation (http://java.sun.com/xml/ns/j2ee/).
Apache Myfaces elects to include this software in this distribution
under the CDDL license. You can obtain a copy of the License at:
https://glassfish.dev.java.net/public/CDDL+GPL.html
The source code is available at:
https://glassfish.dev.java.net/source/browse/glassfish/

The following schemas are included:

===
javaee_5.xsd
javaee_web_services_client_1_2.xsd
===

If no comments, I'll commit this fix tomorrow, regenerate all artifacts and
start vote again.

regards,

Leonardo Uribe

2010/6/15 Leonardo Uribe lu4...@gmail.com

Ok, let me know when all fixes has been applied, so I can regenerate
(again) the artifacts.

To prevent misunderstandings, it is better to propose another vote and
after that wait another 72 hours for release.

2010/6/15 Mike Kienenberger mkien...@gmail.com

The licensing issue has to be fixed, if there is such an issue.
And Bernd needs to withdraw his -1 before we can release using this vote.

On Tue, Jun 15, 2010 at 12:30 PM, Leonardo Uribe lu4...@gmail.com
wrote:

2010/6/15 Mike Kienenberger mkien...@gmail.com

At this point, should this discussion be moved out of the voting
thread?

By the way, MyFaces can include CDDL xsd and dtd spec files, so long
as they are appropriately documented.

http://www.apache.org/legal/resolved.html#category-b

So we can close this vote and continue the release procedure, right?

On Tue, Jun 15, 2010 at 12:02 PM, Leonardo Uribe lu4...@gmail.com
wrote:
Hi

Those files were copied from tomcat project:

http://svn.apache.org/repos/asf/tomcat/trunk/java/javax/servlet/resources/

There is no mention in NOTICE file there.

regards,

Leonardo Uribe

2010/6/15 Bernd Bohmann bernd.bohm...@atanion.com

Hello,

the geronimo project includes these file as well. See:

http://svn.apache.org/repos/asf/geronimo/server/trunk/NOTICE

Maybe we should follow with the same procedure.

Any suggestions?

Regards

Bernd

On Tue, Jun 15, 2010 at 10:06 AM, Werner Punz
werner.p...@gmail.com
wrote:
Hi, sorry to be nitpicking again, but since both files are CDDL
are
we
even
allowed to bundle them?
Or are both clear due to reimplementation and this was an error
made
on
Bernds side.

Werner

Am 14.06.10 19:57, schrieb Leonardo Uribe:

Hi Bernd

All artifacts has been regenerated, to include your fix, so we
can
continue with the vote.

regards,

Leonardo Uribe

2010/6/13 Bernd Bohmann bernd.bohm...@googlemail.com
mailto:bernd.bohm...@googlemail.com

Hello,

here is my

-1

I found too many files without or old apache license header.
j4fry is missing in the notice file.

[jira] Created: (PORTLETBRIDGE-148) Bridge RequestHeaderMap ensureContentLength/CharsSet fails ClassCastException during resource request

Bridge RequestHeaderMap ensureContentLength/CharsSet  fails ClassCastException 
during resource request
--

 Key: PORTLETBRIDGE-148
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-148
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman


By spec the bridge needs to ensure that the Content-type and Char-set-encodings 
headers exist (in its ExternalContext  header Map) on action and resource 
requests.  We get a ClassCastException during a resource request because when 
the code was brought forward from 1.0 the casts weren't changed from 
ActionRequest to ClientDataRequests

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (PORTLETBRIDGE-149) Replace/Update copyright statements in new example with standard Apache statement

Replace/Update copyright statements in new example with standard Apache 
statement
-

 Key: PORTLETBRIDGE-149
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-149
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha, 1.0.0-beta
Reporter: Michael Freedman
Assignee: Michael Freedman


Added 6 new examples from the Mojarra sample set but forgot to exhaustively 
insert/replace the original copyrights with the standard Apache statement.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (PORTLETBRIDGE-148) Bridge RequestHeaderMap ensureContentLength/CharsSet fails ClassCastException during resource request


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-148.


Fix Version/s: 2.0.0
   Resolution: Fixed

As suggested changed casts from ActionRequest to ClientDataRequest

 Bridge RequestHeaderMap ensureContentLength/CharsSet  fails 
 ClassCastException during resource request
 --

 Key: PORTLETBRIDGE-148
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-148
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 2.0.0


 By spec the bridge needs to ensure that the Content-type and 
 Char-set-encodings headers exist (in its ExternalContext  header Map) on 
 action and resource requests.  We get a ClassCastException during a resource 
 request because when the code was brought forward from 1.0 the casts weren't 
 changed from ActionRequest to ClientDataRequests

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (MYFACES-2754) MyFaces can attempt to create a new session after the response has been committed

[
https://issues.apache.org/jira/browse/MYFACES-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12879413#action_12879413
]

Michael Concini commented on MYFACES-2754:
--

initial fix breaks client side state saving in some instances. retesting with
a slight change that should resolve it. Will commit the change this afternoon
once full testing is completed.

MyFaces can attempt to create a new session after the response has been
committed
-

Key: MYFACES-2754
URL: https://issues.apache.org/jira/browse/MYFACES-2754
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.2.9, 2.0.0
Reporter: Michael Concini
Assignee: Michael Concini

As currently implemented, MyFaces can attempt to create a new session after
the response has been committed. This is due to calling saveSerializedView
on the JspStateManagerImpl even in cases where writeState was never called
(e.g. a JSP outcome target with no form tags). This can lead to either an
IllegalStateException being thrown or else extra sessions being created which
wait until the session timeout is reached to be destroyed and thus can lead
to a potential memory leak. Which behavior is seen depends on the appserver
being used and whether it reuses session cookies for the same client.
JSPStateManagerImpl will be updated to set a FacesContext attribute on
writeState to indicate that the state should be written by
saveSerializedView.
On 2.0, FlashImpl also needs to be updated as well to not create a new
session during the remove children operation. Currently we are creating a
new session just to create a new map and then clear it.

--
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 core 2.0.1

Hi Bernd

Ok, thanks. Unfortunately I have to restart all release steps, because there
was changes applied on trunk that should be applied, but I'm not have a
separate patch to apply it (MYFACES-2755, MYFACES-2754 is in progress,
TOMAHAWK).

We still have an unresolved problem with myfaces master pom v7 (checkstyle
version is snapshot). Since myfaces core 2.0.x depends on this pom and we
don't have response from Matthias fix this issue, At this point I have to
release myfaces master pom first.

regards,

Leonardo Uribe

2010/6/16 Bernd Bohmann bernd.bohm...@googlemail.com

Hi Leonardo,

thanks a lot. Now it is ok for me.
I added some missing licenses on the 2.0.1 branch.

Regards

Bernd

On Tue, Jun 15, 2010 at 11:14 PM, Leonardo Uribe lu4...@gmail.com wrote:
Hi Bernd

I added in api:

META-INF/licenses/dojo-LICENSE.TXT
META-INF/licenses/j4fry-LICENSE.TXT
META-INF/licenses/facelets-LICENSE.TXT

in impl

META-INF/licenses/glassfish-LICENSE.TXT
META-INF/licenses/facelets-LICENSE.TXT

because the schemas with CDDL license are on impl jar.

The update to NOTICE.txt message was committed too. Anyway to prevent
misunderstandings, I'll wait your response about it.

regards,

Leonardo Uribe

2010/6/15 Bernd Bohmann bernd.bohm...@atanion.com

Hello Leonardo,

looks ok for me.

Can you also add in api

META-INF/licenses/dojo-LICENSE.TXT
META-INF/licenses/j4fry-LICENSE.TXT
META-INF/licenses/glassfish-LICENSE.TXT
META-INF/licenses/facelets-LICENSE.TXT

and in impl

META-INF/licenses/facelets-LICENSE.TXT

an example would be

http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/core/src/main/resources/META-INF/licenses/

I have no time to perform the required changes unit tomorrow afternoon.

Regards

Bernd

On Tue, Jun 15, 2010 at 8:11 PM, Leonardo Uribe lu4...@gmail.com
wrote:
Hi

I think the NOTICE.txt file on impl module could be like this:

This product includes software developed by:
The Apache Software Foundation (http://www.apache.org/).

See the file LICENSE.txt
See licenses for accompanying products in the /licenses
subdirectory.

This software also includes code from Facelets
(https://facelets.dev.java.net/)
for the purpose of implementing Facelets PDL for JSF 2.0 support.

The following schemas are included:

===
javaee_5.xsd
javaee_web_services_client_1_2.xsd
===

If no comments, I'll commit this fix tomorrow, regenerate all
artifacts and
start vote again.

regards,

Leonardo Uribe

2010/6/15 Leonardo Uribe lu4...@gmail.com

Ok, let me know when all fixes has been applied, so I can regenerate
(again) the artifacts.

To prevent misunderstandings, it is better to propose another vote
and
after that wait another 72 hours for release.

2010/6/15 Mike Kienenberger mkien...@gmail.com

The licensing issue has to be fixed, if there is such an issue.
And Bernd needs to withdraw his -1 before we can release using this
vote.

On Tue, Jun 15, 2010 at 12:30 PM, Leonardo Uribe lu4...@gmail.com
wrote:

2010/6/15 Mike Kienenberger mkien...@gmail.com

At this point, should this discussion be moved out of the voting
thread?

By the way, MyFaces can include CDDL xsd and dtd spec files, so
long
as they are appropriately documented.

http://www.apache.org/legal/resolved.html#category-b

So we can close this vote and continue the release procedure,
right?

On Tue, Jun 15, 2010 at 12:02 PM, Leonardo Uribe
lu4...@gmail.com
wrote:
Hi

Those files were copied from tomcat project:

http://svn.apache.org/repos/asf/tomcat/trunk/java/javax/servlet/resources/

There is no mention in NOTICE file there.

regards,

Leonardo Uribe

2010/6/15 Bernd Bohmann bernd.bohm...@atanion.com

Hello,

the geronimo project includes these file as well. See:

http://svn.apache.org/repos/asf/geronimo/server/trunk/NOTICE

Maybe we should follow with the same procedure.

Any suggestions?

Regards

Bernd

On Tue, Jun 15, 2010 at 10:06 AM, Werner Punz
werner.p...@gmail.com
wrote:
Hi, sorry

[VOTE] release for myfaces master pom v 8

Hi,

I was running the needed tasks to get the version 8 release of Apache
MyFaces Master POM.

Please note that this vote concerns all of the following parts:

 1. Maven artifact group org.apache.myfaces.myfaces v 8  [1]

The artifacts are deployed to my private Apache account [1].

Please take a look at the version 8 pom 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/myfaces8
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: [VOTE] release for myfaces master pom v 8

+1

2010/6/16 Leonardo Uribe lu4...@gmail.com

 Hi,

 I was running the needed tasks to get the version 8 release of Apache
 MyFaces Master POM.

 Please note that this vote concerns all of the following parts:

  1. Maven artifact group org.apache.myfaces.myfaces v 8  [1]

 The artifacts are deployed to my private Apache account [1].

 Please take a look at the version 8 pom 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/myfaces8http://people.apache.org/%7Elu4242/myfaces8
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: [VOTE] release for myfaces master pom v 8

2010-06-16 Thread Bernd Bohmann

+1

On Wed, Jun 16, 2010 at 8:11 PM, Leonardo Uribe lu4...@gmail.com wrote:
 +1

 2010/6/16 Leonardo Uribe lu4...@gmail.com

 Hi,

 I was running the needed tasks to get the version 8 release of Apache
 MyFaces Master POM.

 Please note that this vote concerns all of the following parts:

  1. Maven artifact group org.apache.myfaces.myfaces v 8  [1]

 The artifacts are deployed to my private Apache account [1].

 Please take a look at the version 8 pom 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/myfaces8
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: [VOTE] release for myfaces master pom v 8

2010-06-16 Thread Mark Struberg

Hi Leo!

Again me :)

Please allow me another question from an outside guy.

I wondered if we should also add ASL headers to the MyFaces poms and other 
XMLs. I know that we have this in owb, bval, geronimo, openjpa, etc.
So it at least seems to be a pretty common way to do it pom.xml:

?xml version=1.0 encoding=UTF-8?
!--
 Licensed to the Apache Software Foundation (ASF) under one
 or more contributor license agreements.  See the NOTICE file
 distributed with this work for additional information
 regarding copyright ownership.  The ASF licenses this file
 to you under the Apache License, Version 2.0 (the
 License); you may not use this file except in compliance
 with the License.  You may obtain a copy of the License at
 
 http://www.apache.org/licenses/LICENSE-2.0
 
 Unless required by applicable law or agreed to in writing,
 software distributed under the License is distributed on an
 AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.   
--
project xmlns=http://maven.apache.org/POM/4.0.0; 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd;
 ...

albeit this a +1 for the content :)

txs and LieGrue,
strub


--- On Wed, 6/16/10, Leonardo Uribe lu4...@gmail.com wrote:

From: Leonardo Uribe lu4...@gmail.com
Subject: [VOTE] release for myfaces master pom v 8
To: MyFaces Development dev@myfaces.apache.org
Date: Wednesday, June 16, 2010, 6:10 PM

Hi,

I was running the needed tasks to get the version 8 release of Apache MyFaces 
Master POM.

Please note that this vote concerns all of the following parts:

 1. Maven artifact group org.apache.myfaces.myfaces v 8  [1]


The artifacts are deployed to my private Apache account [1].

Please take a look at the version 8 pom 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/myfaces8
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes

[jira] Resolved: (MYFACES-2754) MyFaces can attempt to create a new session after the response has been committed

[
https://issues.apache.org/jira/browse/MYFACES-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Concini resolved MYFACES-2754.
--

Fix Version/s: 2.0.1
Resolution: Fixed

MyFaces can attempt to create a new session after the response has been
committed
-

--
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 core 2.0.1

2010-06-16 Thread Michael Concini

Leonardo,
I just committed the proper fix for MYFACES-2754 now so as far as 2754
and 2755 we should be good to go.

-Mike
On 6/16/2010 1:52 PM, Leonardo Uribe wrote:

Hi Bernd

Ok, thanks. Unfortunately I have to restart all release steps, because
there was changes applied on trunk that should be applied, but I'm not
have a separate patch to apply it (MYFACES-2755, MYFACES-2754 is in
progress, TOMAHAWK).

We still have an unresolved problem with myfaces master pom v7
(checkstyle version is snapshot). Since myfaces core 2.0.x depends on
this pom and we don't have response from Matthias fix this issue, At
this point I have to release myfaces master pom first.

regards,

Leonardo Uribe

2010/6/16 Bernd Bohmann bernd.bohm...@googlemail.com
mailto:bernd.bohm...@googlemail.com

Hi Leonardo,

thanks a lot. Now it is ok for me.
I added some missing licenses on the 2.0.1 branch.

Regards

Bernd

On Tue, Jun 15, 2010 at 11:14 PM, Leonardo Uribe lu4...@gmail.com
mailto:lu4...@gmail.com wrote:
Hi Bernd

I added in api:

META-INF/licenses/dojo-LICENSE.TXT
META-INF/licenses/j4fry-LICENSE.TXT
META-INF/licenses/facelets-LICENSE.TXT

in impl

META-INF/licenses/glassfish-LICENSE.TXT
META-INF/licenses/facelets-LICENSE.TXT

because the schemas with CDDL license are on impl jar.

The update to NOTICE.txt message was committed too. Anyway to
prevent misunderstandings, I'll wait your response about it.

regards,

Leonardo Uribe

2010/6/15 Bernd Bohmann bernd.bohm...@atanion.com
mailto:bernd.bohm...@atanion.com

Hello Leonardo,

looks ok for me.

Can you also add in api

META-INF/licenses/dojo-LICENSE.TXT
META-INF/licenses/j4fry-LICENSE.TXT
META-INF/licenses/glassfish-LICENSE.TXT
META-INF/licenses/facelets-LICENSE.TXT

and in impl

META-INF/licenses/facelets-LICENSE.TXT

an example would be

http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/core/src/main/resources/META-INF/licenses/

I have no time to perform the required changes unit tomorrow
afternoon.

Regards

Bernd

On Tue, Jun 15, 2010 at 8:11 PM, Leonardo Uribe
lu4...@gmail.com mailto:lu4...@gmail.com wrote:
Hi

I think the NOTICE.txt file on impl module could be like this:

This product includes software developed by:
The Apache Software Foundation (http://www.apache.org/).

See the file LICENSE.txt
See licenses for accompanying products in the /licenses
subdirectory.

This software also includes code from Facelets
(https://facelets.dev.java.net/)
for the purpose of implementing Facelets PDL for JSF 2.0 support.

This product includes schema files developed for the
Glassfish Java EE
reference implementation (http://java.sun.com/xml/ns/j2ee/).
Apache Myfaces elects to include this software in this
distribution
under the CDDL license. You can obtain a copy of the License at:
https://glassfish.dev.java.net/public/CDDL+GPL.html
The source code is available at:
https://glassfish.dev.java.net/source/browse/glassfish/

The following schemas are included:

===
javaee_5.xsd
javaee_web_services_client_1_2.xsd
===

If no comments, I'll commit this fix tomorrow, regenerate all
artifacts and
start vote again.

regards,

Leonardo Uribe

2010/6/15 Leonardo Uribe lu4...@gmail.com
mailto:lu4...@gmail.com

Ok, let me know when all fixes has been applied, so I can
regenerate
(again) the artifacts.

To prevent misunderstandings, it is better to propose
another vote and
after that wait another 72 hours for release.

2010/6/15 Mike Kienenberger mkien...@gmail.com
mailto:mkien...@gmail.com

The licensing issue has to be fixed, if there is such an issue.
And Bernd needs to withdraw his -1 before we can release
using this vote.

On Tue, Jun 15, 2010 at 12:30 PM, Leonardo Uribe
lu4...@gmail.com mailto:lu4...@gmail.com
wrote:

2010/6/15 Mike Kienenberger mkien...@gmail.com
mailto:mkien...@gmail.com

At this point, should this discussion be moved out of
the voting
thread?

By the way, MyFaces can include CDDL xsd and dtd spec
files, so long
as they are appropriately documented.

http://www.apache.org/legal/resolved.html#category-b

So we can close this vote and continue

Re: [VOTE] release for myfaces core 2.0.1

That's cool! Thanks!. After release myfaces master pom v 8 I'll propose a
release of 2.0.1 again.

regards,

Leonardo

2010/6/16 Michael Concini mconc...@gmail.com

Leonardo,
I just committed the proper fix for MYFACES-2754 now so as far as 2754 and
2755 we should be good to go.

-Mike

On 6/16/2010 1:52 PM, Leonardo Uribe wrote:

Hi Bernd

Ok, thanks. Unfortunately I have to restart all release steps, because
there was changes applied on trunk that should be applied, but I'm not have
a separate patch to apply it (MYFACES-2755, MYFACES-2754 is in progress,
TOMAHAWK).

regards,

Leonardo Uribe

2010/6/16 Bernd Bohmann bernd.bohm...@googlemail.com

Hi Leonardo,

thanks a lot. Now it is ok for me.
I added some missing licenses on the 2.0.1 branch.

Regards

Bernd

On Tue, Jun 15, 2010 at 11:14 PM, Leonardo Uribe lu4...@gmail.com
wrote:
Hi Bernd

I added in api:

META-INF/licenses/dojo-LICENSE.TXT
META-INF/licenses/j4fry-LICENSE.TXT
META-INF/licenses/facelets-LICENSE.TXT

in impl

META-INF/licenses/glassfish-LICENSE.TXT
META-INF/licenses/facelets-LICENSE.TXT

because the schemas with CDDL license are on impl jar.

The update to NOTICE.txt message was committed too. Anyway to prevent
misunderstandings, I'll wait your response about it.

regards,

Leonardo Uribe

2010/6/15 Bernd Bohmann bernd.bohm...@atanion.com

Hello Leonardo,

looks ok for me.

Can you also add in api

META-INF/licenses/dojo-LICENSE.TXT
META-INF/licenses/j4fry-LICENSE.TXT
META-INF/licenses/glassfish-LICENSE.TXT
META-INF/licenses/facelets-LICENSE.TXT

and in impl

META-INF/licenses/facelets-LICENSE.TXT

an example would be

http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/core/src/main/resources/META-INF/licenses/

I have no time to perform the required changes unit tomorrow afternoon.

Regards

Bernd

On Tue, Jun 15, 2010 at 8:11 PM, Leonardo Uribe lu4...@gmail.com
wrote:
Hi

I think the NOTICE.txt file on impl module could be like this:

This product includes software developed by:
The Apache Software Foundation (http://www.apache.org/).

See the file LICENSE.txt
See licenses for accompanying products in the /licenses
subdirectory.

This software also includes code from Facelets
(https://facelets.dev.java.net/)
for the purpose of implementing Facelets PDL for JSF 2.0 support.

This product includes schema files developed for the Glassfish Java
EE
reference implementation (http://java.sun.com/xml/ns/j2ee/).
Apache Myfaces elects to include this software in this distribution
under the CDDL license. You can obtain a copy of the License at:
https://glassfish.dev.java.net/public/CDDL+GPL.html
The source code is available at:
https://glassfish.dev.java.net/source/browse/glassfish/

The following schemas are included:

===
javaee_5.xsd
javaee_web_services_client_1_2.xsd
===

If no comments, I'll commit this fix tomorrow, regenerate all
artifacts and
start vote again.

regards,

Leonardo Uribe

2010/6/15 Leonardo Uribe lu4...@gmail.com

Ok, let me know when all fixes has been applied, so I can regenerate
(again) the artifacts.

To prevent misunderstandings, it is better to propose another vote
and
after that wait another 72 hours for release.

2010/6/15 Mike Kienenberger mkien...@gmail.com

The licensing issue has to be fixed, if there is such an issue.
And Bernd needs to withdraw his -1 before we can release using this
vote.

On Tue, Jun 15, 2010 at 12:30 PM, Leonardo Uribe lu4...@gmail.com

wrote:

2010/6/15 Mike Kienenberger mkien...@gmail.com

At this point, should this discussion be moved out of the voting
thread?

By the way, MyFaces can include CDDL xsd and dtd spec files, so
long
as they are appropriately documented.

http://www.apache.org/legal/resolved.html#category-b

So we can close this vote and continue the release procedure,
right?

On Tue, Jun 15, 2010 at 12:02 PM, Leonardo Uribe
lu4...@gmail.com
wrote:
Hi

Those files were copied from tomcat project:

http://svn.apache.org/repos/asf/tomcat/trunk/java/javax/servlet/resources/

There is no mention in NOTICE file there.

regards,

Leonardo Uribe

2010/6/15 Bernd Bohmann bernd.bohm...@atanion.com

Hello,

the

Re: [VOTE] release for myfaces master pom v 8

Hi Mark

I have updated the pom to include the license header as suggested.

best regards,

Leonardo

2010/6/16 Mark Struberg strub...@yahoo.de

 Hi Leo!

 Again me :)

 Please allow me another question from an outside guy.

 I wondered if we should also add ASL headers to the MyFaces poms and other
 XMLs. I know that we have this in owb, bval, geronimo, openjpa, etc.
 So it at least seems to be a pretty common way to do it pom.xml:

 ?xml version=1.0 encoding=UTF-8?
 !--
  Licensed to the Apache Software Foundation (ASF) under one
  or more contributor license agreements.  See the NOTICE file
  distributed with this work for additional information
  regarding copyright ownership.  The ASF licenses this file
  to you under the Apache License, Version 2.0 (the
  License); you may not use this file except in compliance
  with the License.  You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing,
  software distributed under the License is distributed on an
  AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  KIND, either express or implied.  See the License for the
  specific language governing permissions and limitations
  under the License.
 --
 project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
 http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=
 http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
 
  ...

 albeit this a +1 for the content :)

 txs and LieGrue,
 strub


 --- On Wed, 6/16/10, Leonardo Uribe lu4...@gmail.com wrote:

 From: Leonardo Uribe lu4...@gmail.com
 Subject: [VOTE] release for myfaces master pom v 8
 To: MyFaces Development dev@myfaces.apache.org
 Date: Wednesday, June 16, 2010, 6:10 PM

 Hi,

 I was running the needed tasks to get the version 8 release of Apache
 MyFaces Master POM.

 Please note that this vote concerns all of the following parts:

  1. Maven artifact group org.apache.myfaces.myfaces v 8  [1]


 The artifacts are deployed to my private Apache account [1].

 Please take a look at the version 8 pom 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/myfaces8http://people.apache.org/%7Elu4242/myfaces8
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: [VOTE] release for myfaces master pom v 8

2010-06-16 Thread Werner Punz


+1

Am 16.06.10 20:11, schrieb Leonardo Uribe:

+1

2010/6/16 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com

Hi,

I was running the needed tasks to get the version 8 release of
Apache MyFaces Master POM.

Please note that this vote concerns all of the following parts:

  1. Maven artifact group org.apache.myfaces.myfaces v 8  [1]

The artifacts are deployed to my private Apache account [1].

Please take a look at the version 8 pom 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/myfaces8
http://people.apache.org/%7Elu4242/myfaces8
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes

[jira] Created: (TRINIDAD-1834) tr:showDetail prompt facet doesn't fire ActionEvents if it's closed

2010-06-16 Thread Markus Dreher (JIRA)

tr:showDetail prompt facet doesn't fire ActionEvents if it's closed
---

 Key: TRINIDAD-1834
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1834
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.13-core 
 Environment: mojarra 1.2_10, facelets 1.1.4, ext-val 1.2.3
Reporter: Markus Dreher


when I use a tr:commandLink in tr:showDetail prompt facet, the actionListener 
is only invoke when the component is disclosed.

tr:showDetail id=sdWeitereVornamen styleClass=showDetailInput
f:facet name=prompt
  tr:commandLink 
actionListener=#{einwohnerDetailsController.namensaenderung} 
id=namensaenderungLink
tr:image inlineStyle=width: 16px; height: 16px; source= 
/images/bearbeiten.png /
  /tr:commandLink
/f:facet  
...
/tr:showDetail

The actionlistener should also be invoked if it's closed. the same applies to 
input components and validators.

In processDecodes, (processUpdates, processValidators) in UIXShowDetail class
, facets and children will only be processed, if the components is disclosed. 
But facets should be processed in closed and disclosed state.


-- 
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 master pom v 8

2010-06-16 Thread Jakob Korherr

+1

Regards,
Jakob

2010/6/16 Werner Punz werner.p...@gmail.com

 +1

 Am 16.06.10 20:11, schrieb Leonardo Uribe:

 +1

 2010/6/16 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com


Hi,

I was running the needed tasks to get the version 8 release of
Apache MyFaces Master POM.

Please note that this vote concerns all of the following parts:

  1. Maven artifact group org.apache.myfaces.myfaces v 8  [1]

The artifacts are deployed to my private Apache account [1].

Please take a look at the version 8 pom 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/myfaces8http://people.apache.org/%7Elu4242/myfaces8
http://people.apache.org/%7Elu4242/myfaces8

[2] 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] Updated: (TOMAHAWK-1508) Find a way to convert between the model type required for the renderer, and the model-type that the backing-beans use for t:inputCalendar and t:inputDate


 [ 
https://issues.apache.org/jira/browse/TOMAHAWK-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leonardo Uribe updated TOMAHAWK-1508:
-

Status: Patch Available  (was: Open)

 Find a way to convert between the model type required for the renderer, and 
 the model-type that the backing-beans use for t:inputCalendar and t:inputDate
 -

 Key: TOMAHAWK-1508
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1508
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: Calendar, Date
Affects Versions: 1.1.9
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Attachments: TOMAHAWK-1508.patch


 From TOMAHAWK-1425:
 Hi Leonardo,
 I have always thought that JSF should add a business-converter for such 
 issues. So we should have a way to convert between the model type that we 
 need for the renderer, and the model-type that the backing-beans use.
 You could register such a converter on the input-component like the normal 
 converter, businessConverter= We could also cover stuff like the 
 joda-date with this.
 Eventually, we could even add a central registry for this in MyFaces where 
 you can register business-converters centrally and hence let the renderer 
 automatically retrieve such a a converter for the backing-bean datatype and 
 the datatype it needs.
 best regards,
 Martin 
 We'll explore this idea here

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TOMAHAWK-1508) Find a way to convert between the model type required for the renderer, and the model-type that the backing-beans use for t:inputCalendar and t:inputDate


[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12879593#action_12879593
 ] 

Leonardo Uribe commented on TOMAHAWK-1508:
--

I reviewed both components and the problem for use Converter interface reside 
in its design vs t:inputCalendar and t:inputDate requeriments. It has two 
problems:

- It assume submittedValue is always a String, but for t:inputDate that is not 
true. For this case as suggested, we need a property to give the chance to 
convert the java.util.Date instance used by the component to other type and 
viceversa.

- t:inputCalendar and t:inputDate requires a base date type to manipulate. In 
both cases is java.util.Date, but the boundaries between the base date type and 
the business type are not clear. For example, in jdk 1.6 java.sql.Date that 
extends from java.util.Date override some methods and makes t:inputCalendar and 
t:inputDate fail. To show the point, i did a small example and the exception 
thrown was:

javax.faces.FacesException: Exception while setting value for expression : 
#{calendarBean.thirdDate} of component with path : {Component-Path : [Class: 
javax.faces.component.UIViewRoot,ViewId: /calendar.jsp][Class: 
javax.faces.component.html.HtmlPanelGroup,Id: body][Class: 
javax.faces.component.html.HtmlForm,Id: calendarForm2][Class: 
org.apache.myfaces.custom.calendar.HtmlInputCalendar,Id: thirdOne]}
at 
javax.faces.component.UIInput.queueExceptionInRequest(UIInput.java:371)
at javax.faces.component.UIInput.updateModel(UIInput.java:353)
at javax.faces.component.UIInput.processUpdates(UIInput.java:258)
at javax.faces.component.UIForm.processUpdates(UIForm.java:127)
at 
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:799)
at 
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:799)

Caused by: java.lang.IllegalArgumentException: Cannot convert 17/06/10 12:00 AM 
of type class java.util.Date to class java.sql.Date
at com.sun.el.lang.ELSupport.coerceToType(ELSupport.java:381)
at com.sun.el.parser.AstValue.setValue(AstValue.java:164)
at com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:269)
at javax.faces.component.UIInput.updateModel(UIInput.java:336)

In TOMAHAWK-1508.patch there is a proposal to solve this problem. The idea is 
create an interface called DateBusinessConverter with two methods:

public Object getBusinessValue(FacesContext context,
   UIComponent component,
   java.util.Date value);

public java.util.Date getDateValue(FacesContext context,
   UIComponent component,
   Object value);

The idea is use getBusinessValue() to convert the java.util.Date instance 
calculated from submittedValue, so the resulting object will be used later as 
the converted value and validation.

Then, getDateValue() is used to retrieve the value stored in the business bean 
and convert it in a representation that t:inputCalendar and t:inputDate can 
manipulate.

The default DateBusinessConverter has this code:

public Object getBusinessValue(FacesContext context, UIComponent component,
Date value)
{
ValueBinding vb = component.getValueBinding(value);
Class type = vb.getType(context); 
if (type != null)
{
if (java.sql.Date.class.isAssignableFrom(type))
{
return new java.sql.Date(value.getTime());
}
}
return value;
}

public Date getDateValue(FacesContext context, UIComponent component,
Object value)
{
if (value instanceof java.sql.Date)
{
//Convert to strict java.util.Date
return new Date(((java.sql.Date)value).getTime());
}
return (Date) value;
}

In few words, it allows use java.util.Date and java.sql.Date in a better and 
more predictable way, so with this fix, both java.util.Date and java.sql.Date 
will supported out of the box.

To make this fix work, it is necessary to do proper stuff in jsp Tag class and 
facelet TagHandler. The property dateBusinessConverter works like this:

- If the value is literal, look for the mentioned class instance, create a new 
instance and assign to the component property.
- If it the value a EL Expression, set the expression to the component property.

I think we can enhance this approach in the future, but for now I think it is 
better to keep things simple, commit the code and in the future think about it.

If no objections I'll commit the code soon.

 Find a way to convert between the model type required for the renderer, and 
 the model-type that the backing-beans use for t:inputCalendar and t:inputDate

[jira] Resolved: (MYFACES-2756) @JSFProperty has inheritTag property, and it should be inheritedTag


 [ 
https://issues.apache.org/jira/browse/MYFACES-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leonardo Uribe resolved MYFACES-2756.
-

Resolution: Fixed

 @JSFProperty has inheritTag property, and it should be inheritedTag
 ---

 Key: MYFACES-2756
 URL: https://issues.apache.org/jira/browse/MYFACES-2756
 Project: MyFaces Core
  Issue Type: Bug
  Components: build process
Affects Versions: 2.0.0
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe

 Doing some stuff on tomahawk, I saw a typo error. The property inheritedTag 
 is used in tomahawk for jsf 1.1 and it is used on very special cases, when it 
 is necessary to override the default code added on a jsp tag. Since in 
 tomahawk for jsf 1.1 we use doclets that code fall out of the radar. The 
 solution is use the same name as in the doclets.
 With this commit I also added some attributes for @JSFJspProperty.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (MYFACES-2756) @JSFProperty has inheritTag property, and it should be inheritedTag

@JSFProperty has inheritTag property, and it should be inheritedTag
---

 Key: MYFACES-2756
 URL: https://issues.apache.org/jira/browse/MYFACES-2756
 Project: MyFaces Core
  Issue Type: Bug
  Components: build process
Affects Versions: 2.0.0
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Doing some stuff on tomahawk, I saw a typo error. The property inheritedTag is 
used in tomahawk for jsf 1.1 and it is used on very special cases, when it is 
necessary to override the default code added on a jsp tag. Since in tomahawk 
for jsf 1.1 we use doclets that code fall out of the radar. The solution is 
use the same name as in the doclets.

With this commit I also added some attributes for @JSFJspProperty.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TOMAHAWK-1521) ExtensionsFilter cacheFileSizeErrors Does Not Work As Advertised