[VOTE] Extensions-Scripting Alpha

2010-02-02 Thread Werner Punz 
Hello everyone, I have been feature complete since last week for the 
alpha release. So I want to start the vote for the Ext-Scripting Alpha 1.



Feature summary:


The planned Spring part will not make it into the official 1.0 release
since works on dependency injection frameworks which can provide beans 
over the EL will become integral part post 1.0 (my plan is to also go 
the CDI route if the frameworks permit it),the spring reloading it will 
be merged over time, but will not be part of the official 1.0.



So for now 1.0 will only support JSF and JSF only, but that extensively.

Since I am feature complete and relatively bugfree all the work from now 
on will go into bugfixing and code cleanup (believe me some parts really 
need that)


Here is a short compressed summary of what will go into the alpha 1.0 
and later final version:


Dynamic loading of all JSF 1.2 artifacts, including Application and 
Session scoped beans (lots of work went into this area to enable that)


Dynamic loading of most JSF 2.0 artifacts (application events currently 
are not supported)


Dynamic JSF2 annotation support (aka push annoations into existing 
classes move them around as you wish)


Dynamic resource loading within JSF2 (aka load resources from your 
source path)


Dynamic XHTML loading for Facelets (load your xhtml templates directly 
from your sourcepath)


And all of this for Groovy and Java

The documentation will be hosted on the Wiki for the time being and is a 
work in progress, but enough material already is there to justify an 
alpha release as well:


http://wiki.apache.org/myfaces/Extensions/Scripting

As I said, feature freeze for now, and all which will go into the alphas 
and betas will be code cleanup and bugfixes to get a 1.0 release out 
sometime around March.




Werner

Re: [VOTE] Extensions-Scripting Alpha

2010-02-02 Thread Matthias Wessendorf 
+1 on doing an alpha

On Tue, Feb 2, 2010 at 9:26 AM, Werner Punz werner.p...@gmail.com wrote:
 Hello everyone, I have been feature complete since last week for the alpha
 release. So I want to start the vote for the Ext-Scripting Alpha 1.


 Feature summary:


 The planned Spring part will not make it into the official 1.0 release
 since works on dependency injection frameworks which can provide beans over
 the EL will become integral part post 1.0 (my plan is to also go the CDI
 route if the frameworks permit it),the spring reloading it will be merged
 over time, but will not be part of the official 1.0.


 So for now 1.0 will only support JSF and JSF only, but that extensively.

 Since I am feature complete and relatively bugfree all the work from now on
 will go into bugfixing and code cleanup (believe me some parts really need
 that)

 Here is a short compressed summary of what will go into the alpha 1.0 and
 later final version:

 Dynamic loading of all JSF 1.2 artifacts, including Application and Session
 scoped beans (lots of work went into this area to enable that)

 Dynamic loading of most JSF 2.0 artifacts (application events currently are
 not supported)

 Dynamic JSF2 annotation support (aka push annoations into existing classes
 move them around as you wish)

 Dynamic resource loading within JSF2 (aka load resources from your source
 path)

 Dynamic XHTML loading for Facelets (load your xhtml templates directly from
 your sourcepath)

 And all of this for Groovy and Java

 The documentation will be hosted on the Wiki for the time being and is a
 work in progress, but enough material already is there to justify an alpha
 release as well:

 http://wiki.apache.org/myfaces/Extensions/Scripting

 As I said, feature freeze for now, and all which will go into the alphas and
 betas will be code cleanup and bugfixes to get a 1.0 release out sometime
 around March.



 Werner





-- 
Matthias Wessendorf

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

Re: [VOTE] Extensions-Scripting Alpha

2010-02-02 Thread Gerhard Petracek 
+1

regards,
gerhard

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces


2010/2/2 Matthias Wessendorf mat...@apache.org

 +1 on doing an alpha

 On Tue, Feb 2, 2010 at 9:26 AM, Werner Punz werner.p...@gmail.com wrote:
  Hello everyone, I have been feature complete since last week for the
 alpha
  release. So I want to start the vote for the Ext-Scripting Alpha 1.
 
 
  Feature summary:
 
 
  The planned Spring part will not make it into the official 1.0 release
  since works on dependency injection frameworks which can provide beans
 over
  the EL will become integral part post 1.0 (my plan is to also go the CDI
  route if the frameworks permit it),the spring reloading it will be merged
  over time, but will not be part of the official 1.0.
 
 
  So for now 1.0 will only support JSF and JSF only, but that extensively.
 
  Since I am feature complete and relatively bugfree all the work from now
 on
  will go into bugfixing and code cleanup (believe me some parts really
 need
  that)
 
  Here is a short compressed summary of what will go into the alpha 1.0 and
  later final version:
 
  Dynamic loading of all JSF 1.2 artifacts, including Application and
 Session
  scoped beans (lots of work went into this area to enable that)
 
  Dynamic loading of most JSF 2.0 artifacts (application events currently
 are
  not supported)
 
  Dynamic JSF2 annotation support (aka push annoations into existing
 classes
  move them around as you wish)
 
  Dynamic resource loading within JSF2 (aka load resources from your source
  path)
 
  Dynamic XHTML loading for Facelets (load your xhtml templates directly
 from
  your sourcepath)
 
  And all of this for Groovy and Java
 
  The documentation will be hosted on the Wiki for the time being and is a
  work in progress, but enough material already is there to justify an
 alpha
  release as well:
 
  http://wiki.apache.org/myfaces/Extensions/Scripting
 
  As I said, feature freeze for now, and all which will go into the alphas
 and
  betas will be code cleanup and bugfixes to get a 1.0 release out sometime
  around March.
 
 
 
  Werner
 
 



 --
 Matthias Wessendorf

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

release notes for myfaces core

2010-02-02 Thread Matthias Wessendorf 
Hello,

our download page:
http://myfaces.apache.org/download.html

does not talk about the release notes. For Trinidad
we provide the latest release notes along the download info;

Do we want that for MyFaces core as well ?

I'd say yes...


Yeah, I will add them... ;)

-- 
Matthias Wessendorf

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

Re: [VOTE] Extensions-Scripting Alpha

2010-02-02 Thread Cagatay Civici 
+1,

regards,

Cagatay

On Tue, Feb 2, 2010 at 8:36 AM, Gerhard Petracek gerhard.petra...@gmail.com
 wrote:

 +1

 regards,
 gerhard

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces


 2010/2/2 Matthias Wessendorf mat...@apache.org

 +1 on doing an alpha

 On Tue, Feb 2, 2010 at 9:26 AM, Werner Punz werner.p...@gmail.com
 wrote:
  Hello everyone, I have been feature complete since last week for the
 alpha
  release. So I want to start the vote for the Ext-Scripting Alpha 1.
 
 
  Feature summary:
 
 
  The planned Spring part will not make it into the official 1.0 release
  since works on dependency injection frameworks which can provide beans
 over
  the EL will become integral part post 1.0 (my plan is to also go the CDI
  route if the frameworks permit it),the spring reloading it will be
 merged
  over time, but will not be part of the official 1.0.
 
 
  So for now 1.0 will only support JSF and JSF only, but that extensively.
 
  Since I am feature complete and relatively bugfree all the work from now
 on
  will go into bugfixing and code cleanup (believe me some parts really
 need
  that)
 
  Here is a short compressed summary of what will go into the alpha 1.0
 and
  later final version:
 
  Dynamic loading of all JSF 1.2 artifacts, including Application and
 Session
  scoped beans (lots of work went into this area to enable that)
 
  Dynamic loading of most JSF 2.0 artifacts (application events currently
 are
  not supported)
 
  Dynamic JSF2 annotation support (aka push annoations into existing
 classes
  move them around as you wish)
 
  Dynamic resource loading within JSF2 (aka load resources from your
 source
  path)
 
  Dynamic XHTML loading for Facelets (load your xhtml templates directly
 from
  your sourcepath)
 
  And all of this for Groovy and Java
 
  The documentation will be hosted on the Wiki for the time being and is a
  work in progress, but enough material already is there to justify an
 alpha
  release as well:
 
  http://wiki.apache.org/myfaces/Extensions/Scripting
 
  As I said, feature freeze for now, and all which will go into the alphas
 and
  betas will be code cleanup and bugfixes to get a 1.0 release out
 sometime
  around March.
 
 
 
  Werner
 
 



 --
 Matthias Wessendorf

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





-- 
Cagatay Civici
JSF EG | PrimeFaces Lead | Apache MyFaces PMC
http://www.primefaces.org

Re: [VOTE] Extensions-Scripting Alpha

2010-02-02 Thread Mark Struberg 
Hi Werner!

Not sure if this is needed in your case, but the pom in 
extensions/scripting/trunk doesn't contain a parent section.

Usually this points (in the end) to
parent
groupIdorg.apache/groupId
artifactIdapache/artifactId
version6/version
/parent

