[Trinidad] Pluto / Portal dependencies

2010-09-08 Thread Matthias Wessendorf
Hello Scott, Mike,

there are a few snapshot dependencies, on Pluto in here:
https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/pom.xml

Can those be updated ?

-Matthias

-- 
Matthias Wessendorf

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


Re: [VOTE] Trinidad core: 2.0.0 beta1

2010-09-08 Thread Matthias Wessendorf
(re)building..
:-)

On Wed, Sep 8, 2010 at 12:20 AM, Andrew Robinson
andrew.rw.robin...@gmail.com wrote:
 Please include the fix:
 https://issues.apache.org/jira/browse/TRINIDAD-1907

 On Tue, Sep 7, 2010 at 12:09 PM, Matthias Wessendorf mat...@apache.org 
 wrote:
 Ah, ok I see. Thanks for pointing it out!

 Jakob, can you take over on your fix for Trinidad-1902 ?

 -Matthias

 On Tue, Sep 7, 2010 at 8:00 PM, Andrew Robinson
 andrew.rw.robin...@gmail.com wrote:
 -0.5

 It appears that the fix for TRINIDAD-1902 has some drawbacks that
 cause some severe errors. The PseudoFacesContext.getViewRoot() throws
 an unsupported operation exception when called. It should probably
 just return null instead as that is what is expected when the view has
 not be created/restored yet.

 I would say that this should be fixed before a release.

 -Andrew



 On Tue, Sep 7, 2010 at 8:39 AM, Matthias Wessendorf mat...@apache.org 
 wrote:
 Hi,

 I was running the needed tasks to get the first beta release of the Apache
 MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private
 Apache account ([1]).

 Please take a look at the 2.0.0-beta1 artifacts and vote.
 Main diff between the other alphas is that ajax support has been added.

 
 [ ] +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,
 Matthias

 [1] http://people.apache.org/~matzew/staging_repo/

 --
 Matthias Wessendorf

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





 --
 Matthias Wessendorf

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





-- 
Matthias Wessendorf

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


Re: [COMMUNITY] MyFaces += Martin Kočí

2010-09-08 Thread Martin Marinschek
Hi Martin,

welcome aboard!

great to have you around!

best regards,

Martin

On 9/7/10, Martin Koci martin.k...@aura.cz wrote:
 Hi,

 it's an honour for me, thanks for inviting me to this great community.

 Just for curiosity I found this:
 https://issues.apache.org/jira/browse/MYFACES-1171 - reported by me more
 than four years ago - time runs so fast! That reminds me: I started with
 JSF 0.4 EA - do you remember h:command_button tag with underscore :) ?
 Over time I participated in development of more than five large systems
 with JSF based GUI and experiences I'll share with you here.


 Thanks,

 Martin Kočí

 Matthias Wessendorf píše v Út 07. 09. 2010 v 16:50 +0200:
 The Myfaces PMC is proud to announce a new addition to our community.

 Please welcome Martin Kočí as the newest MyFaces committer!
 Ali is an active member of the myfaces community. He started on
 contributing to Trinidad and was a great resource recently on MyFaces
 core.


 @Martin: Please add yourself to the Master-POM at
 https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml






-- 

http://www.irian.at

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

Professional Support for Apache MyFaces


submittedValue vs. Converter.getAsObject

2010-09-08 Thread Martin Koci
Hi,

maybe this is a stupid question but:

From UIInput javadoc:

... decoded value of this component, usually but not necessarily a
String, must be stored - but not yet converted - using
setSubmittedValue() 


from UIInput.getConvertedValue:

... and the submitted value is a String, locate a Converter as
follows

Question: why is Converter tied  only to String? Whole specification
speaks about submitted value as of raw representation of value from
client but not necessarily String. And 3.3 Conversion Model: This
section describes the facilities provided by JavaServer Faces to support
type conversion between server-side Java objects and their (typically
String-based) representation in presentation markup.
But Converter.getAsObject expects only String as this raw
representation and typically String-based formulation from spec now
means always String-based.
It seems to me that Converter introduces unnecessary dependency on
String-based representation - even ResponseWriter.write* accepts
java.lang.Object as value 

What I try to do is JSF-based server view with custom NOT-string based
protocol where raw representations from client can be java object like
Integer or more complex. Creating of:

interface Converter2 {
Object getAsObject(FacesContext,UIComponent,Object)
Object getAsRepresentation(FacesContext,UIComponent,Object)
}

solves my problem but I must reprogram significant part of JSF api.

Does anybody know the backgroud of this? Yes, this is question for EG
but this mailing list more open ...

Related issue: https://issues.apache.org/jira/browse/MYFACES-2910 (only
part of the problem)

Regards,

Kocicak






[jira] Commented: (TOMAHAWK-1548) Allow t:dataScroller to be Ajaxified using f:ajax

2010-09-08 Thread Werner Punz (JIRA)

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

Werner Punz commented on TOMAHAWK-1548:
---

Hey Leo, this is absolutely nice stuff...



 Allow t:dataScroller to be Ajaxified using f:ajax
 -

 Key: TOMAHAWK-1548
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1548
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: Data Scroller
Affects Versions: 1.1.9
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Fix For: 1.1.10-SNAPSHOT


 After thinking a lot about it, to make it possible we need to do some things:
 - If no facet or paginator is rendered, render a div and the id, so when 
 ajax occur it could be replaced.
 - If a facet or paginator is rendered, if an id is set render it.
 - Add click, dblclick and action client events and copy them for all 
 facets and paginator links.
 - Add action as default event name.
 In this way, we can add f:ajax tag inside t:dataScroller to tell when a link 
 is click, which elements should be updated (usually the related dataTable).

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



Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Matthias Wessendorf
Hello,

in Trinidad we don't cast to String:

http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/xhtml/EditableValueRenderer.java?view=annotate

(see line 133-135)

This is because of supporting the oracle adf numbers, like:
http://download.oracle.com/docs/cd/E12839_01/apirefs./e10655/index.html?oracle/jbo/domain/Number.html

The fix is simple: call toString() instead of doing the cast.

However, I think your patch misses the case of tolerating NULL (new w/ jsf2)

-Matthias

On Tue, Sep 7, 2010 at 11:05 PM, Martin Koci
martin.kocicak.k...@gmail.com wrote:
 Hi,

 maybe this is a stupid question but:

 From UIInput javadoc:

 ... decoded value of this component, usually but not necessarily a
 String, must be stored - but not yet converted - using
 setSubmittedValue() 


 from UIInput.getConvertedValue:

 ... and the submitted value is a String, locate a Converter as
 follows

 Question: why is Converter tied  only to String? Whole specification
 speaks about submitted value as of raw representation of value from
 client but not necessarily String. And 3.3 Conversion Model: This
 section describes the facilities provided by JavaServer Faces to support
 type conversion between server-side Java objects and their (typically
 String-based) representation in presentation markup.
 But Converter.getAsObject expects only String as this raw
 representation and typically String-based formulation from spec now
 means always String-based.
 It seems to me that Converter introduces unnecessary dependency on
 String-based representation - even ResponseWriter.write* accepts
 java.lang.Object as value 

 What I try to do is JSF-based server view with custom NOT-string based
 protocol where raw representations from client can be java object like
 Integer or more complex. Creating of:

 interface Converter2 {
 Object getAsObject(FacesContext,UIComponent,Object)
 Object getAsRepresentation(FacesContext,UIComponent,Object)
 }

 solves my problem but I must reprogram significant part of JSF api.

 Does anybody know the backgroud of this? Yes, this is question for EG
 but this mailing list more open ...

 Related issue: https://issues.apache.org/jira/browse/MYFACES-2910 (only
 part of the problem)

 Regards,

 Kocicak








