date:20100831

Removal of YUI code due to project participants internal demand
---

 Key: MYFACES-2902
 URL: https://issues.apache.org/jira/browse/MYFACES-2902
 Project: MyFaces Core
  Issue Type: Improvement
Affects Versions: 2.0.2-SNAPSHOT
Reporter: Werner Punz


We have had one line of code coming from the YUI library, while from an ASF 
standpoint the code was clear, there was a wish from the IBM people involved in 
the project to remove it otherwise they needed legal clearance.
This issue will cover the commit, which was one line in the iFrame handling for 
the ajax fileupload which was introduced post 2.0.1.


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

[jira] Commented: (MYFACES-2458) Miscellaneous AJAX bugs

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

Werner Punz commented on MYFACES-2458:
--

Following issues have been fixed on my side:

* Possible issue with f:ajax execute=multiple ids. Seems the
javax.faces.partial.execute request param may differ from Sun RI
* Function _Lang.getEventTarget(...) fails to find form if event is one of ajax
events (e.g. 'error'). In this case event contains 'source' property, but
'srcElement' or 'target' is checked
* If calling jsf.ajax.request() directly and no options map is specified, the
XHR call never occurs because the options map evaluates to undefined.

Miscellaneous AJAX bugs
---

Key: MYFACES-2458
URL: https://issues.apache.org/jira/browse/MYFACES-2458
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-alpha-2
Reporter: Curtiss Howard
Priority: Minor

There are a couple minor AJAX-related bugs:
* h:commandButton needs to append return false; for onclick when a behavior
chain is present.
* if f:ajax disabled=true, the AJAX call is still emitted.
* Possible issue with f:ajax execute=multiple ids. Seems the
javax.faces.partial.execute request param may differ from Sun RI.
* Unable to restore StateHolder when listener is specified for f:ajax.
* f:ajax onevent not being handled.
* f:ajax onerror not being handled.
* f:ajax render=@all not working correctly.
* f:ajax render=@form not working correctly.
* f:ajax render=@this not working correctly.

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

Re: Building tomahawk for MyFaces 2.0

2010-08-31 Thread Jakob Korherr

+1 Mark.

Regards,
Jakob

2010/8/31 Mark Struberg strub...@yahoo.de

This might be one of the side effects of the new snapshots repo. We should
go through all our projects and deploy snapshot builds to this new
apache-snapshots repo.

LieGrue,
strub

--- On Tue, 8/31/10, Leonardo Uribe lu4...@gmail.com wrote:

From: Leonardo Uribe lu4...@gmail.com
Subject: Re: Building tomahawk for MyFaces 2.0
To: MyFaces Development dev@myfaces.apache.org
Date: Tuesday, August 31, 2010, 5:15 AM

Right now, tomahawk trunk depends on some other projects, so there are some
snapshot versions that makes build fail. The reason is we are working on all
those projects at the same time, but I hope to release one by one soon.

Try checkout and compile these projects in the same order:

(myfaces builder plugin, myfaces builder annotations, myfaces javascript
plugin)

http://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/trunk/maven2-plugins/

(myfaces test)
http://svn.apache.org/repos/asf/myfaces/test/trunk/

(myfaces core 2.0.x, myfaces shared 4.0.x)
http://svn.apache.org/repos/asf/myfaces/current20/

(tomahawk)
http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/

That should work. Anyway, I fixed a problem with hudson (continous
integration) that prevent deploy source snapshots, required to make tomahawk
compile and cause your problem.

best regards,

Leonardo Uribe

2010/8/30 Joe Black pelican5...@yahoo.com

Hi,

I am trying to build tomahawk that can be used with MyFaces 2.0. However, I
am not successful.

I am using Maven 2.2.1 to build. The error encountered is as follows:-

[INFO] [dependency:unpack {execution:
unpack-shared-impl-sources}]

[INFO] Configured Artifact:

org.apache.myfaces.shared:myfaces-shared-tomahawk:sources:4.0.3-SNAPSHOT:jar

Downloading:
http://repository.apache.org/snapshots/org/apache/myfaces/shared/myfaces-shared-tomahawk/4.0.3-SNAPSHOT/myfaces-shared-tomahawk-4.0.3-SNAPSHOT-sources.jar

[INFO] Unable to find resource