for all Apache projects.

LieGrue,
strub

--- On Tue, 2/2/10, Werner Punz werner.p...@gmail.com wrote:

 From: Werner Punz werner.p...@gmail.com
 Subject: [VOTE] Extensions-Scripting Alpha
 To: dev@myfaces.apache.org
 Date: Tuesday, February 2, 2010, 9:26 AM
 Hello everyone, I have been feature
 complete since last week for the alpha release. So I want to
 start the vote for the Ext-Scripting Alpha 1.
 
 
 Feature summary:
 
 
 The planned Spring part will not make it into the official
 1.0 release
 since works on dependency injection frameworks which can
 provide beans over the EL will become integral part post 1.0
 (my plan is to also go the CDI route if the frameworks
 permit it),the spring reloading it will be merged over time,
 but will not be part of the official 1.0.
 
 
 So for now 1.0 will only support JSF and JSF only, but that
 extensively.
 
 Since I am feature complete and relatively bugfree all the
 work from now on will go into bugfixing and code cleanup
 (believe me some parts really need that)
 
 Here is a short compressed summary of what will go into the
 alpha 1.0 and later final version:
 
 Dynamic loading of all JSF 1.2 artifacts, including
 Application and Session scoped beans (lots of work went into
 this area to enable that)
 
 Dynamic loading of most JSF 2.0 artifacts (application
 events currently are not supported)
 
 Dynamic JSF2 annotation support (aka push annoations into
 existing classes move them around as you wish)
 
 Dynamic resource loading within JSF2 (aka load resources
 from your source path)
 
 Dynamic XHTML loading for Facelets (load your xhtml
 templates directly from your sourcepath)
 
 And all of this for Groovy and Java
 
 The documentation will be hosted on the Wiki for the time
 being and is a work in progress, but enough material already
 is there to justify an alpha release as well:
 
 http://wiki.apache.org/myfaces/Extensions/Scripting
 
 As I said, feature freeze for now, and all which will go
 into the alphas and betas will be code cleanup and bugfixes
 to get a 1.0 release out sometime around March.
 
 
 
 Werner

Re: [VOTE] Extensions-Scripting Alpha

2010-02-02 Thread Matthias Wessendorf 
MyFaces has its own master-pom

-Matthias

On Tue, Feb 2, 2010 at 10:32 AM, Mark Struberg strub...@yahoo.de wrote:
 Hi Werner!

 Not sure if this is needed in your case, but the pom in 
 extensions/scripting/trunk doesn't contain a parent section.

 Usually this points (in the end) to
    parent
        groupIdorg.apache/groupId
        artifactIdapache/artifactId
        version6/version
    /parent

 for all Apache projects.

 LieGrue,
 strub

 --- On Tue, 2/2/10, Werner Punz werner.p...@gmail.com wrote:

 From: Werner Punz werner.p...@gmail.com
 Subject: [VOTE] Extensions-Scripting Alpha
 To: dev@myfaces.apache.org
 Date: Tuesday, February 2, 2010, 9:26 AM
 Hello everyone, I have been feature
 complete since last week for the alpha release. So I want to
 start the vote for the Ext-Scripting Alpha 1.


 Feature summary:


 The planned Spring part will not make it into the official
 1.0 release
 since works on dependency injection frameworks which can
 provide beans over the EL will become integral part post 1.0
 (my plan is to also go the CDI route if the frameworks
 permit it),the spring reloading it will be merged over time,
 but will not be part of the official 1.0.


 So for now 1.0 will only support JSF and JSF only, but that
 extensively.

 Since I am feature complete and relatively bugfree all the
 work from now on will go into bugfixing and code cleanup
 (believe me some parts really need that)

 Here is a short compressed summary of what will go into the
 alpha 1.0 and later final version:

 Dynamic loading of all JSF 1.2 artifacts, including
 Application and Session scoped beans (lots of work went into
 this area to enable that)

 Dynamic loading of most JSF 2.0 artifacts (application
 events currently are not supported)

 Dynamic JSF2 annotation support (aka push annoations into
 existing classes move them around as you wish)

 Dynamic resource loading within JSF2 (aka load resources
 from your source path)

 Dynamic XHTML loading for Facelets (load your xhtml
 templates directly from your sourcepath)

 And all of this for Groovy and Java

 The documentation will be hosted on the Wiki for the time
 being and is a work in progress, but enough material already
 is there to justify an alpha release as well:

 http://wiki.apache.org/myfaces/Extensions/Scripting

 As I said, feature freeze for now, and all which will go
 into the alphas and betas will be code cleanup and bugfixes
 to get a 1.0 release out sometime around March.



 Werner









-- 
Matthias Wessendorf

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

Re: [VOTE] Extensions-Scripting Alpha

2010-02-02 Thread Matthias Wessendorf 
...which inherits from Apache-7

On Tue, Feb 2, 2010 at 10:35 AM, Matthias Wessendorf mat...@apache.org wrote:
 MyFaces has its own master-pom

 -Matthias

 On Tue, Feb 2, 2010 at 10:32 AM, Mark Struberg strub...@yahoo.de wrote:
 Hi Werner!

 Not sure if this is needed in your case, but the pom in 
 extensions/scripting/trunk doesn't contain a parent section.

 Usually this points (in the end) to
    parent
        groupIdorg.apache/groupId
        artifactIdapache/artifactId
        version6/version
    /parent

 for all Apache projects.

 LieGrue,
 strub

 --- On Tue, 2/2/10, Werner Punz werner.p...@gmail.com wrote:

 From: Werner Punz werner.p...@gmail.com
 Subject: [VOTE] Extensions-Scripting Alpha
 To: dev@myfaces.apache.org
 Date: Tuesday, February 2, 2010, 9:26 AM
 Hello everyone, I have been feature
 complete since last week for the alpha release. So I want to
 start the vote for the Ext-Scripting Alpha 1.


 Feature summary:


 The planned Spring part will not make it into the official
 1.0 release
 since works on dependency injection frameworks which can
 provide beans over the EL will become integral part post 1.0
 (my plan is to also go the CDI route if the frameworks
 permit it),the spring reloading it will be merged over time,
 but will not be part of the official 1.0.


 So for now 1.0 will only support JSF and JSF only, but that
 extensively.

 Since I am feature complete and relatively bugfree all the
 work from now on will go into bugfixing and code cleanup
 (believe me some parts really need that)

 Here is a short compressed summary of what will go into the
 alpha 1.0 and later final version:

 Dynamic loading of all JSF 1.2 artifacts, including
 Application and Session scoped beans (lots of work went into
 this area to enable that)

 Dynamic loading of most JSF 2.0 artifacts (application
 events currently are not supported)

 Dynamic JSF2 annotation support (aka push annoations into
 existing classes move them around as you wish)

 Dynamic resource loading within JSF2 (aka load resources
 from your source path)

 Dynamic XHTML loading for Facelets (load your xhtml
 templates directly from your sourcepath)

 And all of this for Groovy and Java

 The documentation will be hosted on the Wiki for the time
 being and is a work in progress, but enough material already
 is there to justify an alpha release as well:

 http://wiki.apache.org/myfaces/Extensions/Scripting

 As I said, feature freeze for now, and all which will go
 into the alphas and betas will be code cleanup and bugfixes
 to get a 1.0 release out sometime around March.



 Werner









 --
 Matthias Wessendorf

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




-- 
Matthias Wessendorf

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

Re: [VOTE] Extensions-Scripting Alpha

2010-02-02 Thread Mark Struberg 
any parent section is still missing ;)

LieGrue,
strub