-- 
Matthias Wessendorf

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


[jira] Commented: (MYFACES-2910) Allow non-String submitted values

2010-09-08 Thread JIRA

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

Matthias Weßendorf commented on MYFACES-2910:
-

.toString() is acutally right - but not sure what the TCK says...
would be interesting to test it

 Allow non-String submitted values 
 --

 Key: MYFACES-2910
 URL: https://issues.apache.org/jira/browse/MYFACES-2910
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-314
Affects Versions: 2.0.2-SNAPSHOT
 Environment: myfaces trunk
Reporter: Martin Kočí
Priority: Minor
 Attachments: MYFACES-2910.patch


 Myfaces are too strict and always assume submitted value as String. Comparing 
 with Mojarra and Trinidad:
 1)org.apache.myfaces.shared.renderkit.RendererUtils.getStringValue(FacesContext,
  UIComponent):
 myfaces: IllegalArgumentException (Submitted value of type String expected)
 mojarra, trinidad: call EditableValueHolder.getSubmittedValue().toString() in 
 this situation
 2) 
 org.apache.myfaces.shared_impl.renderkit.RendererUtils.getConvertedUIOutputValue(FacesContext,
  UIOutput, Object)
 myfaces: IllegalArgumentException(Submitted value of type String expected)
 mojarra: CastClassExpection if sumbittedValue is not String
 trinidad: class submittedValue.toString in this situation
 toString() solution will handle all situations and will allow submitted 
 values other type than String 

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



[jira] Commented: (MYFACES-2910) Allow non-String submitted values

2010-09-08 Thread JIRA

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

Matthias Weßendorf commented on MYFACES-2910:
-

more on calling toString() 

http://markmail.org/message/xzj4c6pevmpf33cq

 Allow non-String submitted values 
 --

 Key: MYFACES-2910
 URL: https://issues.apache.org/jira/browse/MYFACES-2910
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-314
Affects Versions: 2.0.2-SNAPSHOT
 Environment: myfaces trunk
Reporter: Martin Kočí
Priority: Minor
 Attachments: MYFACES-2910.patch


 Myfaces are too strict and always assume submitted value as String. Comparing 
 with Mojarra and Trinidad:
 1)org.apache.myfaces.shared.renderkit.RendererUtils.getStringValue(FacesContext,
  UIComponent):
 myfaces: IllegalArgumentException (Submitted value of type String expected)
 mojarra, trinidad: call EditableValueHolder.getSubmittedValue().toString() in 
 this situation
 2) 
 org.apache.myfaces.shared_impl.renderkit.RendererUtils.getConvertedUIOutputValue(FacesContext,
  UIOutput, Object)
 myfaces: IllegalArgumentException(Submitted value of type String expected)
 mojarra: CastClassExpection if sumbittedValue is not String
 trinidad: class submittedValue.toString in this situation
 toString() solution will handle all situations and will allow submitted 
 values other type than String 

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



Re: [COMMUNITY] MyFaces += Martin Kočí

2010-09-08 Thread Martin Koci

And I almost forgot to write: in order to not mix frequent name Martin
in this mailing list I'll use preferably email Martin.Kocicak.Koci at
gmail dot com and Kocicak as nickname.

P.S. Kocicak (Kočičák in Czech) is a untranslatable pun based on my last
name and also a popular character from one bedtime story :)

Martin Koci píše v Út 07. 09. 2010 v 21:33 +0200: 
 Hi,
 
 it's an honour for me, thanks for inviting me to this great community.
 
 Just for curiosity I found this:
 https://issues.apache.org/jira/browse/MYFACES-1171 - reported by me more
 than four years ago - time runs so fast! That reminds me: I started with
 JSF 0.4 EA - do you remember h:command_button tag with underscore :) ?
 Over time I participated in development of more than five large systems
 with JSF based GUI and experiences I'll share with you here.
 
 
 Thanks,
 
 Martin Kočí
 
 Matthias Wessendorf píše v Út 07. 09. 2010 v 16:50 +0200:
  The Myfaces PMC is proud to announce a new addition to our community.
  
  Please welcome Martin Kočí as the newest MyFaces committer!
  Ali is an active member of the myfaces community. He started on
  contributing to Trinidad and was a great resource recently on MyFaces core.
  
  
  @Martin: Please add yourself to the Master-POM at
  https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml
  
 
 
 





Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Martin Koci

Matthias Wessendorf píše v St 08. 09. 2010 v 11:22 +0200:
 Hello,
 
 in Trinidad we don't cast to String:
 
 http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/xhtml/EditableValueRenderer.java?view=annotate
 
 (see line 133-135)
yes, trinidad handles this situation best - mojarra casts to String in
second case described in MYFACES-2910. 

 This is because of supporting the oracle adf numbers, like:
 http://download.oracle.com/docs/cd/E12839_01/apirefs./e10655/index.html?oracle/jbo/domain/Number.html

I use similar solution but it requires unique String representation -
Object relation. This can be easily done for Numbers and other
primitive types in Java but I must deal with types where unique String
represenation does not exists or requires a lot of effort. 
So on JSF level conversion String - Object is unable to solve this
problem - I simply need Object - Object conversion which is not
supported yet.

 
 The fix is simple: call toString() instead of doing the cast.
 
 However, I think your patch misses the case of tolerating NULL (new w/ jsf2)
 
 -Matthias
 
 On Tue, Sep 7, 2010 at 11:05 PM, Martin Koci
 martin.kocicak.k...@gmail.com wrote:
  Hi,
 
  maybe this is a stupid question but:
 
  From UIInput javadoc:
 
  ... decoded value of this component, usually but not necessarily a
  String, must be stored - but not yet converted - using
  setSubmittedValue() 
 
 
  from UIInput.getConvertedValue:
 
  ... and the submitted value is a String, locate a Converter as
  follows
 
  Question: why is Converter tied  only to String? Whole specification
  speaks about submitted value as of raw representation of value from
  client but not necessarily String. And 3.3 Conversion Model: This
  section describes the facilities provided by JavaServer Faces to support
  type conversion between server-side Java objects and their (typically
  String-based) representation in presentation markup.
  But Converter.getAsObject expects only String as this raw
  representation and typically String-based formulation from spec now
  means always String-based.
  It seems to me that Converter introduces unnecessary dependency on
  String-based representation - even ResponseWriter.write* accepts
  java.lang.Object as value 
 
  What I try to do is JSF-based server view with custom NOT-string based
  protocol where raw representations from client can be java object like
  Integer or more complex. Creating of:
 
  interface Converter2 {
  Object getAsObject(FacesContext,UIComponent,Object)
  Object getAsRepresentation(FacesContext,UIComponent,Object)
  }
 
  solves my problem but I must reprogram significant part of JSF api.
 
  Does anybody know the backgroud of this? Yes, this is question for EG
  but this mailing list more open ...
 
  Related issue: https://issues.apache.org/jira/browse/MYFACES-2910 (only
  part of the problem)
 
  Regards,
 
  Kocicak
 
 
 
 
 
 
 
 