'org.apache.myfaces.ahared:myfaces-shared-tomahawk:jar:sources:4.0.3-SNAPSHOT'
in repository apache.snapshots (http://repository.apache.org/snapshots)

[INFO] -

[ERROR] BUILD ERROR

[INFO]

[INFO] Unable to find artifact

...

I can find the myfaces-shared-tomahawk-4.0.3-SNAPSHOT.jar but I cannot
find the sources jar.

Please help. I am also not well versed in Maven too.

rgds,

--
Jakob Korherr

blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at

[jira] Resolved: (MYFACES-2902) Removal of YUI code due to project participants internal demand


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

Werner Punz resolved MYFACES-2902.
--

Fix Version/s: 2.0.2-SNAPSHOT
   Resolution: Fixed

 Removal of YUI code due to project participants internal demand
 ---

 Key: MYFACES-2902
 URL: https://issues.apache.org/jira/browse/MYFACES-2902
 Project: MyFaces Core
  Issue Type: Improvement
Affects Versions: 2.0.2-SNAPSHOT
Reporter: Werner Punz
 Fix For: 2.0.2-SNAPSHOT


 We have had one line of code coming from the YUI library, while from an ASF 
 standpoint the code was clear, there was a wish from the IBM people involved 
 in the project to remove it otherwise they needed legal clearance.
 This issue will cover the commit, which was one line in the iFrame handling 
 for the ajax fileupload which was introduced post 2.0.1.

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

[jira] Commented: (TRINIDAD-195) Two requests at the same time throw an exception when the server just started

2010-08-31 Thread JIRA


[ 
https://issues.apache.org/jira/browse/TRINIDAD-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904606#action_12904606
 ] 

Matthias Weßendorf commented on TRINIDAD-195:
-

See also here:

http://markmail.org/message/xyf7wjwptojtnbk4

 Two requests at the same time throw an exception when the server just started
 -

 Key: TRINIDAD-195
 URL: https://issues.apache.org/jira/browse/TRINIDAD-195
 Project: MyFaces Trinidad
  Issue Type: Bug
 Environment: Running OC4J as App server
Reporter: Chris Eidhof
Priority: Minor

 1. Stop your current server
 2. Run a page. Make sure to do two request a the same time the first time you 
 request a page from the server
 3. See the error message:
 500 Internal Server Error
 java.lang.IllegalStateException: Factory already available for this class 
 loader.
 at 
 org.apache.myfaces.trinidad.context.RequestContextFactory.setFactory(RequestContextFactory.java:53)
 at 
 org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.init(GlobalConfiguratorImpl.java:376)
 at 
 org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:213)
 at 
 org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:124)
 at 
 org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
 at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) 
 ].server.http.EvermindFilterChain.doFilter(EvermindFilterChain.java:15)
 at 
 oracle.adfdemo.view.webapp.rich.RedirectFilter.doFilter(RedirectFilter.java:84)
 at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) 
 ].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:617)
 at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) 
 ].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:368)
 at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) 
 ].server.http.HttpRequestHandler.doDispatchRequest(HttpRequestHandler.java:882)
 at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) 
 ].server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:790)
 at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) 
 ].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:600)
 at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) 
 ].server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java:369)
 at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) 
 ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:160)
 at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) 
 ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:141)
 at 
 oracle.oc4j.network.ServerSocketReadHandler$ClientRunnable.run(ServerSocketReadHandler.java:275)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
 at java.lang.Thread.run(Thread.java:613) 

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

MyFaces archetypes release

2010-08-31 Thread Jakob Korherr

Hi guys,

I already wanted to do a MyFaces archetypes release a while back, but we
agreed on waiting for the next OpenWebBeans release. Now the vote for the
OWB release is already out, so I will start the release for MyFaces
archetypes next week.

If anyone would like to add a new archetype for any MyFaces subproject or
would like to update some versions in the current archetypes, now would be a
good time!

Thanks!

Regards,
Jakob

-- 
Jakob Korherr

blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at

Re: MyFaces archetypes release

2010-08-31 Thread Matthias Wessendorf

thanks for taking care of this!

-M

On Tue, Aug 31, 2010 at 2:53 PM, Jakob Korherr jakob.korh...@gmail.com wrote:
 Hi guys,

 I already wanted to do a MyFaces archetypes release a while back, but we
 agreed on waiting for the next OpenWebBeans release. Now the vote for the
 OWB release is already out, so I will start the release for MyFaces
 archetypes next week.

 If anyone would like to add a new archetype for any MyFaces subproject or
 would like to update some versions in the current archetypes, now would be a
 good time!

 Thanks!

 Regards,
 Jakob

 --
 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: Building tomahawk for MyFaces 2.0

2010-08-31 Thread Grant Smith

Can we do that automatically from the Hudson builds ?

On Tue, Aug 31, 2010 at 4:19 AM, Jakob Korherr jakob.korh...@gmail.comwrote:

+1 Mark.

Regards,
Jakob

2010/8/31 Mark Struberg strub...@yahoo.de

This might be one of the side effects of the new snapshots repo. We should
go through all our projects and deploy snapshot builds to this new
apache-snapshots repo.

LieGrue,
strub

--- On Tue, 8/31/10, Leonardo Uribe lu4...@gmail.com wrote:

From: Leonardo Uribe lu4...@gmail.com
Subject: Re: Building tomahawk for MyFaces 2.0
To: MyFaces Development dev@myfaces.apache.org
Date: Tuesday, August 31, 2010, 5:15 AM

Right now, tomahawk trunk depends on some other projects, so there are
some snapshot versions that makes build fail. The reason is we are working
on all those projects at the same time, but I hope to release one by one
soon.

Try checkout and compile these projects in the same order:

(myfaces builder plugin, myfaces builder annotations, myfaces javascript
plugin)

http://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/trunk/maven2-plugins/

(myfaces test)
http://svn.apache.org/repos/asf/myfaces/test/trunk/

(myfaces core 2.0.x, myfaces shared 4.0.x)
http://svn.apache.org/repos/asf/myfaces/current20/