--- On Tue, 2/2/10, Matthias Wessendorf mat...@apache.org wrote:

 From: Matthias Wessendorf mat...@apache.org
 Subject: Re: [VOTE] Extensions-Scripting Alpha
 To: MyFaces Development dev@myfaces.apache.org
 Date: Tuesday, February 2, 2010, 10:36 AM
 ...which inherits from Apache-7
 
 On Tue, Feb 2, 2010 at 10:35 AM, Matthias Wessendorf mat...@apache.org
 wrote:
  MyFaces has its own master-pom
 
  -Matthias
 
  On Tue, Feb 2, 2010 at 10:32 AM, Mark Struberg strub...@yahoo.de
 wrote:
  Hi Werner!
 
  Not sure if this is needed in your case, but the
 pom in extensions/scripting/trunk doesn't contain a
 parent section.
 
  Usually this points (in the end) to
     parent
       
  groupIdorg.apache/groupId
       
  artifactIdapache/artifactId
         version6/version
     /parent
 
  for all Apache projects.
 
  LieGrue,
  strub
 
  --- On Tue, 2/2/10, Werner Punz werner.p...@gmail.com
 wrote:
 
  From: Werner Punz werner.p...@gmail.com
  Subject: [VOTE] Extensions-Scripting Alpha
  To: dev@myfaces.apache.org
  Date: Tuesday, February 2, 2010, 9:26 AM
  Hello everyone, I have been feature
  complete since last week for the alpha
 release. So I want to
  start the vote for the Ext-Scripting Alpha 1.
 
 
  Feature summary:
 
 
  The planned Spring part will not make it into
 the official
  1.0 release
  since works on dependency injection frameworks
 which can
  provide beans over the EL will become integral
 part post 1.0
  (my plan is to also go the CDI route if the
 frameworks
  permit it),the spring reloading it will be
 merged over time,
  but will not be part of the official 1.0.
 
 
  So for now 1.0 will only support JSF and JSF
 only, but that
  extensively.
 
  Since I am feature complete and relatively
 bugfree all the
  work from now on will go into bugfixing and
 code cleanup
  (believe me some parts really need that)
 
  Here is a short compressed summary of what
 will go into the
  alpha 1.0 and later final version:
 
  Dynamic loading of all JSF 1.2 artifacts,
 including
  Application and Session scoped beans (lots of
 work went into
  this area to enable that)
 
  Dynamic loading of most JSF 2.0 artifacts
 (application
  events currently are not supported)
 
  Dynamic JSF2 annotation support (aka push
 annoations into
  existing classes move them around as you
 wish)
 
  Dynamic resource loading within JSF2 (aka load
 resources
  from your source path)
 
  Dynamic XHTML loading for Facelets (load your
 xhtml
  templates directly from your sourcepath)
 
  And all of this for Groovy and Java
 
  The documentation will be hosted on the Wiki
 for the time
  being and is a work in progress, but enough
 material already
  is there to justify an alpha release as well:
 
  http://wiki.apache.org/myfaces/Extensions/Scripting
 
  As I said, feature freeze for now, and all
 which will go
  into the alphas and betas will be code cleanup
 and bugfixes
  to get a 1.0 release out sometime around
 March.
 
 
 
  Werner
 
 
 
 
 
 
 
 
 
  --
  Matthias Wessendorf
 
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  twitter: http://twitter.com/mwessendorf
 
 
 
 
 -- 
 Matthias Wessendorf
 
 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf

Re: [VOTE] Extensions-Scripting Alpha

2010-02-02 Thread Matthias Wessendorf 
ah! ok,
I'd recommend to use the newly released Apache-MyFaces-Master7

On Tue, Feb 2, 2010 at 10:51 AM, Mark Struberg strub...@yahoo.de wrote:
 any parent section is still missing ;)

 LieGrue,
 strub

 --- On Tue, 2/2/10, Matthias Wessendorf mat...@apache.org wrote:

 From: Matthias Wessendorf mat...@apache.org
 Subject: Re: [VOTE] Extensions-Scripting Alpha
 To: MyFaces Development dev@myfaces.apache.org
 Date: Tuesday, February 2, 2010, 10:36 AM
 ...which inherits from Apache-7

 On Tue, Feb 2, 2010 at 10:35 AM, Matthias Wessendorf mat...@apache.org
 wrote:
  MyFaces has its own master-pom
 
  -Matthias
 
  On Tue, Feb 2, 2010 at 10:32 AM, Mark Struberg strub...@yahoo.de
 wrote:
  Hi Werner!
 
  Not sure if this is needed in your case, but the
 pom in extensions/scripting/trunk doesn't contain a
 parent section.
 
  Usually this points (in the end) to
     parent
 
  groupIdorg.apache/groupId
 
  artifactIdapache/artifactId
         version6/version
     /parent
 
  for all Apache projects.
 
  LieGrue,
  strub
 
  --- On Tue, 2/2/10, Werner Punz werner.p...@gmail.com
 wrote:
 
  From: Werner Punz werner.p...@gmail.com
  Subject: [VOTE] Extensions-Scripting Alpha
  To: dev@myfaces.apache.org
  Date: Tuesday, February 2, 2010, 9:26 AM
  Hello everyone, I have been feature
  complete since last week for the alpha
 release. So I want to
  start the vote for the Ext-Scripting Alpha 1.
 
 
  Feature summary:
 
 
  The planned Spring part will not make it into
 the official
  1.0 release
  since works on dependency injection frameworks
 which can
  provide beans over the EL will become integral
 part post 1.0
  (my plan is to also go the CDI route if the
 frameworks
  permit it),the spring reloading it will be
 merged over time,
  but will not be part of the official 1.0.
 
 
  So for now 1.0 will only support JSF and JSF
 only, but that
  extensively.
 
  Since I am feature complete and relatively
 bugfree all the
  work from now on will go into bugfixing and
 code cleanup
  (believe me some parts really need that)
 
  Here is a short compressed summary of what
 will go into the
  alpha 1.0 and later final version:
 
  Dynamic loading of all JSF 1.2 artifacts,
 including
  Application and Session scoped beans (lots of
 work went into
  this area to enable that)
 
  Dynamic loading of most JSF 2.0 artifacts
 (application
  events currently are not supported)
 
  Dynamic JSF2 annotation support (aka push
 annoations into
  existing classes move them around as you
 wish)
 
  Dynamic resource loading within JSF2 (aka load
 resources
  from your source path)
 
  Dynamic XHTML loading for Facelets (load your
 xhtml
  templates directly from your sourcepath)
 
  And all of this for Groovy and Java
 
  The documentation will be hosted on the Wiki
 for the time
  being and is a work in progress, but enough
 material already
  is there to justify an alpha release as well:
 
  http://wiki.apache.org/myfaces/Extensions/Scripting
 
  As I said, feature freeze for now, and all
 which will go
  into the alphas and betas will be code cleanup
 and bugfixes
  to get a 1.0 release out sometime around
 March.
 
 
 
  Werner
 
 
 
 
 
 
 
 
 
  --
  Matthias Wessendorf
 
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  twitter: http://twitter.com/mwessendorf
 



 --
 Matthias Wessendorf

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








-- 
Matthias Wessendorf

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

[jira] Commented: (MYFACES-2504) Google App Engine Support

2010-02-02 Thread Ali Ok (JIRA) 

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

Ali Ok commented on MYFACES-2504:
-

Thanks for your review Leonardo.
The latest patch : 2504-3.diff does not require the init param. I dont know 
how to delete older ones.
Please ignore 2504.diff and 2504-2.diff files.
2504-doc.diff is the doc patch.

I see what you mean. If that is ok for everyone, I can implement Force JSP_2_0 
init parameter.

 Google App Engine Support
 -

 Key: MYFACES-2504
 URL: https://issues.apache.org/jira/browse/MYFACES-2504
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-252, JSR-314
Affects Versions: 1.2.8, 2.0.0-alpha
 Environment: Google App Engine 1.3
Reporter: Ali Ok
Priority: Minor
 Attachments: 2504-2.diff, 2504-3.diff, 2504-doc.diff, 2504.diff


 Support for Google App Engine for MyFaces 1.2 and 2.0.

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

[jira] Commented: (TRINIDAD-983) Sortable model for localized texts

2010-02-02 Thread Paul Mander (JIRA) 

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

Paul Mander commented on TRINIDAD-983:
--

I would say this was a bug rather than an improvement. Can we get this into the 
next build?

 Sortable model for localized texts
 --

 Key: TRINIDAD-983
 URL: https://issues.apache.org/jira/browse/TRINIDAD-983
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 1.0.6-core
Reporter: Tomas Havelka
 Attachments: locale-sensitive-sortable-model.patch


 Sortable model should support sorting for current locale. 
 Solution:
 Extend inner class Comp of SortableModel to support sorting of String values 
 using Collator.compare method. 

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

Re: [VOTE] Extensions-Scripting Alpha

2010-02-02 Thread Werner Punz 

Will fix that as well before I will tag the alpha :-)
Thanks for pointing it out.



Werner


Matthias Wessendorf schrieb:

ah! ok,
I'd recommend to use the newly released Apache-MyFaces-Master7

On Tue, Feb 2, 2010 at 10:51 AM, Mark Struberg strub...@yahoo.de wrote:

any parent section is still missing ;)

LieGrue,
strub

--- On Tue, 2/2/10, Matthias Wessendorf mat...@apache.org wrote:


From: Matthias Wessendorf mat...@apache.org
Subject: Re: [VOTE] Extensions-Scripting Alpha
To: MyFaces Development dev@myfaces.apache.org
Date: Tuesday, February 2, 2010, 10:36 AM
...which inherits from Apache-7

On Tue, Feb 2, 2010 at 10:35 AM, Matthias Wessendorf mat...@apache.org
wrote:

MyFaces has its own master-pom

-Matthias

On Tue, Feb 2, 2010 at 10:32 AM, Mark Struberg strub...@yahoo.de

wrote:

Hi Werner!

Not sure if this is needed in your case, but the

pom in extensions/scripting/trunk doesn't contain a
parent section.