Re: [COMMUNITY] MyFaces += Martin Kočí

2010-09-08 Thread Bruno Aranda
Wellcome aboard, untranslatable Kočičák! :)

Cheers,

Bruno

On 8 September 2010 10:59, Martin Koci martin.kocicak.k...@gmail.comwrote:


 And I almost forgot to write: in order to not mix frequent name Martin
 in this mailing list I'll use preferably email Martin.Kocicak.Koci at
 gmail dot com and Kocicak as nickname.

 P.S. Kocicak (Kočičák in Czech) is a untranslatable pun based on my last
 name and also a popular character from one bedtime story :)

 Martin Koci píše v Út 07. 09. 2010 v 21:33 +0200:
  Hi,
 
  it's an honour for me, thanks for inviting me to this great community.
 
  Just for curiosity I found this:
  https://issues.apache.org/jira/browse/MYFACES-1171 - reported by me more
  than four years ago - time runs so fast! That reminds me: I started with
  JSF 0.4 EA - do you remember h:command_button tag with underscore :) ?
  Over time I participated in development of more than five large systems
  with JSF based GUI and experiences I'll share with you here.
 
 
  Thanks,
 
  Martin Kočí
 
  Matthias Wessendorf píše v Út 07. 09. 2010 v 16:50 +0200:
   The Myfaces PMC is proud to announce a new addition to our community.
  
   Please welcome Martin Kočí as the newest MyFaces committer!
   Ali is an active member of the myfaces community. He started on
   contributing to Trinidad and was a great resource recently on MyFaces
 core.
  
  
   @Martin: Please add yourself to the Master-POM at
  
 https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml
  
 
 
 






Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Martin Marinschek
Hi Kocicak,

 So on JSF level conversion String - Object is unable to solve this
 problem - I simply need Object - Object conversion which is not
 supported yet.

Yes, this is true - this is obviously a spec problem.

If the submitted value is an object, it should also be allowed to
convert it. A converter is more than just a string to object (and
back) converter, it is an artefact which transforms information from
its representation for output (and this output could be anything, and
certainly doesn't have to be string based) to its representation which
the business model (or also an artefact within JSF, like a validator)
understands.

So I agree. This hasn't come up so far cause nobody uses non string
based output models for JSF.

Note that my notion of a business converter (discussed on this mailing
list a while ago) for converting between a business model
representation and a representation in a JSF artefact like the
renderer (e.g. you use joda.Date in the business model, but the JSF
date picker renderer only understands the normal java date) is also
hinting in the direction that such an additional converter API would
be necessary. I discussed this with the EG (and also Ed privately),
and there wasn't much interest for adding this.

best regards,

Martin

best regards,

Martin

-- 

http://www.irian.at

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

Professional Support for Apache MyFaces


Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Martin Marinschek
 I discussed this with the EG (and also Ed privately),
 and there wasn't much interest for adding this.

P.S.: it might however be useful to have this in the MyFaces
implementation somehow.

@Leonardo: did you actually provide a business-converter interface -
we discussed about this?

best regards,

Martin

 --

 http://www.irian.at

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

 Professional Support for Apache MyFaces



-- 

http://www.irian.at

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

Professional Support for Apache MyFaces


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

2010-09-08 Thread Werner Punz (JIRA)

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

Werner Punz commented on MYFACES-2876:
--

Btw. regarding Blackberries, I only can go down to version 5 so far, I have not 
been able to get a version 4.7 emulator up and running so that it connects to 
the net and loads pages. No run no support from my side, sorry.


 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.



Re: [VOTE] Trinidad core: 2.0.0 beta1

2010-09-08 Thread Matthias Wessendorf
btw. it has been replaced

On Wed, Sep 8, 2010 at 8:41 AM, Matthias Wessendorf mat...@apache.org wrote:
 (re)building..
 :-)

 On Wed, Sep 8, 2010 at 12:20 AM, Andrew Robinson
 andrew.rw.robin...@gmail.com wrote:
 Please include the fix:
 https://issues.apache.org/jira/browse/TRINIDAD-1907

 On Tue, Sep 7, 2010 at 12:09 PM, Matthias Wessendorf mat...@apache.org 
 wrote:
 Ah, ok I see. Thanks for pointing it out!

 Jakob, can you take over on your fix for Trinidad-1902 ?

 -Matthias

 On Tue, Sep 7, 2010 at 8:00 PM, Andrew Robinson
 andrew.rw.robin...@gmail.com wrote:
 -0.5

 It appears that the fix for TRINIDAD-1902 has some drawbacks that
 cause some severe errors. The PseudoFacesContext.getViewRoot() throws
 an unsupported operation exception when called. It should probably
 just return null instead as that is what is expected when the view has
 not be created/restored yet.

 I would say that this should be fixed before a release.

 -Andrew



 On Tue, Sep 7, 2010 at 8:39 AM, Matthias Wessendorf mat...@apache.org 
 wrote:
 Hi,

 I was running the needed tasks to get the first beta release of the Apache
 MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private
 Apache account ([1]).

 Please take a look at the 2.0.0-beta1 artifacts and vote.
 Main diff between the other alphas is that ajax support has been added.

 
 [ ] +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,
 Matthias

 [1] http://people.apache.org/~matzew/staging_repo/

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




-- 
Matthias Wessendorf

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


Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Leonardo Uribe
Hi Martin

Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear
an interface like that was necessary but it is tied to java.util.Date in
this case:

/**
 * Provide a bridge between the java.util.Date instance used by a component
 * that receive date/time values and the business value used to represent
 * the value.
*/
public interface DateBusinessConverter
{
/**
 * Convert the java.util.Date instance calculated from submittedValue,
 * so the resulting object will be used later as the converted value
 * and validation.
 */
public Object getBusinessValue(FacesContext context,
   UIComponent component,
   java.util.Date value);

/**
 * Used to retrieve the value stored in the business bean and convert
 * it in a representation that the component (t:inputCalendar and
 * t:inputDate for example)using this class can manipulate.
 */
public java.util.Date getDateValue(FacesContext context,
   UIComponent component,
   Object value);
}

This two components requires a date/time interface, and in this case the
choice was java.util.Date, to keep things simple, and to indicate that
internally, t:inputCalendar and t:inputDate only understands
java.util.Date for rendering.

best regards,

Leonardo

2010/9/8 Martin Marinschek mmarinsc...@apache.org

  I discussed this with the EG (and also Ed privately),
  and there wasn't much interest for adding this.

 P.S.: it might however be useful to have this in the MyFaces
 implementation somehow.

 @Leonardo: did you actually provide a business-converter interface -
 we discussed about this?

 best regards,

 Martin

  --
 
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 


 --

 http://www.irian.at

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

 Professional Support for Apache MyFaces



Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Matthias Wessendorf
In Trinidad internal package there is a TypeConverter, use in the
Date/Number converter (internals) of Trinidad.