(tomahawk)
http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/

That should work. Anyway, I fixed a problem with hudson (continous
integration) that prevent deploy source snapshots, required to make tomahawk
compile and cause your problem.

best regards,

Leonardo Uribe

2010/8/30 Joe Black pelican5...@yahoo.com

Hi,

I am trying to build tomahawk that can be used with MyFaces 2.0. However,
I am not successful.

I am using Maven 2.2.1 to build. The error encountered is as follows:-

[INFO] [dependency:unpack {execution:
unpack-shared-impl-sources}]

[INFO] Configured Artifact:

org.apache.myfaces.shared:myfaces-shared-tomahawk:sources:4.0.3-SNAPSHOT:jar

Downloading:
http://repository.apache.org/snapshots/org/apache/myfaces/shared/myfaces-shared-tomahawk/4.0.3-SNAPSHOT/myfaces-shared-tomahawk-4.0.3-SNAPSHOT-sources.jar

[INFO] Unable to find resource

'org.apache.myfaces.ahared:myfaces-shared-tomahawk:jar:sources:4.0.3-SNAPSHOT'
in repository apache.snapshots (http://repository.apache.org/snapshots)

[INFO] -

[ERROR] BUILD ERROR

[INFO]

[INFO] Unable to find artifact

...

I can find the myfaces-shared-tomahawk-4.0.3-SNAPSHOT.jar but I cannot
find the sources jar.

Please help. I am also not well versed in Maven too.

rgds,

--
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.

[jira] Created: (MYFACES-2903) ErrorPageWriter may try to write a null to the partialWriter if the exception message is null

2010-08-31 Thread Bruno Aranda (JIRA)

ErrorPageWriter may try to write a null to the partialWriter if the exception 
message is null
-

 Key: MYFACES-2903
 URL: https://issues.apache.org/jira/browse/MYFACES-2903
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.2-SNAPSHOT
Reporter: Bruno Aranda
Assignee: Bruno Aranda
Priority: Minor


When trying to handle an exception and write the output to the writer, if the 
cause and the message of an exception are null a NullPointerException is thrown 
(ErrorPageWriter,379).

Checking if the ex.getMessage() is not null will fix this problem.

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

[jira] Resolved: (MYFACES-2903) ErrorPageWriter may try to write a null to the partialWriter if the exception message is null

2010-08-31 Thread Bruno Aranda (JIRA)


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

Bruno Aranda resolved MYFACES-2903.
---

Fix Version/s: 2.0.2-SNAPSHOT
   Resolution: Fixed

 ErrorPageWriter may try to write a null to the partialWriter if the exception 
 message is null
 -

 Key: MYFACES-2903
 URL: https://issues.apache.org/jira/browse/MYFACES-2903
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.2-SNAPSHOT
Reporter: Bruno Aranda
Assignee: Bruno Aranda
Priority: Minor
 Fix For: 2.0.2-SNAPSHOT


 When trying to handle an exception and write the output to the writer, if the 
 cause and the message of an exception are null a NullPointerException is 
 thrown (ErrorPageWriter,379).
 Checking if the ex.getMessage() is not null will fix this problem.

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

[jira] Commented: (MYFACES-2876) Ajax Support in Mobile Browsers


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

Werner Punz commented on MYFACES-2876:
--

Ok now to basic blackberry 5 support, it came down to changing the global eval 
slightly and pushing the
namespace resolution to the method ie uses, the basic protocol testcases except 
for the viewroot handling now work, but there are still borderline testcases 
which fail, those will be investigated separately.



 Ajax Support in Mobile Browsers
 ---

 Key: MYFACES-2876
 URL: https://issues.apache.org/jira/browse/MYFACES-2876
 Project: MyFaces Core
  Issue Type: Bug
  Components: General, JSR-314
Affects Versions: 2.0.0-beta
 Environment: Windows Mobile 6.1, Blackberry 4.7
Reporter: Mamallan Uthaman

 In Windows Mobile (WM) 6.1 platform, f:ajax is converted into a full-page 
 submit instead of a PPR. The reason is unlike Webkit based mobile-browsers, 
 WM 6.1 or Blackberry (BB) 4.7 offers only a limited JavaScript-DOM support, 
 so we need to optimize MyFaces's Ajax mechanism to work around the 
 limitations of mobile browsers. I used the sample code below for testing.
 Facelets code:
 h:commandButton value=PPR
   f:ajax event=action render=second/
 /h:commandButton
 h:outputText value=#{item.date.seconds} id=second/
 Item.Java:
 import java.util.Date;
 public class Item {
   Date date;
   public void setDate(Date date) {
 this.date = date;
   }
   public Date getDate() {
 return new Date();
   }
 }
 faces-config:
 managed-bean
   managed-bean-nameitem/managed-bean-name
   managed-bean-classItem/managed-bean-class
   managed-bean-scoperequest/managed-bean-scope
 /managed-bean
 Also, in the case of  BB 4.7 , f:ajax can successfully send a PPR, but PPR 
 response is ignored. 

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

[jira] Commented: (TRINIDAD-1898) Stop using the TagSupport convenience class

2010-08-31 Thread JIRA


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904704#action_12904704
 ] 