Usually this points (in the end) to
   parent


 groupIdorg.apache/groupId
 artifactIdapache/artifactId

   version6/version
   /parent

for all Apache projects.

LieGrue,
strub

--- On Tue, 2/2/10, Werner Punz werner.p...@gmail.com

wrote:

From: Werner Punz werner.p...@gmail.com
Subject: [VOTE] Extensions-Scripting Alpha
To: dev@myfaces.apache.org
Date: Tuesday, February 2, 2010, 9:26 AM
Hello everyone, I have been feature
complete since last week for the alpha

release. So I want to

start the vote for the Ext-Scripting Alpha 1.


Feature summary:


The planned Spring part will not make it into

the official

1.0 release
since works on dependency injection frameworks

which can

provide beans over the EL will become integral

part post 1.0

(my plan is to also go the CDI route if the

frameworks

permit it),the spring reloading it will be

merged over time,

but will not be part of the official 1.0.


So for now 1.0 will only support JSF and JSF

only, but that

extensively.

Since I am feature complete and relatively

bugfree all the

work from now on will go into bugfixing and

code cleanup

(believe me some parts really need that)

Here is a short compressed summary of what

will go into the

alpha 1.0 and later final version:

Dynamic loading of all JSF 1.2 artifacts,

including

Application and Session scoped beans (lots of

work went into

this area to enable that)

Dynamic loading of most JSF 2.0 artifacts

(application

events currently are not supported)

Dynamic JSF2 annotation support (aka push

annoations into

existing classes move them around as you

wish)

Dynamic resource loading within JSF2 (aka load

resources

from your source path)

Dynamic XHTML loading for Facelets (load your

xhtml

templates directly from your sourcepath)

And all of this for Groovy and Java

The documentation will be hosted on the Wiki

for the time

being and is a work in progress, but enough

material already

is there to justify an alpha release as well:

http://wiki.apache.org/myfaces/Extensions/Scripting

As I said, feature freeze for now, and all

which will go

into the alphas and betas will be code cleanup

and bugfixes

to get a 1.0 release out sometime around

March.



Werner









--
Matthias Wessendorf

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




--
Matthias Wessendorf

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

[jira] Created: (EXTSCRIPT-61) Fix parent pom relations before tagging alpha

2010-02-02 Thread Werner Punz (JIRA) 
Fix parent pom relations before tagging alpha
-

 Key: EXTSCRIPT-61
 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-61
 Project: MyFaces Extensions Scripting
  Issue Type: Bug
Reporter: Werner Punz
Assignee: Werner Punz
Priority: Minor


Posted from Marc Struberg

   Not sure if this is needed in your case, but the
 pom in extensions/scripting/trunk doesn't contain a
 parent section.
  
   Usually this points (in the end) to
  parent

  groupIdorg.apache/groupId

  artifactIdapache/artifactId
  version6/version
  /parent
  
   for all Apache projects.
 Not sure if this is needed in your case, but the
 pom in extensions/scripting/trunk doesn't contain a
 parent section.
  
   Usually this points (in the end) to
  parent

  groupIdorg.apache/groupId

  artifactIdapache/artifactId
  version6/version
  /parent
  
   for all Apache projects.
  

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

[jira] Commented: (EXTSCRIPT-61) Fix parent pom relations before tagging alpha

2010-02-02 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/EXTSCRIPT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12828621#action_12828621
 ] 

Matthias Weßendorf commented on EXTSCRIPT-61:
-

please use the myfaces master pom 

 Fix parent pom relations before tagging alpha
 -

 Key: EXTSCRIPT-61
 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-61
 Project: MyFaces Extensions Scripting
  Issue Type: Bug
Reporter: Werner Punz
Assignee: Werner Punz
Priority: Minor

 Posted from Marc Struberg
Not sure if this is needed in your case, but the
  pom in extensions/scripting/trunk doesn't contain a
  parent section.
   
Usually this points (in the end) to
   parent
 
   groupIdorg.apache/groupId
 
   artifactIdapache/artifactId
   version6/version
   /parent
   
for all Apache projects.
  Not sure if this is needed in your case, but the
  pom in extensions/scripting/trunk doesn't contain a
  parent section.
   
Usually this points (in the end) to
   parent
 
   groupIdorg.apache/groupId
 
   artifactIdapache/artifactId
   version6/version
   /parent
   
for all Apache projects.
   

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

[jira] Created: (MYFACES-2528) BeanValidator validation groups are overwritten with PSS

2010-02-02 Thread Michael Kurz (JIRA) 
BeanValidator validation groups are overwritten with PSS


 Key: MYFACES-2528
 URL: https://issues.apache.org/jira/browse/MYFACES-2528
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-beta
Reporter: Michael Kurz


Setting the validation groups of a bean validator like f:validateBean 
validationGroups=#{bean.groups}/ is not always working correctly with PSS. 
Property bean.groups returns null or the class name of a validation group in my 
example based on the value of a boolean checkbox:

h:selectBooleanCheckbox value=#{bean.prop1}
valueChangeListener=#{bean.prop1Changed}
immediate=true onclick=this.form.submit()/
h:inputText value=#{bean.prop2} rendered=#{bean.prop1}
  f:validateBean validationGroups=#{bean.groups}/
/h:inputText

If I check the boolean checkbox the form is submitted and rendered again with 
the additional input field. The problem now is that the validation groups are 
set correctly on building the view during the second traversal of the lifecycle 
before restoring the state. But on restoring the validator this value is 
overwritten with the old value from the state and my validation group is gone 
again.

As the BeanValidator is a PartialStateHolder this can be avoided by only saving 
and restoring the state if the initial state was not marked.


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

[jira] Updated: (MYFACES-2528) BeanValidator validation groups are overwritten with PSS

2010-02-02 Thread Michael Kurz (JIRA) 

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

Michael Kurz updated MYFACES-2528:
--

Status: Patch Available  (was: Open)

 BeanValidator validation groups are overwritten with PSS
 

 Key: MYFACES-2528
 URL: https://issues.apache.org/jira/browse/MYFACES-2528
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-beta
Reporter: Michael Kurz
 Attachments: MYFACES-2528.patch


 Setting the validation groups of a bean validator like f:validateBean 
 validationGroups=#{bean.groups}/ is not always working correctly with PSS. 
 Property bean.groups returns null or the class name of a validation group in 
 my example based on the value of a boolean checkbox:
 h:selectBooleanCheckbox value=#{bean.prop1}
 valueChangeListener=#{bean.prop1Changed}
 immediate=true onclick=this.form.submit()/
 h:inputText value=#{bean.prop2} rendered=#{bean.prop1}
   f:validateBean validationGroups=#{bean.groups}/
 /h:inputText
 If I check the boolean checkbox the form is submitted and rendered again with 
 the additional input field. The problem now is that the validation groups are 
 set correctly on building the view during the second traversal of the 
 lifecycle before restoring the state. But on restoring the validator this 
 value is overwritten with the old value from the state and my validation 
 group is gone again.
 As the BeanValidator is a PartialStateHolder this can be avoided by only 
 saving and restoring the state if the initial state was not marked.

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

[jira] Created: (TOMAHAWK-1486) Tree does not work any more with core 2.0

2010-02-02 Thread Ingo Hofmann (JIRA) 
Tree does not work any more with core 2.0
-

 Key: TOMAHAWK-1486
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1486
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Tree
Affects Versions: 1.1.10-SNAPSHOT
Reporter: Ingo Hofmann


A rendered t:tree tree can not be collapsed or opened any more (with core 
2.0).
The nodes' command links seem to be rendered wrong.

Example from the examples module:

h:form id=treeform
t:tree id=tree1 value=#{tree1Backer.treeModel}
styleClass=tree
nodeClass=treenode
selectedNodeClass=treenodeSelected
expandRoot=true
/t:tree
/h:form


tree1Backer:

public class Tree1Backer {

private TreeModel treeModel;

public TreeModel getTreeModel() {
if (treeModel == null) {
DefaultMutableTreeNode root = new DefaultMutableTreeNode(XY);
DefaultMutableTreeNode a = new DefaultMutableTreeNode(A);
root.insert(a);
DefaultMutableTreeNode b = new DefaultMutableTreeNode(B);
root.insert(b);
DefaultMutableTreeNode c = new DefaultMutableTreeNode(C);
root.insert(c);

DefaultMutableTreeNode node = new DefaultMutableTreeNode(a1);
a.insert(node);
node = new DefaultMutableTreeNode(a2 );
a.insert(node);
node = new DefaultMutableTreeNode(b );
b.insert(node);

a = node;
node = new DefaultMutableTreeNode(x1);
a.insert(node);
node = new DefaultMutableTreeNode(x2);
a.insert(node);
treeModel = new DefaultTreeModel(root);
}
return treeModel;
}

public void setTreeModel(TreeModel treeModel) {
this.treeModel = treeModel;
}
}

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