has a factory and some more stuff, perhaps worth to check (they were
introduced - looong time ago - to support the
mentioned oracle types, from the binding layer)

-M

On Wed, Sep 8, 2010 at 4:27 PM, Leonardo Uribe lu4...@gmail.com wrote:
 Hi Martin

 Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear
 an interface like that was necessary but it is tied to java.util.Date in
 this case:

 /**
  * Provide a bridge between the java.util.Date instance used by a component
  * that receive date/time values and the business value used to represent
  * the value.
 */
 public interface DateBusinessConverter
 {
     /**
  * Convert the java.util.Date instance calculated from submittedValue,
  * so the resulting object will be used later as the converted value
  * and validation.
  */
     public Object getBusinessValue(FacesContext context,
    UIComponent component,
    java.util.Date value);

     /**
  * Used to retrieve the value stored in the business bean and convert
  * it in a representation that the component (t:inputCalendar and
  * t:inputDate for example)using this class can manipulate.
  */
     public java.util.Date getDateValue(FacesContext context,
    UIComponent component,
    Object value);
 }

 This two components requires a date/time interface, and in this case the
 choice was java.util.Date, to keep things simple, and to indicate that
 internally, t:inputCalendar and t:inputDate only understands
 java.util.Date for rendering.

 best regards,

 Leonardo

 2010/9/8 Martin Marinschek mmarinsc...@apache.org

  I discussed this with the EG (and also Ed privately),
  and there wasn't much interest for adding this.

 P.S.: it might however be useful to have this in the MyFaces
 implementation somehow.

 @Leonardo: did you actually provide a business-converter interface -
 we discussed about this?

 best regards,

 Martin

  --
 
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 


 --

 http://www.irian.at

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

 Professional Support for Apache MyFaces





-- 
Matthias Wessendorf

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


Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Martin Marinschek
Hi Leo,

 Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear
 an interface like that was necessary but it is tied to java.util.Date in
 this case:

We could open an issue to make this more generic - and have an
infrastructure in the impl where we can register such converters. Then
we could use them for such use-cases as we have, and also for Martin's
use-cases.

best regards,

Martin

-- 

http://www.irian.at

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

Professional Support for Apache MyFaces


[jira] Commented: (TRINIDAD-1890) NullPointerException when using file upload with trinidad

2010-09-08 Thread JIRA

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

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

what version r u using? Works fine here

 NullPointerException when using file upload with trinidad
 -

 Key: TRINIDAD-1890
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1890
 Project: MyFaces Trinidad
  Issue Type: Bug
 Environment: Linux x64
 Java 1.6