Matthias Weßendorf commented on TRINIDAD-1898:
--

Added a TrinidadTagSupport (borrowed by Tomcat) that is NOT serializable;
also refactored those classes that inherit from (standard) TagSupport to now 
inherit from our fork

 Stop using the TagSupport convenience class
 ---

 Key: TRINIDAD-1898
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1898
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0.3-core
Reporter: Matthias Weßendorf
 Attachments: TrinidadTagSupport.patch


 The TagSupport convenience class does implement Serializable
 We should stop using the TagSupport convenience class, so that this bogus 
 Serializable doesn't show up.
 http://download-llnw.oracle.com/javaee/1.4/api/javax/servlet/jsp/tagext/TagSupport.html

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

FacesIO.js not using the Trinidad state-saving parameter

2010-08-31 Thread Michel Boivin

Hello,

Issue MYFACES-2160 (https://issues.apache.org/jira/browse/MYFACES-2160) was
originally raised because the state-saving request parameter
org.apache.myfaces.trinidad.faces.STATE was not checked by the
RestoreViewExecutor.

This caused command components to not trigger their associated action under
a Trinidad form, since the generated request was not interpreted as a
postback request.

Under MyFaces 1.1.7 (version under which the fix was implemented), the
FacesIO.js script (dojo extension) does not support the
org.apache.myfaces.trinidad.faces.STATE parameter. Since some AJAX
components (ex inputSuggestAjax) rely on this script, it renders some of the
ajax components non-functional under Trinidad.

I am then wondering:
1) Should FacesIO.js support the Trinidad state-saving parameter?
2) Should this be filed as an issue on JIRA.

Thank you for taking the time to answer.

-Mike

[VOTE] release for myfaces test 1.0.0

Hi,

I was running the needed tasks to get the 1.0.0 release of Apache
MyFaces Test out.

Please note that this vote concerns all of the following parts:
 1. Maven artifact group org.apache.myfaces.test v1.0.0  [1]

The artifacts are deployed to nexus repository [1].

The release notes could be found at [3].

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,
Leonardo Uribe

[1]
https://repository.apache.org/content/repositories/orgapachemyfaces-001/org/apache/myfaces/test/

https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes
[3]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951styleName=Htmlversion=12315294

Re: [VOTE] release for myfaces test 1.0.0

+1

2010/8/31 Leonardo Uribe lu4...@gmail.com

 Hi,

 I was running the needed tasks to get the 1.0.0 release of Apache
 MyFaces Test out.

 Please note that this vote concerns all of the following parts:
  1. Maven artifact group org.apache.myfaces.test v1.0.0  [1]

 The artifacts are deployed to nexus repository [1].

 The release notes could be found at [3].

 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,
 Leonardo Uribe

 [1]
 https://repository.apache.org/content/repositories/orgapachemyfaces-001/org/apache/myfaces/test/

 https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 [3]
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951styleName=Htmlversion=12315294

Re: [VOTE] release for myfaces test 1.0.0

2010-08-31 Thread Mark Struberg

+1

LieGrue,
strub

--- On Tue, 8/31/10, Leonardo Uribe lu4...@gmail.com wrote:

From: Leonardo Uribe lu4...@gmail.com
Subject: [VOTE] release for myfaces test 1.0.0
To: MyFaces Development dev@myfaces.apache.org
Date: Tuesday, August 31, 2010, 7:13 PM

Hi,

I was running the needed tasks to get the 1.0.0 release of Apache
MyFaces Test out.

Please note that this vote concerns all of the following parts:
 1. Maven artifact group org.apache.myfaces.test v1.0.0  [1]


The artifacts are deployed to nexus repository [1].

The release notes could be found at [3].

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,
Leonardo Uribe

[1] 
https://repository.apache.org/content/repositories/orgapachemyfaces-001/org/apache/myfaces/test/

    
https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes

[3] 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951styleName=Htmlversion=12315294

Re: [VOTE] release for myfaces test 1.0.0

2010-08-31 Thread Matthias Wessendorf

+1

On Tue, Aug 31, 2010 at 9:32 PM, Mark Struberg strub...@yahoo.de wrote:
 +1

 LieGrue,
 strub

 --- On Tue, 8/31/10, Leonardo Uribe lu4...@gmail.com wrote:

 From: Leonardo Uribe lu4...@gmail.com
 Subject: [VOTE] release for myfaces test 1.0.0
 To: MyFaces Development dev@myfaces.apache.org
 Date: Tuesday, August 31, 2010, 7:13 PM

 Hi,

 I was running the needed tasks to get the 1.0.0 release of Apache
 MyFaces Test out.

 Please note that this vote concerns all of the following parts:
  1. Maven artifact group org.apache.myfaces.test v1.0.0  [1]


 The artifacts are deployed to nexus repository [1].

 The release notes could be found at [3].

 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,
 Leonardo Uribe

 [1] 
 https://repository.apache.org/content/repositories/orgapachemyfaces-001/org/apache/myfaces/test/

     
 https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes

 [3] 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951styleName=Htmlversion=12315294











-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: [VOTE] release for myfaces test 1.0.0

2010-08-31 Thread Rudy De Busscher