[jira] Commented: (MYFACES-2528) BeanValidator validation groups are overwritten with PSS

2010-02-02 Thread Michael Kurz (JIRA) 

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

Michael Kurz commented on MYFACES-2528:
---

I did some further investigation on this one and set 
javax.faces.FULL_STATE_SAVING_VIEW_IDS to have full state saving for this view. 
Interestingly enough, it is not working too. I expected, that this would solve 
the issue. But the validator is not refreshed on building the view in render 
response. The validation group is always determined by the one in the state 
(and thus the one set on the first request).

This leads to an interesting behavior: If the select box is checked on the 
initial request to this page the validator works as expected. Also when I check 
and uncheck the checkbox. So I guess in this case the validation group is 
always the same in the state but the validation still behaves correctly because 
the rendered attribute changes. If the checkbox is not checked on the initial 
request the validator does not work (validation group is always the default 
one).

I noticed the same behavior in Mojarra 2.0.1.

Is this the expected behavior?

 BeanValidator validation groups are overwritten with PSS
 

 Key: MYFACES-2528
 URL: https://issues.apache.org/jira/browse/MYFACES-2528
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-beta
Reporter: Michael Kurz
 Attachments: MYFACES-2528.patch


 Setting the validation groups of a bean validator like f:validateBean 
 validationGroups=#{bean.groups}/ is not always working correctly with PSS. 
 Property bean.groups returns null or the class name of a validation group in 
 my example based on the value of a boolean checkbox:
 h:selectBooleanCheckbox value=#{bean.prop1}
 valueChangeListener=#{bean.prop1Changed}
 immediate=true onclick=this.form.submit()/
 h:inputText value=#{bean.prop2} rendered=#{bean.prop1}
   f:validateBean validationGroups=#{bean.groups}/
 /h:inputText
 If I check the boolean checkbox the form is submitted and rendered again with 
 the additional input field. The problem now is that the validation groups are 
 set correctly on building the view during the second traversal of the 
 lifecycle before restoring the state. But on restoring the validator this 
 value is overwritten with the old value from the state and my validation 
 group is gone again.
 As the BeanValidator is a PartialStateHolder this can be avoided by only 
 saving and restoring the state if the initial state was not marked.

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

[jira] Created: (TRINIDAD-1703) JSF2: Viewhandler.getViewDeclarationLanguage() implementation should call into the PageResolver

2010-02-02 Thread Max Starets (JIRA) 
JSF2: Viewhandler.getViewDeclarationLanguage() implementation should call into 
the PageResolver
---

 Key: TRINIDAD-1703
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1703
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Facelets
Affects Versions: 2.0.0.1-core 
Reporter: Max Starets
Assignee: Max Starets


Viewhandler.getViewDeclarationLanguage() implementation should be using a 
physical View id, so that the extension mapping defined by the 
javax.faces.FACELETS_VIEW_MAPPINGS context parameter is applied to the physical 
file extension.

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

[jira] Created: (TOMAHAWK-1487) ClassCastException when rendering HtmlDataScroller with core 2.0

2010-02-02 Thread Ingo Hofmann (JIRA) 
ClassCastException when rendering HtmlDataScroller with core 2.0


 Key: TOMAHAWK-1487
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1487
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Data Scroller
Affects Versions: 1.1.10-SNAPSHOT
Reporter: Ingo Hofmann


Using tomahawk20's HtmlDataScroller produces following exception:
java.lang.ClassCastException: 
org.apache.myfaces.custom.datascroller.HtmlDataScroller cannot be cast to 
javax.faces.component.ActionSource2
at 
org.apache.myfaces.view.facelets.tag.jsf.ActionSourceRule$ActionMapper2.applyMetadata(ActionSourceRule.java:55)


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

[jira] Resolved: (TRINIDAD-1703) JSF2: Viewhandler.getViewDeclarationLanguage() implementation should call into the PageResolver

2010-02-02 Thread Max Starets (JIRA) 

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

Max Starets resolved TRINIDAD-1703.
---

   Resolution: Fixed
Fix Version/s: 2.0.0.1-core 

 JSF2: Viewhandler.getViewDeclarationLanguage() implementation should call 
 into the PageResolver
 ---

 Key: TRINIDAD-1703
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1703
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Facelets
Affects Versions: 2.0.0.1-core 
Reporter: Max Starets
Assignee: Max Starets
 Fix For: 2.0.0.1-core 


 Viewhandler.getViewDeclarationLanguage() implementation should be using a 
 physical View id, so that the extension mapping defined by the 
 javax.faces.FACELETS_VIEW_MAPPINGS context parameter is applied to the 
 physical file extension.

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

Re: release notes for myfaces core

2010-02-02 Thread Jakob Korherr 
+1 on that!

Regards,
Jakob

2010/2/2, Matthias Wessendorf mat...@apache.org:
 Hello,

 our download page:
 http://myfaces.apache.org/download.html

 does not talk about the release notes. For Trinidad
 we provide the latest release notes along the download info;

 Do we want that for MyFaces core as well ?

 I'd say yes...


 Yeah, I will add them... ;)

 --
 Matthias Wessendorf

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

[jira] Commented: (TOMAHAWK-1487) ClassCastException when rendering HtmlDataScroller with core 2.0

2010-02-02 Thread Leonardo Uribe (JIRA) 

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

Leonardo Uribe commented on TOMAHAWK-1487:
--

The problem is in myfaces core. ActionSourceRule should deal with both 
ActionSource and ActionSource2. We have to try is ri is doing right.

 ClassCastException when rendering HtmlDataScroller with core 2.0
 

 Key: TOMAHAWK-1487
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1487
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Data Scroller
Affects Versions: 1.1.10-SNAPSHOT
Reporter: Ingo Hofmann
 Attachments: HtmlDataScroller_as_ActionSource2.patch


 Using tomahawk20's HtmlDataScroller produces following exception:
 java.lang.ClassCastException: 
 org.apache.myfaces.custom.datascroller.HtmlDataScroller cannot be cast to 
 javax.faces.component.ActionSource2
 at 
 org.apache.myfaces.view.facelets.tag.jsf.ActionSourceRule$ActionMapper2.applyMetadata(ActionSourceRule.java:55)

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

[jira] Commented: (MYFACES-2528) BeanValidator validation groups are overwritten with PSS

2010-02-02 Thread Michael Kurz (JIRA) 

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

Michael Kurz commented on MYFACES-2528:
---

Out of curiosity I hacked a quick solution for this one that seems to work as I 
expect it. I simply wrote a tag handler for f:validateBean that checks if the 
attribute is a value expression. In that case this expression is directly set 
on the BeanValidator (new property validationGroupsExpression). BeanValidator 
evaluates this expression if it is set.

Though this works for me with partial and full state saving I don't know if it 
is the way to go. 

 BeanValidator validation groups are overwritten with PSS
 

 Key: MYFACES-2528
 URL: https://issues.apache.org/jira/browse/MYFACES-2528
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-beta
Reporter: Michael Kurz
 Attachments: MYFACES-2528.patch


 Setting the validation groups of a bean validator like f:validateBean 
 validationGroups=#{bean.groups}/ is not always working correctly with PSS. 
 Property bean.groups returns null or the class name of a validation group in 
 my example based on the value of a boolean checkbox:
 h:selectBooleanCheckbox value=#{bean.prop1}
 valueChangeListener=#{bean.prop1Changed}
 immediate=true onclick=this.form.submit()/
 h:inputText value=#{bean.prop2} rendered=#{bean.prop1}
   f:validateBean validationGroups=#{bean.groups}/
 /h:inputText
 If I check the boolean checkbox the form is submitted and rendered again with 
 the additional input field. The problem now is that the validation groups are 
 set correctly on building the view during the second traversal of the 
 lifecycle before restoring the state. But on restoring the validator this 
 value is overwritten with the old value from the state and my validation 
 group is gone again.
 As the BeanValidator is a PartialStateHolder this can be avoided by only 
 saving and restoring the state if the initial state was not marked.

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

[MyFaces 2] Validator attributes

2010-02-02 Thread Michael Kurz 

Hallo,

I have some troubles with the attribute validationGroups on 
f:validateBean (see MYFACES-2528 [1] for details). The problem is mainly 
caused by the fact, that its value is set on the validator in the tag 
handler. If the attribute is set to a value expressions this leads to 
unexpected behavior (at least not the way I would expect it ;-)).


So I wonder how this should be solved. What I (successfully) tried is to 
save the value expression directly in the validator with an additional 
tag handler to evaluate it not before the value is really needed. The 
same might also apply to other validator attributes. But how is this 
compliant with the spec? Or the other way round: why is it implemented 
the way it currently is?


reards
Michael

[1]: https://issues.apache.org/jira/browse/MYFACES-2528

[jira] Updated: (TRINIDAD-983) Sortable model for localized texts