Reporter: Thomas Müller

 Hi,
 I tried to use the file upload in trinidad. When I want to submit a file, I 
 get ther following exception:
 java.lang.NullPointerException
   
 org.apache.myfaces.trinidadinternal.config.upload.UploadRequestWrapper.setCharacterEncoding(UploadRequestWrapper.java:83)
   
 com.sun.faces.context.ExternalContextImpl.setRequestCharacterEncoding(ExternalContextImpl.java:165)
   
 org.apache.myfaces.trinidad.context.ExternalContextDecorator.setRequestCharacterEncoding(ExternalContextDecorator.java:266)
   
 org.apache.myfaces.trinidad.context.ExternalContextDecorator.setRequestCharacterEncoding(ExternalContextDecorator.java:266)
   javax.faces.application.ViewHandler.initView(ViewHandler.java:270)
   
 com.sun.faces.application.ViewHandlerImpl.initView(ViewHandlerImpl.java:119)
   
 javax.faces.application.ViewHandlerWrapper.initView(ViewHandlerWrapper.java:175)
   
 com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:102)
   com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
   javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
 Can you help me if this is a bug or something is wrong in my enviroment 
 properties?
 web.xml:
 ?xml version=1.0 encoding=UTF-8?
 web-app id=WebApp_ID version=2.5 xmlns=http://java.sun.com/xml/ns/j2ee; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://java.sun.com/xml/ns/javaee 
 http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
   display-namepferdemarkt.tv/display-name
   welcome-file-list
 welcome-fileindex.html/welcome-file
 welcome-fileindex.htm/welcome-file
 welcome-fileindex.jsp/welcome-file
 welcome-filedefault.html/welcome-file
 welcome-filedefault.htm/welcome-file
 welcome-filedefault.jsp/welcome-file
   /welcome-file-list
   jsp-config
 jsp-property-group
   url-pattern*.jsp/url-pattern
   url-pattern*.jspf/url-pattern
   page-encodingUTF-8/page-encoding
   scripting-invalidtrue/scripting-invalid
   is-xmltrue/is-xml
 /jsp-property-group
   /jsp-config
   context-param
 param-namejavax.faces.STATE_SAVING_METHOD/param-name
 param-valueclient/param-value
   /context-param
   context-param
 param-namecom.sun.faces.enableLazyBeanValidation/param-name
 param-valuefalse/param-value
   /context-param
   context-param
 param-namecom.sun.faces.validateXml/param-name
 param-valuefalse/param-value
   /context-param
   context-param
 param-namecom.sun.faces.verifyObjects/param-name
 param-valuefalse/param-value
   /context-param
   
 context-param
 !-- Maximum memory per request (in bytes) --
 param-nameorg.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY/param-name
 !-- Use 500K --
 param-value512000/param-value
   /context-param
   context-param
 !-- Maximum disk space per request (in bytes) --
 param-nameorg.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE/param-name
 !-- Use 5,000K --
 param-value512/param-value
   /context-param
   context-param
 !-- directory to store temporary files --
 param-nameorg.apache.myfaces.trinidad.UPLOAD_TEMP_DIR/param-name
 !-- Use a TrinidadUploads subdirectory of /tmp --
 param-value/tmp//param-value
   /context-param
   
   !-- Faces Servlet --
   servlet
 servlet-nameFaces Servlet/servlet-name
 servlet-classjavax.faces.webapp.FacesServlet/servlet-class
 load-on-startup1/load-on-startup
   /servlet
   servlet-mapping
 servlet-nameFaces Servlet/servlet-name
 url-pattern*.html/url-pattern
   /servlet-mapping
   
 filter
 filter-nametrinidad/filter-name
 
 filter-classorg.apache.myfaces.trinidad.webapp.TrinidadFilter/filter-class
   /filter
   filter-mapping
 filter-nametrinidad/filter-name
 !-- This assumes that the FacesServlet has been registered --
 !-- under the name faces --
 servlet-namefaces/servlet-name
   /filter-mapping
 servlet
   servlet-nameresources/servlet-name
   
 servlet-classorg.apache.myfaces.trinidad.webapp.ResourceServlet/servlet-class
  /servlet
 !-- This cannot be configured currently --
 servlet-mapping
 servlet-nameresources/servlet-name
 url-pattern/adf/*/url-pattern
 /servlet-mapping
   
 /web-app
 faces-config.xml:
 ?xml version=1.0 encoding=UTF-8?

[jira] Commented: (TRINIDAD-1737) LocaleSymbols* at LocaleElements*.js files are empty in 1.0.12 release

2010-09-08 Thread JIRA

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

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

problem is that iw was build w/ Java6

re-running a release now...

 LocaleSymbols* at LocaleElements*.js files are empty in 1.0.12 release
 --

 Key: TRINIDAD-1737
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1737
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 1.0.12-core
Reporter: Rafael Pérez
Priority: Critical

 Locale*.js files are not getting filled properly for any locale. For example, 
 the file at 
 http://localhost:8080/trinidad-demo/adf/jsLibs/resources/LocaleElements_en1_0_11.js?loc=en
 Looks in 1.0.12 as:
 var LocaleSymbols_en = new LocaleSymbols({
 });
 TrMessageFactory._TRANSLATIONS={
 'org.apache.myfaces.trinidad.validator.DoubleRangeValidator.NOT_IN_RANGE_detail':'The
  number must be between {2} and {3}.',
 ...
 }
 And it should be (as in 1.0.11):
 var LocaleSymbols_en = new LocaleSymbols({
 MonthNames:[January, February, March, April, May, June, July, 
 August, September, October, November, December, ], 
 MonthAbbreviations:[Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, 
 Sep, Oct, Nov, Dec, ], 
 DayNames:[Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, 
 Saturday], 
 DayAbbreviations:[Sun, Mon, Tue, Wed, Thu, Fri, Sat], 
 AmPmMarkers:[AM, PM], 
 Eras:[BC, AD], 
 DateTimePatterns:[h:mm:ss a z, h:mm:ss a z, h:mm:ss a, h:mm a, , 
  d, ,  d, , MMM d, , M/d/yy, {1} {0}], 
 DateTimeElements:[1, 1], 
 NumberElements:[., ,, ;, %, 0, #, -, E, \u2030, \u221e, 
 \ufffd], 
 CurrencyElements:[\xa4, XXX, \xa4, , -\xa4, ]
 });
 TrMessageFactory._TRANSLATIONS={
 'org.apache.myfaces.trinidad.validator.DoubleRangeValidator.NOT_IN_RANGE_detail':'The
  number must be between {2} and {3}.',
 ...
 }

-- 
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-09-08 Thread Vaclav Tregner (JIRA)

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

Vaclav Tregner commented on TRINIDAD-195:
-

Bug can be still reproduced in Trinidad 1.2.13. Where can I find the patch?
Thanks

 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.



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

2010-09-08 Thread Blake Sullivan (JIRA)

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

Blake Sullivan commented on TRINIDAD-195:
-

The problem definitely exists.  The correct solution is to add a setIfAbsent 
method to the factories and call that instead of setFactory().


 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.



Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Leonardo Uribe
Hi Martin

2010/9/8 Martin Marinschek mmarinsc...@apache.org

 Hi Leo,

  Yes, to solve the problem with t:inputCalendar and t:inputDate it was
 clear
  an interface like that was necessary but it is tied to java.util.Date in
  this case:

 We could open an issue to make this more generic - and have an
 infrastructure in the impl where we can register such converters. Then
 we could use them for such use-cases as we have, and also for Martin's
 use-cases.


Ok, I'll check in deep what trinidad does and why and later I'll open an
issue for this one on
the jsf spec issue tracker.

best regards,

Leonardo


 best regards,

 Martin

 --

 http://www.irian.at

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

 Professional Support for Apache MyFaces



Re: [DISCUSS] [GSoC] Automated webapp test framework integration

2010-09-08 Thread Jakob Korherr
Hi,

I just created the webapptest component for MYFACESTEST in the JIRA. Feel
free to open issues!!

@Leonardo:

It runs with JUnit, actually, and yes I also noticed it needs Java 1.6, but
this is only because of the java.util.ServiceLoader, I guess. I saw that you
already changed the import to the ServiceLoader class of Arquillian - maybe
we can now use Java 1.5 (which is IMO preferred, because core 2.0 also uses
it).

Regards,
Jakob

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

 Hi

 Ok, it seems it is not tied to maven lifecycle, but runs with eclipse. It
 says it requires java 1.5 but it is not true, it requires java 1.6.

 regards,

 Leonardo

 2010/9/7 Leonardo Uribe lu4...@gmail.com

 Hi

 How that stuff work? I thought that it was only necessary to run it using
 maven goals or something like that, but for my surprise it is not. In the
 documentation left there are no instructions about how to do a simple test
 helloworld app.

 regards,

 Leonardo Uribe

 2010/9/7 Leonardo Uribe lu4...@gmail.com

 +1

 I'll start to work on some test for ajax using that stuff.

 regards,

 Leonardo

 2010/9/7 Rudy De Busscher rdebussc...@gmail.com

 +1

 Try to add my 5 or so improvements this weekend.

 Regards
 Rudy.


 On 7 September 2010 11:23, Gerhard gerhard.petra...@gmail.com wrote:

 +1

 regards,
 gerhard

 http://www.irian.at

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

 Professional Support for Apache MyFaces



 2010/9/7 Jakob Korherr jakob.korh...@gmail.com

  Hi,

 I just committed the webapptest project into the gsoc folder. Now we
 can start to improve it in order to be able to do a first alpha
 release.

 In addition I'd like to create a webapptest component for the
 MYFACESTEST project in the JIRA. Any objections or better ideas?

 Regards,
 Jakob

 2010/9/6 Jakob Korherr jakob.korh...@gmail.com:
  Hi,
 
  Thinking about it, it may be better at the moment to commit it into
 the gsoc
  folder and enhance it first. Then when we think we can do the first
 alpha
  release, we can move it into a different folder.
 
  However I really think that it should be separated from
 MyFaces-test, since
  MyFaces-test is a mocking framework and webapp-test is kind of an
  integration testing framework. But we can deal with this question
 later.
 
  Regards,
  Jakob
 
  2010/9/4 Leonardo Uribe lu4...@gmail.com
 
  Hi
 
  No objections for my side, but could you be more explicit about
 what you
  gonna do? Do you want to include it as a separate module for
 myfaces-test
  (note this requires an official vote)? or maybe create a branch on
  myfaces-test so we can enhance it and when it is ready, do some
 alpha/beta
  releases?.
 
  regards,
 
  Leonardo Uribe
 
  2010/9/4 Jakob Korherr jakob.korh...@gmail.com
 
  Hi,
 
  If no objections I'll start the integration today into
  myfaces/test/webapptest.
 
  Regards,
  Jakob
 
  2010/8/23 Jakob Korherr jakob.korh...@gmail.com
 
  Hi,
 
  Since GSoC is over, we can now integrate the code into our
 codebase. The
  code currently lives in a google code project [1].
 
  Because of the fact that this is a test framework, I would really
 like
  to put it into the test folder rather then creating a new
  (myfaces-)top-level entry. However I do not want to integrate it
 into the
  current MyFaces test framework (that currently lives in the
 test folder),
  because this is a completely different thing and IMO we have to
 be able to
  do separate releases of those two.
 
  In addition I would like to create a new project in the JIRA for
 the
  automated webapp tests framework. Something like WEBAPPTEST.
 Suggestions are
  welcome!
 
  What do you think? Any objections, thoughts, ideas?
 
  Thanks for looking into this!
 
  Regards,
  Jakob
 
 
  [1] http://code.google.com/p/gsoc2010-automated-myfaces-tests/
 
  --
  Jakob Korherr
 
  blog: http://www.jakobk.com
  twitter: http://twitter.com/jakobkorherr
  work: http://www.irian.at
 
 
 
  --
  Jakob Korherr
 
  blog: http://www.jakobk.com
  twitter: http://twitter.com/jakobkorherr
  work: http://www.irian.at
 
 
 
 
  --
  Jakob Korherr
 
  blog: http://www.jakobk.com
  twitter: http://twitter.com/jakobkorherr
  work: http://www.irian.at
 



 --
 Jakob Korherr

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









-- 
Jakob Korherr

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


Re: [DISCUSS] [GSoC] Automated webapp test framework integration

2010-09-08 Thread Leonardo Uribe
Hi

2010/9/8 Jakob Korherr jakob.korh...@gmail.com

 Hi,

 I just created the webapptest component for MYFACESTEST in the JIRA. Feel
 free to open issues!!

 @Leonardo:

 It runs with JUnit, actually, and yes I also noticed it needs Java 1.6, but
 this is only because of the java.util.ServiceLoader, I guess. I saw that you
 already changed the import to the ServiceLoader class of Arquillian - maybe
 we can now use Java 1.5 (which is IMO preferred, because core 2.0 also uses
 it).


Yes,  It could be good to set it as java 1.5 compatible.  I'm doing some
tests about this stuff to see how it works, and how we can enhance it (for
example, test should run on the integration-test lifecycle). It will take
some time.

regards,

Leonardo


 Regards,
 Jakob

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

 Hi

 Ok, it seems it is not tied to maven lifecycle, but runs with eclipse. It
 says it requires java 1.5 but it is not true, it requires java 1.6.

 regards,

 Leonardo

 2010/9/7 Leonardo Uribe lu4...@gmail.com

 Hi

 How that stuff work? I thought that it was only necessary to run it using
 maven goals or something like that, but for my surprise it is not. In the
 documentation left there are no instructions about how to do a simple test
 helloworld app.

 regards,

 Leonardo Uribe

 2010/9/7 Leonardo Uribe lu4...@gmail.com

 +1

 I'll start to work on some test for ajax using that stuff.

 regards,

 Leonardo

 2010/9/7 Rudy De Busscher rdebussc...@gmail.com

 +1

 Try to add my 5 or so improvements this weekend.

 Regards
 Rudy.


 On 7 September 2010 11:23, Gerhard gerhard.petra...@gmail.com wrote:

 +1

 regards,
 gerhard

 http://www.irian.at

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

 Professional Support for Apache MyFaces



 2010/9/7 Jakob Korherr jakob.korh...@gmail.com

  Hi,

 I just committed the webapptest project into the gsoc folder. Now we
 can start to improve it in order to be able to do a first alpha
 release.

 In addition I'd like to create a webapptest component for the
 MYFACESTEST project in the JIRA. Any objections or better ideas?

 Regards,
 Jakob

 2010/9/6 Jakob Korherr jakob.korh...@gmail.com:
  Hi,
 
  Thinking about it, it may be better at the moment to commit it into
 the gsoc
  folder and enhance it first. Then when we think we can do the first
 alpha
  release, we can move it into a different folder.
 
  However I really think that it should be separated from
 MyFaces-test, since
  MyFaces-test is a mocking framework and webapp-test is kind of an
  integration testing framework. But we can deal with this question
 later.
 
  Regards,
  Jakob
 
  2010/9/4 Leonardo Uribe lu4...@gmail.com
 
  Hi
 
  No objections for my side, but could you be more explicit about
 what you
  gonna do? Do you want to include it as a separate module for
 myfaces-test
  (note this requires an official vote)? or maybe create a branch on
  myfaces-test so we can enhance it and when it is ready, do some
 alpha/beta
  releases?.
 
  regards,
 
  Leonardo Uribe
 
  2010/9/4 Jakob Korherr jakob.korh...@gmail.com
 
  Hi,
 
  If no objections I'll start the integration today into
  myfaces/test/webapptest.
 
  Regards,
  Jakob
 
  2010/8/23 Jakob Korherr jakob.korh...@gmail.com
 
  Hi,
 
  Since GSoC is over, we can now integrate the code into our
 codebase. The
  code currently lives in a google code project [1].
 
  Because of the fact that this is a test framework, I would
 really like
  to put it into the test folder rather then creating a new
  (myfaces-)top-level entry. However I do not want to integrate it
 into the
  current MyFaces test framework (that currently lives in the
 test folder),
  because this is a completely different thing and IMO we have to
 be able to
  do separate releases of those two.
 
  In addition I would like to create a new project in the JIRA for
 the
  automated webapp tests framework. Something like WEBAPPTEST.
 Suggestions are
  welcome!
 
  What do you think? Any objections, thoughts, ideas?
 
  Thanks for looking into this!
 
  Regards,
  Jakob
 
 
  [1] http://code.google.com/p/gsoc2010-automated-myfaces-tests/
 
  --
  Jakob Korherr
 
  blog: http://www.jakobk.com
  twitter: http://twitter.com/jakobkorherr
  work: http://www.irian.at
 
 
 
  --
  Jakob Korherr
 
  blog: http://www.jakobk.com
  twitter: http://twitter.com/jakobkorherr
  work: http://www.irian.at
 
 
 
 
  --
  Jakob Korherr
 
  blog: http://www.jakobk.com
  twitter: http://twitter.com/jakobkorherr
  work: http://www.irian.at
 



 --
 Jakob Korherr

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









 --
 Jakob Korherr

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



[jira] Resolved: (TRINIDAD-1900) WrappedUploadedFileImpl of CompositeUploadedFileProcessorImpl does not implement Serializable interface

2010-09-08 Thread JIRA

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

Matthias Weßendorf resolved TRINIDAD-1900.
--

Fix Version/s:  1.2.15-core 
   Resolution: Fixed

 WrappedUploadedFileImpl of CompositeUploadedFileProcessorImpl does not 
 implement Serializable interface
 ---

 Key: TRINIDAD-1900
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1900
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Matthias Weßendorf
Assignee: Matthias Weßendorf
Priority: Critical
 Fix For:  1.2.15-core 

 Attachments: SerializableWrapperFileImpl


 In TRINIDAD-1757 we introduce the (internal) WrappedUploadedFileImpl;
 However, it is not serializable

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



[jira] Created: (TRINIDAD-1908) Errors in the tear down of the visiting or encoding context may cover up errors in the processing code

2010-09-08 Thread Andrew Robinson (JIRA)
Errors in the tear down of the visiting or encoding context may cover up errors 
in the processing code
--

 Key: TRINIDAD-1908
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1908
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.0.3-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson


If a component throws and error in the processing, between a setup and tear 
down function, and the tear down throws an exception, the tear down exception 
is the one that is seen since it is thrown from the finally.

UIXComponent should be changed to throw the actual error and not the tear down 
error when this occurs.

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



[jira] Resolved: (TRINIDAD-1908) Errors in the tear down of the visiting or encoding context may cover up errors in the processing code

2010-09-08 Thread Andrew Robinson (JIRA)

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

Andrew Robinson resolved TRINIDAD-1908.
---

Fix Version/s: 2.0.0.3-core
   Resolution: Fixed

 Errors in the tear down of the visiting or encoding context may cover up 
 errors in the processing code
 --

 Key: TRINIDAD-1908
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1908
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.0.3-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
 Fix For: 2.0.0.3-core


 If a component throws and error in the processing, between a setup and tear 
 down function, and the tear down throws an exception, the tear down exception 
 is the one that is seen since it is thrown from the finally.
 UIXComponent should be changed to throw the actual error and not the tear 
 down error when this occurs.

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



[jira] Created: (TRINIDAD-1909) afterEncode should still be called on CoreRenderer even if encodeAll or encodeEnd fails

2010-09-08 Thread Andrew Robinson (JIRA)
afterEncode should still be called on CoreRenderer even if encodeAll or 
encodeEnd fails
---

 Key: TRINIDAD-1909
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1909
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.0.3-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson


If encodeAll or encodeEnd fails in CoreRenderer (exception thrown), the 
afterEncode is never called. This should be in a finally block to allow the 
renderer to properly cleanup even when there is an exception

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



[VOTE] Trinidad core: 1.0.13

2010-09-08 Thread Matthias Wessendorf
Hi,

I was running the needed tasks to get the next release of the Apache
MyFaces Trinidad 1.0.x CORE out. The artifacts are deployed to my private
Apache account ([1]).

Please take a look at the 1.0.13 artifacts and vote.


[ ] +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,
Matthias

[1] http://people.apache.org/~matzew/staging_repo/

-- 
Matthias Wessendorf

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


Re: [VOTE] Trinidad core: 1.0.13

2010-09-08 Thread Matthias Wessendorf
+1

On Wed, Sep 8, 2010 at 10:49 PM, Matthias Wessendorf mat...@apache.org wrote:
 Hi,

 I was running the needed tasks to get the next release of the Apache
 MyFaces Trinidad 1.0.x CORE out. The artifacts are deployed to my private
 Apache account ([1]).

 Please take a look at the 1.0.13 artifacts and vote.

 
 [ ] +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,
 Matthias

 [1] http://people.apache.org/~matzew/staging_repo/

 --
 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] Trinidad core: 1.0.13

2010-09-08 Thread Blake Sullivan

 +1

-- Blake

On 9/8/10 1:56 PM, Matthias Wessendorf wrote:

+1

On Wed, Sep 8, 2010 at 10:49 PM, Matthias Wessendorfmat...@apache.org  wrote:

Hi,

I was running the needed tasks to get the next release of the Apache
MyFaces Trinidad 1.0.x CORE out. The artifacts are deployed to my private
Apache account ([1]).

Please take a look at the 1.0.13 artifacts and vote.


[ ] +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,
Matthias

[1] http://people.apache.org/~matzew/staging_repo/

--
Matthias Wessendorf

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








Re: [VOTE] Trinidad core: 2.0.0 beta1

2010-09-08 Thread Jakob Korherr
Hi,

Sorry, I just read the mail. Thanks for fixing it!

IMO the PseudoFacesContext should do the same as the StartupFacesContextImpl
on MyFaces core, but I am not that familiar with Trinidad, so I actually
don't know what's best in this situation. However we should consider that in
JSF 2.0 there has to be a FacesContext available at every time (request and
server-startup and -shutdown) and thus the JSF impls and also comp-libs or
extensions might use it at some places where it was not possible in JSF 1.2.
TRINIDAD-1902 was caused exactly by this scenario.

However this is something for the next release.

+1 on this one (including Andrew's fix).

Regards,
Jakob

2010/9/7 Matthias Wessendorf mat...@apache.org

 Ah, ok I see. Thanks for pointing it out!

 Jakob, can you take over on your fix for Trinidad-1902 ?

 -Matthias

 On Tue, Sep 7, 2010 at 8:00 PM, Andrew Robinson
 andrew.rw.robin...@gmail.com wrote:
  -0.5
 
  It appears that the fix for TRINIDAD-1902 has some drawbacks that
  cause some severe errors. The PseudoFacesContext.getViewRoot() throws
  an unsupported operation exception when called. It should probably
  just return null instead as that is what is expected when the view has
  not be created/restored yet.
 
  I would say that this should be fixed before a release.
 
  -Andrew
 
 
 
  On Tue, Sep 7, 2010 at 8:39 AM, Matthias Wessendorf mat...@apache.org
 wrote:
  Hi,
 
  I was running the needed tasks to get the first beta release of the
 Apache
  MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private
  Apache account ([1]).
 
  Please take a look at the 2.0.0-beta1 artifacts and vote.
  Main diff between the other alphas is that ajax support has been added.
 
  
  [ ] +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,
  Matthias
 
  [1] 
  http://people.apache.org/~matzew/staging_repo/http://people.apache.org/%7Ematzew/staging_repo/
 
  --
  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




-- 
Jakob Korherr

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


Re: [VOTE] Release Bridge Master 4

2010-09-08 Thread Jakob Korherr
+1

Regards,
Jakob

2010/9/7 Matthias Wessendorf mat...@apache.org

 Scott,

 +1 on the release.

 We had done lazy consensus votes (see [1]) on poms in the past.
 So feel free to vote and move on :-)

 -Matthias

 [1] http://apache.org/foundation/how-it-works.html#management

 On Tue, Sep 7, 2010 at 7:49 PM, Grant Smith work.gr...@gmail.com wrote:
  +1 for the vote
  +1 for only 48 hours
 
  On Tue, Sep 7, 2010 at 10:42 AM, Scott O'Bryan darkar...@gmail.com
 wrote:
 
  Please vote on the proposed release of MyFaces Portlet Bridge Master
  version 4.
 
  This version of the bridge master uses version 9 of the myfaces plugin
 to
  allow artifacts to be published to repository.apache.org as per the
 Apache
  instructions [1].
 
  The bridge master artifacts have been staged to the Nexus repository at
  [2].
 
  Please note:  This is a minor change so we're proposing the vote is open
  for 48 hours rather than the usual 72.
 
  
  [ ] +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..
 
  [1]: http://www.apache.org/dev/publishing-maven-artifacts.html
  [2]:
 
 https://repository.apache.org/content/repositories/orgapachemyfaces-035/
 
 
 
  --
  Grant Smith - V.P. Information Technology
  Marathon Computer Systems, LLC.
 
 



 --
 Matthias Wessendorf

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




-- 
Jakob Korherr

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


Re: [VOTE] Trinidad plugins: 2.0.2 release

2010-09-08 Thread Jakob Korherr
+1

Regards,
Jakob

2010/9/7 Grant Smith work.gr...@gmail.com

 +1


 On Tue, Sep 7, 2010 at 9:18 AM, Blake Sullivan 
 blake.sulli...@oracle.comwrote:

  +1

 -- Blake Sullivan


 On 9/7/10 12:23 AM, Matthias Wessendorf wrote:

 Hi,

 I was running the needed tasks to get the 2.0.2 release of the Apache
 MyFaces Trinidad Maven 2 Plugins. This contains more JSF 2.0
 support for the MyFaces Trinidad Maven plugins.

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

 Please take a look at the 2.0.2 artifacts and vote.

 How to test those JARs ?

 Use the stage repo inside your pom.xml file:
 ...
 pluginRepositories
 pluginRepository
 idapache.stage/id
 nameApache Stage Repository/name
 urlhttp://people.apache.org/~matzew/staging_repo/http://people.apache.org/%7Ematzew/staging_repo/
 /url
 layoutdefault/layout
 /pluginRepository
 /pluginRepositories
 ...

 
 [ ] +1 for community members who have reviewed and tested the bits
 [ ] +0
 [ ] -1 for fatal flaws that should cause these bits not to be released,
 and why..
 

 Thanks,
 Matthias

 [1] 
 http://people.apache.org/~matzew/staging_repo/http://people.apache.org/%7Ematzew/staging_repo/







 --
 Grant Smith - V.P. Information Technology
 Marathon Computer Systems, LLC.




-- 
Jakob Korherr

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


[jira] Commented: (MYFACES-2911) OSGi Manifest: MyFaces API Bundle requires IMPL Bundle

2010-09-08 Thread Jakob Korherr (JIRA)

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

Jakob Korherr commented on MYFACES-2911:


But you can use the API without the IMPL, for example in a JUnit test.

 OSGi Manifest: MyFaces API Bundle requires IMPL Bundle
 --

 Key: MYFACES-2911
 URL: https://issues.apache.org/jira/browse/MYFACES-2911
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
 Environment: OSGi container
Reporter: Frank Mittag
Priority: Minor

 The MANIFEST.MF file of the org.apache.myfaces.core.api bundle/jar contains 
 the entry:
 Require-Bundle: org.apache.myfaces.core.impl;bundle-version=2.0.1 
 So the API bundle requires the IMPL bundle to work. This is not needed and 
 prevents scenarios where the e.g. two IMPL bundles just reference the same 
 API bundle.
 The easiest solution is just to remove the entry.
 Frank

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



[jira] Resolved: (MYFACES-2912) Wrong JNDI Name for Method Resource Injections

2010-09-08 Thread Jakob Korherr (JIRA)

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

Jakob Korherr resolved MYFACES-2912.


Fix Version/s: 1.2.10-SNAPSHOT
   2.0.2-SNAPSHOT
   Resolution: Fixed

 Wrong JNDI Name for Method Resource Injections
 --

 Key: MYFACES-2912
 URL: https://issues.apache.org/jira/browse/MYFACES-2912
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-252, JSR-314
Affects Versions: 1.2.9, 2.0.1
Reporter: Gurkan Erdogdu
Assignee: Jakob Korherr
 Fix For: 1.2.10-SNAPSHOT, 2.0.2-SNAPSHOT

 Attachments: patch.txt


 Method based JNDI env. injections not worked correctly. Patch is attached. See
 Java EE 6 specification section, EE. 5.2.5 Annotations and Injections. Patch 
 is
 provided that solves problem.

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



[jira] Created: (MYFACESTEST-25) Refactor POMs

2010-09-08 Thread Jakob Korherr (JIRA)
Refactor POMs
-

 Key: MYFACESTEST-25
 URL: https://issues.apache.org/jira/browse/MYFACESTEST-25
 Project: MyFaces Test
  Issue Type: Task
  Components: webapptest
Reporter: Jakob Korherr
Assignee: Jakob Korherr


We need to do some refactoring in the webapptest-POMs, like e.g. update to 
MyFaces master pom v9.

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



[jira] Commented: (MYFACESTEST-25) Refactor POMs

2010-09-08 Thread Jakob Korherr (JIRA)

[ 
https://issues.apache.org/jira/browse/MYFACESTEST-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12907473#action_12907473
 ] 

Jakob Korherr commented on MYFACESTEST-25:
--

Furthermore we need to add some license headers.

 Refactor POMs
 -

 Key: MYFACESTEST-25
 URL: https://issues.apache.org/jira/browse/MYFACESTEST-25
 Project: MyFaces Test
  Issue Type: Task
  Components: webapptest
Reporter: Jakob Korherr
Assignee: Jakob Korherr

 We need to do some refactoring in the webapptest-POMs, like e.g. update to 
 MyFaces master pom v9.

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



[jira] Resolved: (MYFACESTEST-25) Refactor POMs

2010-09-08 Thread Jakob Korherr (JIRA)

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

Jakob Korherr resolved MYFACESTEST-25.
--

Resolution: Fixed

updated to Arquillian alpha 4 and to myfaces master pom 9, added various 
sections in the parent pom, added some dependencies to the dependencyManagement 
section and added license headers to all poms.

 Refactor POMs
 -

 Key: MYFACESTEST-25
 URL: https://issues.apache.org/jira/browse/MYFACESTEST-25
 Project: MyFaces Test
  Issue Type: Task
  Components: webapptest
Reporter: Jakob Korherr
Assignee: Jakob Korherr

 We need to do some refactoring in the webapptest-POMs, like e.g. update to 
 MyFaces master pom v9.

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



Re: [VOTE] Release Bridge Master 4

2010-09-08 Thread Michael Freedman

+1

On 9/7/2010 10:42 AM, Scott O'Bryan wrote:
Please vote on the proposed release of MyFaces Portlet Bridge Master 
version 4.


This version of the bridge master uses version 9 of the myfaces plugin 
to allow artifacts to be published to repository.apache.org as per the 
Apache instructions [1].


The bridge master artifacts have been staged to the Nexus repository 
at [2].


Please note:  This is a minor change so we're proposing the vote is 
open for 48 hours rather than the usual 72.



[ ] +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..

[1]: http://www.apache.org/dev/publishing-maven-artifacts.html
[2]: 
https://repository.apache.org/content/repositories/orgapachemyfaces-035/


[jira] Commented: (TOMAHAWK-1548) Allow t:dataScroller to be Ajaxified using f:ajax

2010-09-08 Thread Leonardo Uribe (JIRA)

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

Leonardo Uribe commented on TOMAHAWK-1548:
--

Yes, I think it is worth to dedicate some time to enhance compatibility of 
tomahawk with ajax, and doing this we can find bugs on myfaces core as well.

 Allow t:dataScroller to be Ajaxified using f:ajax
 -

 Key: TOMAHAWK-1548
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1548
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: Data Scroller
Affects Versions: 1.1.9
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Fix For: 1.1.10-SNAPSHOT


 After thinking a lot about it, to make it possible we need to do some things:
 - If no facet or paginator is rendered, render a div and the id, so when 
 ajax occur it could be replaced.
 - If a facet or paginator is rendered, if an id is set render it.
 - Add click, dblclick and action client events and copy them for all 
 facets and paginator links.
 - Add action as default event name.
 In this way, we can add f:ajax tag inside t:dataScroller to tell when a link 
 is click, which elements should be updated (usually the related dataTable).

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