+1

Seems that jira issues MYFACESTEST-19 and MYFACESTEST-20 don't have the
correct status. So they don't show up in the release notes.

regards
rudy.

On 31 August 2010 21:43, Matthias Wessendorf mat...@apache.org wrote:

 +1

 On Tue, Aug 31, 2010 at 9:32 PM, Mark Struberg strub...@yahoo.de wrote:
  +1
 
  LieGrue,
  strub
 
  --- On Tue, 8/31/10, Leonardo Uribe lu4...@gmail.com wrote:
 
  From: Leonardo Uribe lu4...@gmail.com
  Subject: [VOTE] release for myfaces test 1.0.0
  To: MyFaces Development dev@myfaces.apache.org
  Date: Tuesday, August 31, 2010, 7:13 PM
 
  Hi,
 
  I was running the needed tasks to get the 1.0.0 release of Apache
  MyFaces Test out.
 
  Please note that this vote concerns all of the following parts:
   1. Maven artifact group org.apache.myfaces.test v1.0.0  [1]
 
 
  The artifacts are deployed to nexus repository [1].
 
  The release notes could be found at [3].
 
  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,
  Leonardo Uribe
 
  [1]
 https://repository.apache.org/content/repositories/orgapachemyfaces-001/org/apache/myfaces/test/
 
 
 https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/
  [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 
  [3]
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951styleName=Htmlversion=12315294
 
 
 
 
 
 
 
 



 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf

Re: [VOTE] release for myfaces test 1.0.0

Hi

So we can close both of them as fixed?

regards,

2010/8/31 Rudy De Busscher rdebussc...@gmail.com

 +1

 Seems that jira issues MYFACESTEST-19 and MYFACESTEST-20 don't have the
 correct status. So they don't show up in the release notes.

 regards
 rudy.


 On 31 August 2010 21:43, Matthias Wessendorf mat...@apache.org wrote:

 +1

 On Tue, Aug 31, 2010 at 9:32 PM, Mark Struberg strub...@yahoo.de wrote:
  +1
 
  LieGrue,
  strub
 
  --- On Tue, 8/31/10, Leonardo Uribe lu4...@gmail.com wrote:
 
  From: Leonardo Uribe lu4...@gmail.com
  Subject: [VOTE] release for myfaces test 1.0.0
  To: MyFaces Development dev@myfaces.apache.org
  Date: Tuesday, August 31, 2010, 7:13 PM
 
  Hi,
 
  I was running the needed tasks to get the 1.0.0 release of Apache
  MyFaces Test out.
 
  Please note that this vote concerns all of the following parts:
   1. Maven artifact group org.apache.myfaces.test v1.0.0  [1]
 
 
  The artifacts are deployed to nexus repository [1].
 
  The release notes could be found at [3].
 
  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,
  Leonardo Uribe
 
  [1]
 https://repository.apache.org/content/repositories/orgapachemyfaces-001/org/apache/myfaces/test/
 
 
 https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/
  [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 
  [3]
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951styleName=Htmlversion=12315294
 
 
 
 
 
 
 
 



 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf

Re: [VOTE] release for myfaces test 1.0.0

2010-08-31 Thread Rudy De Busscher

Yes, they can be set as fixed.


On 31 August 2010 22:19, Leonardo Uribe lu4...@gmail.com wrote:

 Hi

 So we can close both of them as fixed?

 regards,

 2010/8/31 Rudy De Busscher rdebussc...@gmail.com

 +1

 Seems that jira issues MYFACESTEST-19 and MYFACESTEST-20 don't have the
 correct status. So they don't show up in the release notes.

 regards
 rudy.


 On 31 August 2010 21:43, Matthias Wessendorf mat...@apache.org wrote:

 +1

 On Tue, Aug 31, 2010 at 9:32 PM, Mark Struberg strub...@yahoo.de
 wrote:
  +1
 
  LieGrue,
  strub
 
  --- On Tue, 8/31/10, Leonardo Uribe lu4...@gmail.com wrote:
 
  From: Leonardo Uribe lu4...@gmail.com
  Subject: [VOTE] release for myfaces test 1.0.0
  To: MyFaces Development dev@myfaces.apache.org
  Date: Tuesday, August 31, 2010, 7:13 PM
 
  Hi,
 
  I was running the needed tasks to get the 1.0.0 release of Apache
  MyFaces Test out.
 
  Please note that this vote concerns all of the following parts:
   1. Maven artifact group org.apache.myfaces.test v1.0.0  [1]
 
 
  The artifacts are deployed to nexus repository [1].
 
  The release notes could be found at [3].
 
  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,
  Leonardo Uribe
 
  [1]
 https://repository.apache.org/content/repositories/orgapachemyfaces-001/org/apache/myfaces/test/
 
 
 https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/
  [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 
  [3]
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951styleName=Htmlversion=12315294
 
 
 
 
 
 
 
 



 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf

Re: [VOTE] release for myfaces test 1.0.0

Ok, done

2010/8/31 Rudy De Busscher rdebussc...@gmail.com

 Yes, they can be set as fixed.



 On 31 August 2010 22:19, Leonardo Uribe lu4...@gmail.com wrote:

 Hi

 So we can close both of them as fixed?

 regards,

 2010/8/31 Rudy De Busscher rdebussc...@gmail.com

 +1

 Seems that jira issues MYFACESTEST-19 and MYFACESTEST-20 don't have the
 correct status. So they don't show up in the release notes.

 regards
 rudy.


 On 31 August 2010 21:43, Matthias Wessendorf mat...@apache.org wrote:

 +1

 On Tue, Aug 31, 2010 at 9:32 PM, Mark Struberg strub...@yahoo.de
 wrote:
  +1
 
  LieGrue,
  strub
 
  --- On Tue, 8/31/10, Leonardo Uribe lu4...@gmail.com wrote:
 
  From: Leonardo Uribe lu4...@gmail.com
  Subject: [VOTE] release for myfaces test 1.0.0
  To: MyFaces Development dev@myfaces.apache.org
  Date: Tuesday, August 31, 2010, 7:13 PM
 
  Hi,
 
  I was running the needed tasks to get the 1.0.0 release of Apache
  MyFaces Test out.
 
  Please note that this vote concerns all of the following parts:
   1. Maven artifact group org.apache.myfaces.test v1.0.0  [1]
 
 
  The artifacts are deployed to nexus repository [1].
 
  The release notes could be found at [3].
 
  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,
  Leonardo Uribe
 
  [1]
 https://repository.apache.org/content/repositories/orgapachemyfaces-001/org/apache/myfaces/test/
 
 
 https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/
  [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 
  [3]
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951styleName=Htmlversion=12315294
 
 
 
 
 
 
 
 



 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf

[VOTE] release for myfaces builder plugin 1.0.7

Hi,

I was running the needed tasks to get the 1.0.7 release of Apache
MyFaces Builder Plugin out.

This release includes some minor changes necessary to build myfaces
core 2.0.x, like the update to Qdox 1.12, a new goal for javascript plugin
to compress directories and put in a alternate location, and a typo error
in an annotation in myfaces builder annotations.

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.7 [1]
 2. Maven artifact group org.apache.myfaces.buildtools artifact
myfaces-builder-annotations v1.0.6 [1]
 3. Maven artifact group org.apache.myfaces.buildtools artifact
myfaces-javascript-plugin v1.0.2  [1]
 4. Maven artifact group org.apache.myfaces.buildtools artifact
myfaces-plugin-parent v1.0.4  [1]

The artifacts were deployed to a nexus repository ([1]).

Please take a look at the 1.0.7 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-003/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/BuilderPluginRelease107

Re: [VOTE] release for myfaces builder plugin 1.0.7

+1

2010/8/31 Leonardo Uribe lu4...@gmail.com

 Hi,

 I was running the needed tasks to get the 1.0.7 release of Apache
 MyFaces Builder Plugin out.

 This release includes some minor changes necessary to build myfaces
 core 2.0.x, like the update to Qdox 1.12, a new goal for javascript plugin
 to compress directories and put in a alternate location, and a typo error
 in an annotation in myfaces builder annotations.

 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.7 [1]
  2. Maven artifact group org.apache.myfaces.buildtools artifact
 myfaces-builder-annotations v1.0.6 [1]
  3. Maven artifact group org.apache.myfaces.buildtools artifact
 myfaces-javascript-plugin v1.0.2  [1]
  4. Maven artifact group org.apache.myfaces.buildtools artifact
 myfaces-plugin-parent v1.0.4  [1]

 The artifacts were deployed to a nexus repository ([1]).

 Please take a look at the 1.0.7 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-003/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/BuilderPluginRelease107

[jira] Resolved: (MYFACES-2896) PartialViewContextImpl ignores executeIds/renderIds/renderAll of wrapping PartialViewContext


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

Leonardo Uribe resolved MYFACES-2896.
-

 Assignee: Leonardo Uribe
Fix Version/s: 2.0.2-SNAPSHOT
   Resolution: Fixed

Yes, it is true. For allow override those methods it is required to call them 
getting the current partialViewContext instance first

 PartialViewContextImpl ignores executeIds/renderIds/renderAll of wrapping 
 PartialViewContext
 

 Key: MYFACES-2896
 URL: https://issues.apache.org/jira/browse/MYFACES-2896
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.2-SNAPSHOT
Reporter: Nick Belaevski
Assignee: Leonardo Uribe
 Fix For: 2.0.2-SNAPSHOT


 When PartialViewContextImpl#processPartial(PhaseId phaseId) is executed, 
 executeIds/renderIds/renderAll of wrapping PartialViewContext are ignored: 
 this.getRenderIds() etc are called instead of calling 
 _facesContext.getPartialViewContext().getExecuteIds() like is done for 
 PartialResponseWriter. 

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

[jira] Updated: (MYFACES-2774) Remove MARK_DELETED attribute from the component


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

Leonardo Uribe updated MYFACES-2774:


   Status: Resolved  (was: Patch Available)
 Assignee: Leonardo Uribe
Fix Version/s: 2.0.2-SNAPSHOT
   Resolution: Fixed

After checking in deep this patch, I found that the most expensive operation is 
finalizeForDeletion, because per each component it traverse all components in 
the previous level just to found it and remove it.

Instead, it is better to use a ListMapString, UIComponent for several 
reasons:

 - It is possible to reuse the map on each level (use an ArrayList is better 
over LinkedList).
 - In this case we need random access for finalizeForDeletion, and use a Map 
works best.
 - the key could be MARK_CREATED attribute, because all components with a 
facelet taghandler has it, and if a component does not have it there is no 
problem.

Also, I think the included methods on FaceletCompositionContext are too tied to 
the implementation detail of the algorithm. Instead, it is better to add just 
two methods:

public abstract void markForDeletion(UIComponent component)
public abstract void finalizeForDeletion(UIComponent component)

and the remaining methods call them in a private way.

I also solved a bug when more that one component is added to a facet:

h:form id=form
f:facet name=header
   c:if test=#{employee.management}
 h:commandButton id=button1 action=test rendered=#{true}/
 h:commandButton id=button2 action=test rendered=#{true}/
   /c:if
/f:facet
/h:form

That notation was invalid on facelets 1.1.x but on jsf 2.0, with the 
introduction of f:metadata, which it is a facet that could contain many 
components, the previous code becomes valid and should be handled properly.

Thanks to Marius Petoi for its help with this issue. It was very hard to solve 
it.

 Remove MARK_DELETED attribute from the component
 

 Key: MYFACES-2774
 URL: https://issues.apache.org/jira/browse/MYFACES-2774
 Project: MyFaces Core
  Issue Type: Improvement
  Components: General, JSR-314
Affects Versions: 2.0.0
Reporter: Marius Petoi
Assignee: Leonardo Uribe
Priority: Minor
 Fix For: 2.0.2-SNAPSHOT

 Attachments: markDeletedFaceletContext.patch, 
 markDeletedFaceletContext11.patch, markDeletedFaceletContext2.patch, 
 markDeletedFaceletContext3.patch, markDeletedFaceletContext4.patch, 
 markDeletedFaceletContext5.patch, markDeletedFaceletContext6.patch, 
 markDeletedFaceletContext7.patch, markDeletedFaceletContext8.patch, 
 markDeletedFaceletContext9.patch


 The ComponentSupport.MARK_DELETED attribute is used only inside one request. 
 It doesn't need to be saved in the state. It should be removed from the 
 attributes of the component. Instead a list of components marked for deletion 
 should be included in the FaceletContext.

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

[jira] Created: (TRINIDAD-1899) SessionChangeManager performance and behavior improvements

2010-08-31 Thread Blake Sullivan (JIRA)

SessionChangeManager performance and behavior improvements
--

 Key: TRINIDAD-1899
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1899
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 1.2.14-core , 2.0.0.3-core
Reporter: Blake Sullivan
Assignee: Blake Sullivan


Currently the SessionChangeManager when working with JSPs maintains a single 
list of changes to be applied and applies them in order.  While the list does 
support collapsing attribute changes even across component moves, this approach 
has some performance limitations in and of itself and decreases our ability to 
make other performance improvements:

1) Because some changes affect multiple components, we wait to the end of the 
document tag to apply the changes (so that all components exist).  
Unfortunately this means that when the tags are executing, they don't actually 
have any values that were modified by a change available to them.  This 
prevents us from applying optimizations where we don't even execute the tags 
that are subtrees that won't be visited by the lifecycle (for example 
undisclosed tabs).  

2) Because the changes are not applied at the time of tag execution, we need to 
do a separate findComponent() for each change that we want to apply.  This can 
get expensive for large numbers of changes.


The solution is to group changes into
1) Changes that apply to a single component
a) Collapsible single changes
2) Cross component changes
a) Cross component changes that can change the identity of a component