2010-02-02 Thread JIRA 

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

Matthias Weßendorf updated TRINIDAD-983:


   Resolution: Fixed
Fix Version/s: 1.2.14-core 
   1.0.12-core
 Assignee: Matthias Weßendorf
   Status: Resolved  (was: Patch Available)

Thx to Tomas Havelka for the patch!

 Sortable model for localized texts
 --

 Key: TRINIDAD-983
 URL: https://issues.apache.org/jira/browse/TRINIDAD-983
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 1.0.6-core
Reporter: Tomas Havelka
Assignee: Matthias Weßendorf
 Fix For: 1.0.12-core, 1.2.14-core 

 Attachments: locale-sensitive-sortable-model.patch


 Sortable model should support sorting for current locale. 
 Solution:
 Extend inner class Comp of SortableModel to support sorting of String values 
 using Collator.compare method. 

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

[jira] Commented: (MYFACES-2528) BeanValidator validation groups are overwritten with PSS

2010-02-02 Thread Leonardo Uribe (JIRA) 

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

Leonardo Uribe commented on MYFACES-2528:
-

I think the patch miss one call to clearInitialState on setValidationGroups. In 
this way if validationGroups is changed after build view, it state is 
saved/restored. 

Jakob did/is doing some work on this field, maybe he can answer better than me 
if this is the way to go.

 BeanValidator validation groups are overwritten with PSS
 

 Key: MYFACES-2528
 URL: https://issues.apache.org/jira/browse/MYFACES-2528
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-beta
Reporter: Michael Kurz
 Attachments: MYFACES-2528.patch


 Setting the validation groups of a bean validator like f:validateBean 
 validationGroups=#{bean.groups}/ is not always working correctly with PSS. 
 Property bean.groups returns null or the class name of a validation group in 
 my example based on the value of a boolean checkbox:
 h:selectBooleanCheckbox value=#{bean.prop1}
 valueChangeListener=#{bean.prop1Changed}
 immediate=true onclick=this.form.submit()/
 h:inputText value=#{bean.prop2} rendered=#{bean.prop1}
   f:validateBean validationGroups=#{bean.groups}/
 /h:inputText
 If I check the boolean checkbox the form is submitted and rendered again with 
 the additional input field. The problem now is that the validation groups are 
 set correctly on building the view during the second traversal of the 
 lifecycle before restoring the state. But on restoring the validator this 
 value is overwritten with the old value from the state and my validation 
 group is gone again.
 As the BeanValidator is a PartialStateHolder this can be avoided by only 
 saving and restoring the state if the initial state was not marked.

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

Re: release notes for myfaces core

2010-02-02 Thread Leonardo Uribe 
Hi

I put the release notes link on

http://myfaces.apache.org/

But put it on download page seems to be a good idea.

+1

regards,

Leonardo Uribe

2010/2/2 Jakob Korherr jakob.korh...@gmail.com

 +1 on that!

 Regards,
 Jakob

 2010/2/2, Matthias Wessendorf mat...@apache.org:
  Hello,
 
  our download page:
  http://myfaces.apache.org/download.html
 
  does not talk about the release notes. For Trinidad
  we provide the latest release notes along the download info;
 
  Do we want that for MyFaces core as well ?
 
  I'd say yes...
 
 
  Yeah, I will add them... ;)
 
  --
  Matthias Wessendorf
 
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  twitter: http://twitter.com/mwessendorf

[jira] Commented: (MYFACES-2528) BeanValidator validation groups are overwritten with PSS

2010-02-02 Thread Michael Kurz (JIRA) 

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

Michael Kurz commented on MYFACES-2528:
---

The patch is anyway not the complete solution as I found out later.

 BeanValidator validation groups are overwritten with PSS
 

 Key: MYFACES-2528
 URL: https://issues.apache.org/jira/browse/MYFACES-2528
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-beta
Reporter: Michael Kurz
 Attachments: MYFACES-2528.patch


 Setting the validation groups of a bean validator like f:validateBean 
 validationGroups=#{bean.groups}/ is not always working correctly with PSS. 
 Property bean.groups returns null or the class name of a validation group in 
 my example based on the value of a boolean checkbox:
 h:selectBooleanCheckbox value=#{bean.prop1}
 valueChangeListener=#{bean.prop1Changed}
 immediate=true onclick=this.form.submit()/
 h:inputText value=#{bean.prop2} rendered=#{bean.prop1}
   f:validateBean validationGroups=#{bean.groups}/
 /h:inputText
 If I check the boolean checkbox the form is submitted and rendered again with 
 the additional input field. The problem now is that the validation groups are 
 set correctly on building the view during the second traversal of the 
 lifecycle before restoring the state. But on restoring the validator this 
 value is overwritten with the old value from the state and my validation 
 group is gone again.
 As the BeanValidator is a PartialStateHolder this can be avoided by only 
 saving and restoring the state if the initial state was not marked.

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

[jira] Resolved: (MYFACES-2522) f:event wrong attribute name

2010-02-02 Thread Leonardo Uribe (JIRA) 

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

Leonardo Uribe resolved MYFACES-2522.
-

   Resolution: Fixed
Fix Version/s: 2.0.0-beta-2
 Assignee: Leonardo Uribe

Thanks to Werner Punz for make clear how this should be solved.

 f:event wrong attribute name
 

 Key: MYFACES-2522
 URL: https://issues.apache.org/jira/browse/MYFACES-2522
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Reporter: Werner Punz
Assignee: Leonardo Uribe
Priority: Minor
 Fix For: 2.0.0-beta-2


 As it seems f:event uses a wrong (probably old) attribute name:
 f:event name=postAddToView
  listener=#{javatestbean.validate}/ works
 but in reality according to the spec section 3.4.3.4 it should be 
 f:event type=postAddToView
  listener=#{javatestbean.validate}/
 and that one causes a classNotFound error

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

[jira] Created: (TRINIDAD-1704) Implement a prototype on Trinidad 2.0.x., that accepts JSF2.0 Ajax style requests and returns JSF 2.0 style responses.

2010-02-02 Thread Pavitra Subramaniam (JIRA) 
Implement a prototype on Trinidad 2.0.x., that accepts JSF2.0 Ajax style 
requests and returns JSF 2.0 style responses.
--

 Key: TRINIDAD-1704
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1704
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Components
Affects Versions: 2.0.0.1-core 
 Environment: Windows 7
Reporter: Pavitra Subramaniam


The goal of this task is to do research/prototyping to get our bearings and 
identify potential stumbling blocks in the trasition to JSF 2.0 Ajax features 
in particular. I have put together a Trinidad prototype with the following 
changes:

1. Trinidad client-side calls out to jsf.ajax.request() to issue the request
  - simple changes to call jsf.ajax.request() instead of Trinidad sendFormPost
  - no support (yet) for special usecases - mobile/iframe (file upload) /portlet

2. Trinidad server-side has been updated to recognize the JSF2-style request
 - minor changes to CoreRenderKit to recognize JSF 2.0 request headers / POST 
params
 
3. Trinidad server-side generates a JSF2-style response
 - PPRResponseWriter tweaked; a new implementation for the 
PartialViewContextFactory/PartialViewContext

4. Trinidad client-side allows jsf.ajax.response() to process the response.
  - allow jsf.ajax.response() to handle response entirely and update the page


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

[jira] Commented: (TRINIDAD-1689) New Trinidad Default Skin - Casablanca

2010-02-02 Thread Mathias Walter (JIRA) 

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

Mathias Walter commented on TRINIDAD-1689:
--

Disabling gridlines (verticalGridVisible=false horizontalGridVisible=false) 
 in table or treeTable does not work. Neither in FireFox nor in IE8. Can also 
be seen in the show case.

Also, Trinidad input/select components are not rendered well if they are placed 
in the actions facet of a table/treeTable. See screenshot.

The first input is a h:inputText, 2nd is tr:inputText and 3rd is tr:inputText 
with simple=true.

Please fix this before release of 1.2.14. Or should I open a new issue for 
skinning errors related to Casablanca skin?

 New Trinidad Default Skin - Casablanca
 --

 Key: TRINIDAD-1689
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1689
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Skinning
Affects Versions: 1.2.14-core 
Reporter: Adonis Raul Raduca
Assignee: Catalin Kormos
 Fix For: 1.2.14-core 

 Attachments: casablanca.zip, casablancaIntegration.patch, 
 trinidadAdaptation.patch


 A new more modern skin with a nice-minimalist look. 
 Also a simple and intuitive way to skin Trinidad components using Casablanca 
 selectors stack.

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

[Trinidad 2] Integrating JSF 2 AJAX support with Trinidad AJAX

2010-02-02 Thread Andrew Robinson 
Hey all, wanting to send a heads up:

Pavitra Subramaniam and Andy Schwartz have spent a good amount of time
looking into Trinidad 2 and what gaps there are with Trinidad 2 and
JSF 2's AJAX implementation. Pavitra has also already done some work
on her own and has got much of Trinidad working with the built-in JSF
2 requests during some prototyping and her gap analysis. Andy is going
to move their findings and results of their research into the MyFaces
WIKI on the gaps, issues and begin a discussion on this list and on
the WIKI about a phased strategy of migrating Trinidad.

Pavitra created this JIRA ticket with her work so far:
https://issues.apache.org/jira/browse/TRINIDAD-1704

I also want to be help out with this effort and am planning on helping
out with the client JavaScript side first I think.

The three of us are employed by Oracle and have time allocated for
assisting Trinidad 2 in this capacity and will be ensuring to be
operating in the standard MyFaces development way, meaning both open,
submitting patches, maintaining a WIKI and leveraging the mailing
lists and JIRA.

I created a private branch in SVN
(https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax)
so that the AJAX changes can be made gradually and only merged into
the 2.0.x branch when it is stable enough to not break the 2.0.x
branch.

I just wanted to send this email out as a heads up so that the whole
community is aware of the work that has already been done on research
and Pavitra's initial work. Once Andy has written the WIKI, he or I
will post the link as a reply in this thread so any community feedback
can be made on this thread to make following this work easier.
Basically I wanted to make sure that the submissions and help from
Oracle is done in an open manner that is congruent to the modus
operandi of the ASF.

Once the WIKI is up, let me know if there is interest in helping out
or if you have any comments on any of the suggested approaches.

Thanks,
Andrew

[jira] Updated: (TRINIDAD-1704) Implement a prototype on Trinidad 2.0.x., that accepts JSF2.0 Ajax style requests and returns JSF 2.0 style responses.

2010-02-02 Thread Pavitra Subramaniam (JIRA) 

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

Pavitra Subramaniam updated TRINIDAD-1704:
--

Status: Patch Available  (was: Open)

 Implement a prototype on Trinidad 2.0.x., that accepts JSF2.0 Ajax style 
 requests and returns JSF 2.0 style responses.
 --

 Key: TRINIDAD-1704
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1704
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Components
Affects Versions: 2.0.0.1-core 
 Environment: Windows 7
Reporter: Pavitra Subramaniam
Assignee: Andrew Robinson

 The goal of this task is to do research/prototyping to get our bearings and 
 identify potential stumbling blocks in the trasition to JSF 2.0 Ajax features 
 in particular. I have put together a Trinidad prototype with the following 
 changes:
 1. Trinidad client-side calls out to jsf.ajax.request() to issue the request
   - simple changes to call jsf.ajax.request() instead of Trinidad sendFormPost
   - no support (yet) for special usecases - mobile/iframe (file upload) 
 /portlet
 2. Trinidad server-side has been updated to recognize the JSF2-style request
  - minor changes to CoreRenderKit to recognize JSF 2.0 request headers / POST 
 params
  
 3. Trinidad server-side generates a JSF2-style response
  - PPRResponseWriter tweaked; a new implementation for the 
 PartialViewContextFactory/PartialViewContext
 4. Trinidad client-side allows jsf.ajax.response() to process the response.
   - allow jsf.ajax.response() to handle response entirely and update the page

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

[jira] Updated: (TRINIDAD-1704) Implement a prototype on Trinidad 2.0.x., that accepts JSF2.0 Ajax style requests and returns JSF 2.0 style responses.

2010-02-02 Thread Andrew Robinson (JIRA) 

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

Andrew Robinson updated TRINIDAD-1704:
--

Status: Open  (was: Patch Available)

 Implement a prototype on Trinidad 2.0.x., that accepts JSF2.0 Ajax style 
 requests and returns JSF 2.0 style responses.
 --

 Key: TRINIDAD-1704
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1704
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Components
Affects Versions: 2.0.0.1-core 
 Environment: Windows 7
Reporter: Pavitra Subramaniam
Assignee: Andrew Robinson
 Attachments: jsf2-ajax-patch0.patch


 The goal of this task is to do research/prototyping to get our bearings and 
 identify potential stumbling blocks in the trasition to JSF 2.0 Ajax features 
 in particular. I have put together a Trinidad prototype with the following 
 changes:
 1. Trinidad client-side calls out to jsf.ajax.request() to issue the request
   - simple changes to call jsf.ajax.request() instead of Trinidad sendFormPost
   - no support (yet) for special usecases - mobile/iframe (file upload) 
 /portlet
 2. Trinidad server-side has been updated to recognize the JSF2-style request
  - minor changes to CoreRenderKit to recognize JSF 2.0 request headers / POST 
 params
  
 3. Trinidad server-side generates a JSF2-style response
  - PPRResponseWriter tweaked; a new implementation for the 
 PartialViewContextFactory/PartialViewContext
 4. Trinidad client-side allows jsf.ajax.response() to process the response.
   - allow jsf.ajax.response() to handle response entirely and update the page

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

[jira] Resolved: (MYFACES-2507) onClick on commandLink does not trigger loading of required jsf.js

2010-02-02 Thread Leonardo Uribe (JIRA) 

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

Leonardo Uribe resolved MYFACES-2507.
-

   Resolution: Fixed
Fix Version/s: 2.0.0-beta-2
 Assignee: Leonardo Uribe

 onClick on commandLink does not trigger loading of required jsf.js
 --

 Key: MYFACES-2507
 URL: https://issues.apache.org/jira/browse/MYFACES-2507
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-alpha
Reporter: Ingo Hofmann
Assignee: Leonardo Uribe
 Fix For: 2.0.0-beta-2


 The commandLink's onClick attribute will be rendered as 
 onclick=jsf.util.chain(...) what requires the variable jsf which is 
 defined in jsf.js. However, the renderer does not load the appropriate file 
 so that the onClick action will be ignored (or end up as a JavaScript error) 
 if - for instance - no Ajax component is present on the same page. 
 Find the example below to reproduce this issue (click on command link will 
 not have any effects):
 ?xml version=1.0 encoding=ISO-8859-1 ?
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html xmlns=http://www.w3.org/1999/xhtml;
  xmlns:h=http://java.sun.com/jsf/html;
  xmlns:f=http://java.sun.com/jsf/core;
  
 h:head
 /h:head
 h:body
 h:form id=mainForm
 h:panelGrid id=grid columns=2
 h:commandLink value=Click me! onclick=confirm('Hello World') 
 action=update
 /h:commandLink
 /h:panelGrid
 /h:form
 /h:body
 /html

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

[jira] Resolved: (MYFACES-2527) Support for decorator design pattern: RenderKit(s)

2010-02-02 Thread Leonardo Uribe (JIRA) 

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

Leonardo Uribe resolved MYFACES-2527.
-

   Resolution: Fixed
Fix Version/s: 2.0.0-beta-2
 Assignee: Leonardo Uribe

Thanks to Martin Koci for the report. 

 Support for decorator design pattern: RenderKit(s)
 --

 Key: MYFACES-2527
 URL: https://issues.apache.org/jira/browse/MYFACES-2527
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Reporter: Martin Koci
Assignee: Leonardo Uribe
 Fix For: 2.0.0-beta-2


 Spec. 11.4.6 Delegating Implementation Support - The runtime must support 
 the decorator design pattern .. for .. RenderKit. This is especially true 
 for HTML_BASIC, following example should work:
 faces-config.xml
 render-kit
 render-kit-classcom.foo.render.RenderKitImpl/render-kit-class
 render-kit-idHTML_BASIC/render-kit-id
 /render-kit
 RenderKitImpl:
 class RenderKitImpl extends RenderKit implements FacesWrapperRenderKit {
   public RenderKitImpl(RenderKit wrapped) {
 super();
 this.wrapped = wrapped;
   }
   // method delegation here ...
 }

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

[jira] Resolved: (MYFACES-2466) NullPointerException in UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot subscribed to PostAddToViewEvent

2010-02-02 Thread Leonardo Uribe (JIRA) 

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

Leonardo Uribe resolved MYFACES-2466.
-

Resolution: Duplicate
  Assignee: Leonardo Uribe

This is a duplicate of MYFACES-2487, which was already fixed

 NullPointerException in 
 UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot 
 subscribed to PostAddToViewEvent
 --

 Key: MYFACES-2466
 URL: https://issues.apache.org/jira/browse/MYFACES-2466
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-alpha-2
Reporter: Jakob Korherr
Assignee: Leonardo Uribe
 Attachments: exception-trigger.patch, myfaces-2466-ugly-fix.patch


 java.lang.NullPointerException
   at 
 javax.faces.component.UIComponentBase.restoreDeltaSystemEventListenerClassMap(UIComponentBase.java:1770)
   at 
 javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:1611)
   at javax.faces.component.UIViewRoot.restoreState(UIViewRoot.java:1161)
   at 
 org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:379)
   at 
 org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreView(DefaultFaceletsStateManagementStrategy.java:181)
   at 
 org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:388)
   at 
 org.apache.myfaces.view.ViewDeclarationLanguageBase.restoreView(ViewDeclarationLanguageBase.java:106)
   at 
 org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.restoreView(FaceletViewDeclarationLanguage.java:972)
   at 
 org.apache.myfaces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:231)
   at 
 org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:106)
   at 
 org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:129)
   at 
 org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:85)
   at 
 javax.faces.webapp.FacesServlet._handleStandardRequest(FacesServlet.java:453)
   ... 13 more
 In this scenario savedObject is an instance of _AttachedDeltaWrapper, but 
 _systemEventListenerClassMap is empty and so it returns null for 
 get(entry.getKey()). Thus a NullPointerException is thrown in the following 
 line (UIComponentBase.java:1770).

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