1) Changes that are applied to a single component are saved under the 
component's original scoped identifier.  The collapsible changes are collapsed.
2) Cross component changes are maintained in a single page wide list
3) Cross component changes that change the identify of a component update a 
mapping from the new (current scoped identifier) for the component to the 
original scoped identifier so that as new changes are applied, they are applied 
to the correct entry in 1)
4) For efficiency, the serialized form of the changes is a single list of 
changes with all collapsible entries collapsed, even across changes that change 
the identity.  The rename maps and a single component changes can be rebuilt on 
demand from this list.

The upshot of these changes are that:

1) We can apply all of the single component changes to a component at tag 
execution time, even if that component had a change that moved it.  This opens 
up optimizations where we don't execute child tags

2) Since all collapsible changes, like attribute changes are collapsed, we have 
fewer changes to apply

3) Only the rare, cross-component changes need to be applied using separate 
findComponent calls

To apply the changes at tag execution time, we need a new api on ChangeManager:

  /**
   * Apply non-cross-component changes to a component in its original location. 
 This is typically
   * only called by tags that need to ensure that a newly created component 
instance is
   * as up-to-date as possible.
   * @param context
   * @param component Component to apply the simple changes to
   */
  public void applySimpleComponentChanges(FacesContext context, UIComponent 
component)



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

[Trinidad][api]SessionChangeManager performance and behavior improvements:Jira-1899

2010-08-31 Thread Blake Sullivan

 JIRA 1899 https://issues.apache.org/jira/browse/TRINIDAD-1899 
describes the following:


Currently the SessionChangeManager when working with JSPs maintains a 
single list of changes to be applied and applies them in order. While 
the list does support collapsing attribute changes even across component 
moves, this approach has some performance limitations in and of itself 
and decreases our ability to make other performance improvements:


1) Because some changes affect multiple components, we wait to the end 
of the document tag to apply the changes (so that all components exist). 
Unfortunately this means that when the tags are executing, they don't 
actually have any values that were modified by a change available to 
them. This prevents us from applying optimizations where we don't even 
execute the tags that are subtrees that won't be visited by the 
lifecycle (for example undisclosed tabs).


2) Because the changes are not applied at the time of tag execution, we 
need to do a separate findComponent() for each change that we want to 
apply. This can get expensive for large numbers of changes.



The solution is to group changes into
1) Changes that apply to a single component
a) Collapsible single changes
2) Cross component changes
a) Cross component changes that can change the identity of a component

1) Changes that are applied to a single component are saved under the 
component's original scoped identifier. The collapsible changes are 
collapsed.

2) Cross component changes are maintained in a single page wide list
3) Cross component changes that change the identify of a component 
update a mapping from the new (current scoped identifier) for the 
component to the original scoped identifier so that as new changes are 
applied, they are applied to the correct entry in 1)
4) For efficiency, the serialized form of the changes is a single list 
of changes with all collapsible entries collapsed, even across changes 
that change the identity. The rename maps and a single component changes 
can be rebuilt on demand from this list.