[jira] Updated: (MYFACES-2510) Remove RendererUtils.NOTHING

2010-02-02 Thread Leonardo Uribe (JIRA) 

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

Leonardo Uribe updated MYFACES-2510:


   Resolution: Fixed
Fix Version/s: 2.0.0-beta-2
 Assignee: Leonardo Uribe
   Status: Resolved  (was: Patch Available)

Thanks to Michael Kurz for provide this patch

 Remove RendererUtils.NOTHING
 

 Key: MYFACES-2510
 URL: https://issues.apache.org/jira/browse/MYFACES-2510
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-314
Affects Versions: 2.0.0-beta-2
Reporter: Michael Kurz
Assignee: Leonardo Uribe
 Fix For: 2.0.0-beta-2

 Attachments: MYFACES-2510.patch


 According to the spec, the submitted value for UISelectOne components must be 
 set to the empty string if there is no entry in the request parameter map. 
 Though this change is already covered in MYFACES-2356, some cleanup work 
 remains to be done.
 Previously the submitted value was set to RendererUtils.NOTHING in this case. 
 As this is no longer needed, it should be removed completely.

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

[jira] Updated: (MYFACES-2526) javax.faces.view.facelets.ResourceResolver support

2010-02-02 Thread Leonardo Uribe (JIRA) 

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

Leonardo Uribe updated MYFACES-2526:


   Resolution: Fixed
Fix Version/s: 2.0.0-beta-2
 Assignee: Leonardo Uribe
   Status: Resolved  (was: Patch Available)

Thanks to Martin Koci for this patch

 javax.faces.view.facelets.ResourceResolver support
 --

 Key: MYFACES-2526
 URL: https://issues.apache.org/jira/browse/MYFACES-2526
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-beta-2
 Environment: myfaces core trunk
Reporter: Martin Koci
Assignee: Leonardo Uribe
 Fix For: 2.0.0-beta-2

 Attachments: patch.MYFACES-2526


 Currently DefaultResourceResolver in myfaces implements a interface 
 ResourceResolver from o.a.m.v.f.i  (probably copy from old facelts 1.x). 
 JSF 2.0 introduce javax.faces.view.facelets.ResourceResolver as base class 
 for all ResourceResolvers. Specification 11.1.3 Application Configuration 
 Parameters describes it.
 Make ResourceResolver from o.a.m.v.f.i deprecated (or delete it) and modify 
 facelts stuff for using javax.faces ResourceResolver + add support for 
 decorator pattern.

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

RE: [Trinidad 2] Plugins branch moved

2010-02-02 Thread Maria Kaval 
Andrew, 

For trinidad-maven changes, do they need to be checked in to both 
Trinidad-maven/branches/2.0.x-branch and trinidad-maven/trunk or is it 
sufficient to just check into trinidad-maven/trunk and then someone will do a 
rebase for trinidad-maven/branches/2.0.x-branch on a periodic basis?  I'm 
thinking of e.g. JIRA 1677. 
https://issues.apache.org/jira/browse/TRINIDAD-1677

Thanks, Maria

-Original Message-
From: Andrew Robinson [mailto:andrew.rw.robin...@gmail.com] 
Sent: Wednesday, January 06, 2010 10:11 AM
To: MyFaces Development
Subject: [Trinidad 2] Plugins branch moved

Guys, with the okay from Matthias, I renamed the plugins 2.0 branch from:

https://svn.apache.org/repos/asf/myfaces/trinidad-maven/branches/2.0.0-branch

to

https://svn.apache.org/repos/asf/myfaces/trinidad-maven/branches/2.0.x-branch

So that it reflects the fact that the last digit is changing. This is
our trunk for the 2.0 plugins.

For existing working copies, run an svn switch to switch the URL to
the new name.

Thanks,
Andrew

Re: [Trinidad 2] Plugins branch moved

2010-02-02 Thread Matthias Wessendorf 
Hi Maria,

these the changes to trunk are being merged forward to the 2.x work.
For plugins that has not been done yet. For Trinidad core, we did.

I think generally it is about time to do another round of rebranching,
next week or so.
Why? Becuase developement on trunk is not stopping :-) and the longer
we wait, the
worse the final merge is. During that I can also merge the plugins work.

-Matthias

On Wed, Feb 3, 2010 at 6:50 AM, Maria Kaval maria.ka...@oracle.com wrote:
 Andrew,

 For trinidad-maven changes, do they need to be checked in to both 
 Trinidad-maven/branches/2.0.x-branch and trinidad-maven/trunk or is it 
 sufficient to just check into trinidad-maven/trunk and then someone will do a 
 rebase for trinidad-maven/branches/2.0.x-branch on a periodic basis?  I'm 
 thinking of e.g. JIRA 1677.
 https://issues.apache.org/jira/browse/TRINIDAD-1677

 Thanks, Maria

 -Original Message-
 From: Andrew Robinson [mailto:andrew.rw.robin...@gmail.com]
 Sent: Wednesday, January 06, 2010 10:11 AM
 To: MyFaces Development
 Subject: [Trinidad 2] Plugins branch moved

 Guys, with the okay from Matthias, I renamed the plugins 2.0 branch from:

 https://svn.apache.org/repos/asf/myfaces/trinidad-maven/branches/2.0.0-branch

 to

 https://svn.apache.org/repos/asf/myfaces/trinidad-maven/branches/2.0.x-branch

 So that it reflects the fact that the last digit is changing. This is
 our trunk for the 2.0 plugins.

 For existing working copies, run an svn switch to switch the URL to
 the new name.

 Thanks,
 Andrew




-- 
Matthias Wessendorf

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

Re: [Trinidad 2] Integrating JSF 2 AJAX support with Trinidad AJAX

2010-02-02 Thread Matthias Wessendorf 
Hello,

I appreciate the open communication. Using the combination of patches and wikis
(and someone that merges the changes from a tmp branch to
trinidad-branch) is fine.
If there are (big) questions on the code, that needs to be discussed
here as well.

Also Legal issues are also solved, as both signed the icla and they
are listed on Oralce's
CCLA. (Andy already has an Apache account).

Looking forward to read the wiki / patch

Thanks for the mail, Andrew!
-Matthias

On Wed, Feb 3, 2010 at 12:26 AM, Andrew Robinson arobinso...@apache.org wrote:
 Hey all, wanting to send a heads up:

 Pavitra Subramaniam and Andy Schwartz have spent a good amount of time
 looking into Trinidad 2 and what gaps there are with Trinidad 2 and
 JSF 2's AJAX implementation. Pavitra has also already done some work
 on her own and has got much of Trinidad working with the built-in JSF
 2 requests during some prototyping and her gap analysis. Andy is going
 to move their findings and results of their research into the MyFaces
 WIKI on the gaps, issues and begin a discussion on this list and on
 the WIKI about a phased strategy of migrating Trinidad.

 Pavitra created this JIRA ticket with her work so far:
 https://issues.apache.org/jira/browse/TRINIDAD-1704

 I also want to be help out with this effort and am planning on helping
 out with the client JavaScript side first I think.

 The three of us are employed by Oracle and have time allocated for
 assisting Trinidad 2 in this capacity and will be ensuring to be
 operating in the standard MyFaces development way, meaning both open,
 submitting patches, maintaining a WIKI and leveraging the mailing
 lists and JIRA.

 I created a private branch in SVN
 (https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax)
 so that the AJAX changes can be made gradually and only merged into
 the 2.0.x branch when it is stable enough to not break the 2.0.x
 branch.

 I just wanted to send this email out as a heads up so that the whole
 community is aware of the work that has already been done on research
 and Pavitra's initial work. Once Andy has written the WIKI, he or I
 will post the link as a reply in this thread so any community feedback
 can be made on this thread to make following this work easier.
 Basically I wanted to make sure that the submissions and help from
 Oracle is done in an open manner that is congruent to the modus
 operandi of the ASF.

 Once the WIKI is up, let me know if there is interest in helping out
 or if you have any comments on any of the suggested approaches.

 Thanks,
 Andrew




-- 
Matthias Wessendorf

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