The upshot of these changes are that:

1) We can apply all of the single component changes to a component at 
tag execution time, even if that component had a change that moved it. 
This opens up optimizations where we don't execute child tags


2) Since all collapsible changes, like attribute changes are collapsed, 
we have fewer changes to apply


3) Only the rare, cross-component changes need to be applied using 
separate findComponent calls


To apply the changes at tag execution time, we need a new api on 
ChangeManager:


  /**
   * Apply non-cross-component changes to a component in its original 
location. This is typically
   * only called by tags that need to ensure that a newly created 
component instance is

   * as up-to-date as possible.
   * @param context
   * @param component Component to apply the simple changes to
   */
  public void applySimpleComponentChanges(FacesContext context, 
UIComponent component)


-- Blake Sullivan

[jira] Resolved: (MYFACES-2887) IllegalAccessException restoring custom behavior state


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

Leonardo Uribe resolved MYFACES-2887.
-

 Assignee: Leonardo Uribe
Fix Version/s: 2.0.2-SNAPSHOT
   Resolution: Fixed

It is an error on BehaviorBase. Thanks for the example, it helps a lot.

 IllegalAccessException restoring custom behavior state
 --

 Key: MYFACES-2887
 URL: https://issues.apache.org/jira/browse/MYFACES-2887
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.2-SNAPSHOT
Reporter: Nick Belaevski
Assignee: Leonardo Uribe
 Fix For: 2.0.2-SNAPSHOT

 Attachments: jsf2test.zip


 See test project attached. Clicking link leads to:
 20.08.2010 13:58:41 org.apache.myfaces.renderkit.ErrorPageWriter 
 handleThrowable
 SEVERE: An exception occurred
 javax.faces.FacesException: java.lang.RuntimeException: 
 java.lang.IllegalAccessException: Class javax.faces.component.UIComponentBase 
 can not access a member of class javax.faces.component.behavior._DeltaList 
 with modifiers public
   at 
 org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241)
   at 
 org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156)
   at 
 org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:191)
   at 
 org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)
   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
   at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
   at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
   at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
   at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
   at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
   at 
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
   at 
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
   at 
 org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
   at java.lang.Thread.run(Thread.java:619)
 Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException: 
 Class javax.faces.component.UIComponentBase can not access a member of class 
 javax.faces.component.behavior._DeltaList with modifiers public
   at 
 javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1607)
   at 
 javax.faces.component.behavior.BehaviorBase.restoreState(BehaviorBase.java:126)
   at 
 javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1615)
   at javax.faces.component._DeltaList.restoreState(_DeltaList.java:251)
   at 
 javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1615)
   at 
 javax.faces.component.UIComponentBase.restoreFullBehaviorsMap(UIComponentBase.java:1790)
   at 
 javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:1742)
   at 
 javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1385)
   at 
 javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1428)
   at 
 javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1428)
   at 
 javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1428)
   at 
 javax.faces.component.UIViewRoot.processRestoreState(UIViewRoot.java:680)
   at 
 org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:418)
   at 
 org.apache.myfaces.shared_impl.view.ViewDeclarationLanguageBase.restoreView(ViewDeclarationLanguageBase.java:106)
   at 
 org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.restoreView(FaceletViewDeclarationLanguage.java:1277)
   at 
 org.apache.myfaces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:278)
   at 
 org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:123)
   at 
 org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:171)
   ... 14 more
 Caused by: java.lang.IllegalAccessException: Class 
 javax.faces.component.UIComponentBase can not access a member of class

[jira] Resolved: (MYFACES-2895) Messages component cannot be updated by ajax without wrapping it