from:"Matthias Wessendorf"

As there are some limitations (see TRINIDAD-1603) and picking an ugly one, like

faces-config

 name
   org_apache_myfaces_trinidad
 /name
...

/faces-config

doesn't make much sense, what do folks think about picking a
simplified version ?

faces-config
 name
   trinidad
 /name
...
/faces-config

There shouldn't be much issues with trinidad as the (kinda) unique name...

Thoughts ?

-Matthias


On Tue, Oct 20, 2009 at 7:04 PM, Andy Schwartz
andy.g.schwa...@gmail.com wrote:
 Hey Matthias -

 I like org.apache.myfaces.trinidad.

 Just out of curiosity I sent email to the EG to see what other folks
 have done.  I don't think we need to wait for that info, but I will
 pass along any responses.

 Andy




-- 
Matthias Wessendorf

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

[COMMUNITY] MyFaces += Mamallan Uthaman

The Myfaces PMC is proud to announce a new addition to our community.

Please welcome Mamallan Uthaman as the newest MyFaces committer!
Mamallan is an active member of the myfaces community, especially in
the trinidad mobile renderkit section of the code.

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

-Matthias

-- 
Matthias Wessendorf

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

[COMMUNITY] MyFaces += Mamallan Uthaman

The Myfaces PMC is proud to announce a new addition to our community.

Please welcome Mamallan Uthaman as the newest MyFaces committer!
Mamallan is an active member of the myfaces community, especially in
the trinidad mobile renderkit section of the code.

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

-Matthias

-- 
Matthias Wessendorf

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

Re: [PROPOSAL][VOTE] Subversion

 is at
     http://buildbot.subversion.org/buildbot/

  Note that we request these resources to be at their final locations,
 not an intermediary while going through incubation.  The cost of
 switching twice would otherwise be significant due to the size of the
 existing community.

  The Subversion team members are happy to work with and assist the ASF
 Infrastructure team to enable early deployments of its release candidates if
 possible.

 Initial Committers

  The list of initial committers is at
 http://svn.collab.net/repos/svn/trunk/COMMITTERS.

 The initial PMC members are those listed as full committers in that
 file (lines 1-74).

 Sponsors
  * Champion: Greg Stein
  * Nominated Mentors: Justin Erenkrantz, Greg Stein, Sander Striker, Daniel 
 Rall
  * Sponsor:

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org





-- 
Matthias Wessendorf

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

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: JSF 2.0 - Bean Validation, Unified EL and other specs

On Tue, Nov 3, 2009 at 4:24 PM, Ed Burns ed.bu...@sun.com wrote:
 On Tue, 27 Oct 2009 18:06:04 -0700, Matthias Wessendorf 
 mat...@apache.org said:

 MW Hi Jan-Kees,
 MW thanks for creating this ticket. I'd like to see something like this.
 MW Sounds (to me) very useful...

 Note that there is a precedent for doing this kind of discovery without
 requiring a Java language signature: the way properties are conveyed to
 the standard XML parsers in Java.  I would rather avoid introducing a
 signature for this because it needs to be very fluid over time.

fair enough, so let's keep it to be part of the implementation.
In myfaces we have several non public classes, big issue here
(in this particular) case is that we actually have to duplicate the
code. Oh well :-)

-M


 Ed

 --
 | ed.bu...@sun.com  | office: 408 884 9519 OR x31640
 | homepage:         | http://ridingthecrest.com/

 -
 To unsubscribe, e-mail: dev-unsubscr...@javaserverfaces.dev.java.net
 For additional commands, e-mail: dev-h...@javaserverfaces.dev.java.net





-- 
Matthias Wessendorf

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

Re: Trinidad file upload

are you sure that you have everything configured correct ?

Trinidad and tomahawk ?

I think i remember some issues on the upload case, when mixing them
(trinidad and
tomahawk). Perhaps searching the archives gives any hint ? I really
don't remember it

-Matthias

On Tue, Nov 3, 2009 at 7:48 PM, veena pandit v.kri...@gmail.com wrote:
 Well, I have both Tomahawk and trinidad in the same application for file
 uploads.
 I added commons.io to the web-inf/lib directory and now I dont get any error
 messages in the log.  I just get the popup error message once again.  I am
 using trinidad for another control in the same page.  But I was also trying
 to use trinidad for the upload as well.

 Thanks,

 Veena

 On Tue, Nov 3, 2009 at 1:45 PM, Matthias Wessendorf mat...@apache.orgwrote:

 This is not Trinidad, this is Tomahawk.

 The NoClassDefFoundError says that you don't
 have the ServletFileUpload from the given package
 in your classpath. This class is part of the Apache Commons
 Upload project, which is required by Tomahawk.

 -Matthias

 On Tue, Nov 3, 2009 at 7:38 PM, veena pandit v.kri...@gmail.com wrote:
  A new development.  Now I am getting this error in the log:
  All I was getting before this is a popup error message.
  Now here is the stacktrace:
 
 
  SEVERE: Servlet.service() for servlet Faces Servlet threw exception
 
  java.lang.NoClassDefFoundError:
  org/apache/commons/fileupload/servlet/ServletFileUpload
 
  at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(*
  ExtensionsFilter.java:321*)
 
  *Thanks,*
  **
  *Veena*
 
 
 
  On Tue, Nov 3, 2009 at 1:33 PM, Matthias Wessendorf mat...@apache.org
 wrote:
 
  do you have a little bit more information ?
 
  cfg, size of the file. error message, stack trace...
 
  -Matthias
 
  On Tue, Nov 3, 2009 at 7:26 PM, veena pandit v.kri...@gmail.com
 wrote:
   Hi,
  
   I am having trouble making this work.  I have configured the web.xml,
   faces-config.xml
   and followed the instructions on the following page:
  
   http://myfaces.apache.org/trinidad/devguide/fileUpload.html.
  
   I get a following popup error:
   Message from webpage:
   A file upload error has occured, please verify your upload data and
 file
   name.
  
   Thanks,
  
   Veena
  
 
 
 
  --
  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: Trinidad file upload

do you have a little bit more information ?

cfg, size of the file. error message, stack trace...

-Matthias

On Tue, Nov 3, 2009 at 7:26 PM, veena pandit v.kri...@gmail.com wrote:
 Hi,

 I am having trouble making this work.  I have configured the web.xml,
 faces-config.xml
 and followed the instructions on the following page:

 http://myfaces.apache.org/trinidad/devguide/fileUpload.html.

 I get a following popup error:
 Message from webpage:
 A file upload error has occured, please verify your upload data and file
 name.

 Thanks,

 Veena




-- 
Matthias Wessendorf

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

Re: Trinidad file upload


Do you have the Resource servlet? Are you having tr:document ?

Sent from my iPod.

On 03.11.2009, at 21:51, veena pandit v.kri...@gmail.com wrote:


Martin,

Hi,  I tried a small demo app and I followed your instructions;  I  
get the

following errors:

_submitFormCheck is not defined
http://localhost:8080/TrUpload/mypage.jsp line 34

_checkLoad is not defined
http://localhost:8080/TrUpload/mypage.jsp line 1

_submitForm is not defined
http://localhost:8080/TrUpload/mypage.jsp line 1.

What am I doing wrong?

Thanks,

Veena

On Tue, Nov 3, 2009 at 4:03 PM, Martin Kočí martin.k...@aura.cz wr 
ote:


It seems that message A file upload error has occurred, please  
verify
your upload data and file name occures on client and has nothing  
to do

with server configuration. Can you please try  a simple example:

tr:form usesUpload=true
tr:inputFile value=#{yourBean.uploadFile} /
/tr:form

if it works - if not please look in Firefox at Tools - Error
Console if there is any error.


veena pandit píše v Út 03. 11. 2009 v 14:56 -0500:

Hi Martin,

I checked my web.xml and the ordering is already the way you state  
it

should

be. Anything else I can check for?

Thanks,

Veena

On Tue, Nov 3, 2009 at 3:24 PM, Martin Kočí martin.k...@aura.cz 
 wrote:



Hi,

it is a known limitation, it depends on filters ordering in  
web.xml.

.
Look in your web.xml and put something like:

filter-mapping
  filter-nametrinidad/filter-name
  servlet-namefaces/servlet-name
/filter-mapping

before

filter-mapping
  filter-nameMyFacesExtensionsFilter/filter-name
  servlet-namefaces/servlet-name
/filter-mapping

Filter declared first will consume file upload.


Regards,

Martin




veena pandit píše v Út 03. 11. 2009 v 14:00 -0500:

I configured it according to the trinidad web page.
http://myfaces.apache.org/trinidad/devguide/fileUpload.html

Trinidad and Tomahawk are working well together.  I am using  
Trinidad

for

a

drop down and Tomahawk for file upload from BalusC's blog.  But I

just

added

the Trinidad File upload functionality to the web application and

that is

the only thing that is not working.  I just thought I would use

Trinidad

for

both so I could have a common look and feel since this application

will

go

into production eventually.

I could not find anything else specific to any problems with  
Trinidad

file

upload.

Thanks.

Veena

On Tue, Nov 3, 2009 at 1:51 PM, Matthias Wessendorf 

mat...@apache.org

wrote:


are you sure that you have everything configured correct ?

Trinidad and tomahawk ?

I think i remember some issues on the upload case, when mixing  
them

(trinidad and
tomahawk). Perhaps searching the archives gives any hint ? I  
really

don't remember it

-Matthias

On Tue, Nov 3, 2009 at 7:48 PM, veena pandit v.kri...@gmail.com

wrote:

Well, I have both Tomahawk and trinidad in the same application

for

file

uploads.
I added commons.io to the web-inf/lib directory and now I dont

get

any

error

messages in the log.  I just get the popup error message once

again.

I

am

using trinidad for another control in the same page.  But I was

also

trying

to use trinidad for the upload as well.

Thanks,

Veena

On Tue, Nov 3, 2009 at 1:45 PM, Matthias Wessendorf 

mat...@apache.org

wrote:


This is not Trinidad, this is Tomahawk.

The NoClassDefFoundError says that you don't
have the ServletFileUpload from the given package
in your classpath. This class is part of the Apache Commons
Upload project, which is required by Tomahawk.

-Matthias

On Tue, Nov 3, 2009 at 7:38 PM, veena pandit 

v.kri...@gmail.com

wrote:

A new development.  Now I am getting this error in the log:
All I was getting before this is a popup error message.
Now here is the stacktrace:


SEVERE: Servlet.service() for servlet Faces Servlet threw

exception


java.lang.NoClassDefFoundError:
org/apache/commons/fileupload/servlet/ServletFileUpload

at

org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(*

ExtensionsFilter.java:321*)

*Thanks,*
**
*Veena*



On Tue, Nov 3, 2009 at 1:33 PM, Matthias Wessendorf 

mat...@apache.org

wrote:


do you have a little bit more information ?

cfg, size of the file. error message, stack trace...

-Matthias

On Tue, Nov 3, 2009 at 7:26 PM, veena pandit 

v.kri...@gmail.com



wrote:

Hi,

I am having trouble making this work.  I have configured

the

web.xml,

faces-config.xml
and followed the instructions on the following page:



http://myfaces.apache.org/trinidad/devguide/fileUpload.html.


I get a following popup error:
Message from webpage:
A file upload error has occured, please verify your upload

data

and

file

name.

Thanks,

Veena





--
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: Trinidad file upload


Again, add the required jar...

Sent from my iPod.

On 03.11.2009, at 21:39, veena pandit v.kri...@gmail.com wrote:


When I run it outside of eclipse and in my Firefox I get the following
message(this is intermittant):


java.lang.NoClassDefFoundError:
org/apache/commons/fileupload/servlet/ServletFileUpload
   org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter 
(ExtensionsFilter.java:321)


**
Remember I have Tomahawk upload in the same page.

Thanks,

Veena

On Tue, Nov 3, 2009 at 4:03 PM, Martin Kočí martin.k...@aura.cz wr 
ote:


It seems that message A file upload error has occurred, please  
verify
your upload data and file name occures on client and has nothing  
to do

with server configuration. Can you please try  a simple example:

tr:form usesUpload=true
tr:inputFile value=#{yourBean.uploadFile} /
/tr:form

if it works - if not please look in Firefox at Tools - Error
Console if there is any error.


veena pandit píše v Út 03. 11. 2009 v 14:56 -0500:

Hi Martin,

I checked my web.xml and the ordering is already the way you state  
it

should

be. Anything else I can check for?

Thanks,

Veena

On Tue, Nov 3, 2009 at 3:24 PM, Martin Kočí martin.k...@aura.cz 
 wrote:



Hi,

it is a known limitation, it depends on filters ordering in  
web.xml.

.
Look in your web.xml and put something like:

filter-mapping
  filter-nametrinidad/filter-name
  servlet-namefaces/servlet-name
/filter-mapping

before

filter-mapping
  filter-nameMyFacesExtensionsFilter/filter-name
  servlet-namefaces/servlet-name
/filter-mapping

Filter declared first will consume file upload.


Regards,

Martin




veena pandit píše v Út 03. 11. 2009 v 14:00 -0500:

I configured it according to the trinidad web page.
http://myfaces.apache.org/trinidad/devguide/fileUpload.html

Trinidad and Tomahawk are working well together.  I am using  
Trinidad

for

a

drop down and Tomahawk for file upload from BalusC's blog.  But I

just

added

the Trinidad File upload functionality to the web application and

that is

the only thing that is not working.  I just thought I would use

Trinidad

for

both so I could have a common look and feel since this application

will

go

into production eventually.

I could not find anything else specific to any problems with  
Trinidad

file

upload.

Thanks.

Veena

On Tue, Nov 3, 2009 at 1:51 PM, Matthias Wessendorf 

mat...@apache.org

wrote:


are you sure that you have everything configured correct ?

Trinidad and tomahawk ?

I think i remember some issues on the upload case, when mixing  
them

(trinidad and
tomahawk). Perhaps searching the archives gives any hint ? I  
really

don't remember it

-Matthias

On Tue, Nov 3, 2009 at 7:48 PM, veena pandit v.kri...@gmail.com

wrote:

Well, I have both Tomahawk and trinidad in the same application

for

file

uploads.
I added commons.io to the web-inf/lib directory and now I dont

get

any

error

messages in the log.  I just get the popup error message once

again.

I

am

using trinidad for another control in the same page.  But I was

also

trying

to use trinidad for the upload as well.

Thanks,

Veena

On Tue, Nov 3, 2009 at 1:45 PM, Matthias Wessendorf 

mat...@apache.org

wrote:


This is not Trinidad, this is Tomahawk.

The NoClassDefFoundError says that you don't
have the ServletFileUpload from the given package
in your classpath. This class is part of the Apache Commons
Upload project, which is required by Tomahawk.

-Matthias

On Tue, Nov 3, 2009 at 7:38 PM, veena pandit 

v.kri...@gmail.com

wrote:

A new development.  Now I am getting this error in the log:
All I was getting before this is a popup error message.
Now here is the stacktrace:


SEVERE: Servlet.service() for servlet Faces Servlet threw

exception


java.lang.NoClassDefFoundError:
org/apache/commons/fileupload/servlet/ServletFileUpload

at

org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(*

ExtensionsFilter.java:321*)

*Thanks,*
**
*Veena*



On Tue, Nov 3, 2009 at 1:33 PM, Matthias Wessendorf 

mat...@apache.org

wrote:


do you have a little bit more information ?

cfg, size of the file. error message, stack trace...

-Matthias

On Tue, Nov 3, 2009 at 7:26 PM, veena pandit 

v.kri...@gmail.com



wrote:

Hi,

I am having trouble making this work.  I have configured

the

web.xml,

faces-config.xml
and followed the instructions on the following page:



http://myfaces.apache.org/trinidad/devguide/fileUpload.html.


I get a following popup error:
Message from webpage:
A file upload error has occured, please verify your upload

data

and

file

name.

Thanks,

Veena





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

Re: Trinidad file upload

This is not Trinidad, this is Tomahawk.

The NoClassDefFoundError says that you don't
have the ServletFileUpload from the given package
in your classpath. This class is part of the Apache Commons
Upload project, which is required by Tomahawk.

-Matthias

On Tue, Nov 3, 2009 at 7:38 PM, veena pandit v.kri...@gmail.com wrote:
 A new development.  Now I am getting this error in the log:
 All I was getting before this is a popup error message.
 Now here is the stacktrace:


 SEVERE: Servlet.service() for servlet Faces Servlet threw exception

 java.lang.NoClassDefFoundError:
 org/apache/commons/fileupload/servlet/ServletFileUpload

 at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(*
 ExtensionsFilter.java:321*)

 *Thanks,*
 **
 *Veena*



 On Tue, Nov 3, 2009 at 1:33 PM, Matthias Wessendorf mat...@apache.orgwrote:

 do you have a little bit more information ?

 cfg, size of the file. error message, stack trace...

 -Matthias

 On Tue, Nov 3, 2009 at 7:26 PM, veena pandit v.kri...@gmail.com wrote:
  Hi,
 
  I am having trouble making this work.  I have configured the web.xml,
  faces-config.xml
  and followed the instructions on the following page:
 
  http://myfaces.apache.org/trinidad/devguide/fileUpload.html.
 
  I get a following popup error:
  Message from webpage:
  A file upload error has occured, please verify your upload data and file
  name.
 
  Thanks,
 
  Veena
 



 --
 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: Trinidad file upload

On Wed, Nov 4, 2009 at 12:28 AM, veena pandit v.kri...@gmail.com wrote:
 I do not have a resource servlet.  But the tomahawk demo works without a
 resource servlet.  I did have tr:document.  I removed it to see if it would
 fix the error but it did not.

if you would read the Trinidad doc, it says that the Resource Servlet
is responsible
to send down CSS/JS resources for Trinidad. Tomahawk has _nothing_ to do with
that...

Tomahawk just needs the Commons Upload JAR...


 Thanks,

 Veena

 On Tue, Nov 3, 2009 at 4:07 PM, Matthias Wessendorf
 mwessend...@gmail.comwrote:

 Do you have the Resource servlet? Are you having tr:document ?

 Sent from my iPod.


 On 03.11.2009, at 21:51, veena pandit v.kri...@gmail.com wrote:

 Martin,

 Hi,  I tried a small demo app and I followed your instructions;  I get the
 following errors:

 _submitFormCheck is not defined
 http://localhost:8080/TrUpload/mypage.jsp line 34

 _checkLoad is not defined
 http://localhost:8080/TrUpload/mypage.jsp line 1

 _submitForm is not defined
 http://localhost:8080/TrUpload/mypage.jsp line 1.

 What am I doing wrong?

 Thanks,

 Veena

 On Tue, Nov 3, 2009 at 4:03 PM, Martin Kočí martin.k...@aura.cz wrote:

 It seems that message A file upload error has occurred, please verify
 your upload data and file name occures on client and has nothing to do
 with server configuration. Can you please try  a simple example:

 tr:form usesUpload=true
 tr:inputFile value=#{yourBean.uploadFile} /
 /tr:form

 if it works - if not please look in Firefox at Tools - Error
 Console if there is any error.


 veena pandit píše v Út 03. 11. 2009 v 14:56 -0500:

 Hi Martin,

 I checked my web.xml and the ordering is already the way you state it

 should

 be. Anything else I can check for?

 Thanks,

 Veena

 On Tue, Nov 3, 2009 at 3:24 PM, Martin Kočí martin.k...@aura.cz
 wrote:

 Hi,

 it is a known limitation, it depends on filters ordering in web.xml.
 .
 Look in your web.xml and put something like:

 filter-mapping
  filter-nametrinidad/filter-name
  servlet-namefaces/servlet-name
 /filter-mapping

 before

 filter-mapping
  filter-nameMyFacesExtensionsFilter/filter-name
  servlet-namefaces/servlet-name
 /filter-mapping

 Filter declared first will consume file upload.


 Regards,

 Martin




 veena pandit píše v Út 03. 11. 2009 v 14:00 -0500:

 I configured it according to the trinidad web page.
 http://myfaces.apache.org/trinidad/devguide/fileUpload.html

 Trinidad and Tomahawk are working well together.  I am using Trinidad

 for

 a

 drop down and Tomahawk for file upload from BalusC's blog.  But I

 just

 added

 the Trinidad File upload functionality to the web application and

 that is

  the only thing that is not working.  I just thought I would use

 Trinidad

 for

 both so I could have a common look and feel since this application

 will

 go

 into production eventually.

 I could not find anything else specific to any problems with Trinidad

 file

 upload.

 Thanks.

 Veena

 On Tue, Nov 3, 2009 at 1:51 PM, Matthias Wessendorf 

 mat...@apache.org

  wrote:

 are you sure that you have everything configured correct ?

 Trinidad and tomahawk ?

 I think i remember some issues on the upload case, when mixing them
 (trinidad and
 tomahawk). Perhaps searching the archives gives any hint ? I really
 don't remember it

 -Matthias

 On Tue, Nov 3, 2009 at 7:48 PM, veena pandit v.kri...@gmail.com

 wrote:

  Well, I have both Tomahawk and trinidad in the same application

 for

 file

  uploads.
 I added commons.io to the web-inf/lib directory and now I dont

 get

 any

 error

 messages in the log.  I just get the popup error message once

 again.

 I

 am

 using trinidad for another control in the same page.  But I was

 also

  trying

 to use trinidad for the upload as well.

 Thanks,

 Veena

 On Tue, Nov 3, 2009 at 1:45 PM, Matthias Wessendorf 

 mat...@apache.org

  wrote:

 This is not Trinidad, this is Tomahawk.

 The NoClassDefFoundError says that you don't
 have the ServletFileUpload from the given package
 in your classpath. This class is part of the Apache Commons
 Upload project, which is required by Tomahawk.

 -Matthias

 On Tue, Nov 3, 2009 at 7:38 PM, veena pandit 

 v.kri...@gmail.com

  wrote:

  A new development.  Now I am getting this error in the log:
 All I was getting before this is a popup error message.
 Now here is the stacktrace:


 SEVERE: Servlet.service() for servlet Faces Servlet threw

 exception


 java.lang.NoClassDefFoundError:
 org/apache/commons/fileupload/servlet/ServletFileUpload

 at

 org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(*

    ExtensionsFilter.java:321*)

 *Thanks,*
 **
 *Veena*



 On Tue, Nov 3, 2009 at 1:33 PM, Matthias Wessendorf 

 mat...@apache.org

  wrote:

 do you have a little bit more information ?

 cfg, size of the file. error message, stack trace...

 -Matthias

 On Tue, Nov 3, 2009 at 7:26 PM, veena pandit 

 v.kri...@gmail.com


  wrote:

  Hi,

 I am having

Re: [PATCH] component-comp interceptor stack copy

Eric,

the right way to provide a patch is by using the JIRA issue tracker.
Doing so makes sure they aren't forgotten.

Can you please upload your patch ?

Thx,
Matthias

On Tue, Oct 27, 2009 at 1:16 PM, Eric Covener cove...@apache.org wrote:
 Typo in WebBeansUtil::createNewBean() copying interceptor stack from
 bean class to managed bean -- see attachment.

 Contributed By: Joe Bergmark, Eric Covener

 --
 Eric Covener
 cove...@gmail.com




-- 
Matthias Wessendorf

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

Re: [MyFaces 2.0] / [JSF 2.0] SPEC not too clear on setParent() description = MYFACES-2389 review request

On Mon, Oct 26, 2009 at 8:48 PM, Martin Marinschek
mmarinsc...@apache.org wrote:
 Hi Matthias,

 that has not been discussed on the EG, so I can't confirm your version
 of the code. However, it seems reasonable to me.

OK, yeah, I just did refactoring :-) not added anything (wild). thanks for the
review.

 As I see from the
 issue tracker, Ed already responded (he's been faster there than with
 other MyFaces team issues recently ;), so I guess there is no need for
 speeding him up.

I know :-) thanks for the pointer!

-Matthias



 regards,

 Martin

 On 10/27/09, Matthias Wessendorf mat...@apache.org wrote:
 Hi,

 some of the hidden secrets of the new spec have been forgotten to be
 spec'd out :-(

 While checking on MyFaces's setParent() implementation, I decided to
 do a little clean up.

 Please see the patch here:
 https://issues.apache.org/jira/browse/MYFACES-2389

 Generally I am wondering about the previous implementation as nothing
 like that has been mentioned in the spec at all.
 Can the MyFaces EG members confirm that this version is correct ?

 Would be also good if they were able to speed up on this ticket as well:
 https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1384

 Greetings,
 Matthias

 --
 Matthias Wessendorf

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



 --

 http://www.irian.at

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

 Professional Support for Apache MyFaces




-- 
Matthias Wessendorf

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

Re: [Trinidad 2.0] Relocatable Resources - API proposal

I created two tickets:
Renderer modification = https://issues.apache.org/jira/browse/TRINIDAD-1610
Event part (setParent() behavior) =
https://issues.apache.org/jira/browse/TRINIDAD-1611

-Matthias

On Mon, Oct 26, 2009 at 3:51 PM, Matthias Wessendorf mat...@apache.org wrote:
 oh, yeah... of course this can only work when we change our
 UIXComponentBase's setParent() to trigger the new PostAddToViewEvent
 event.

 A simple implementation of the setParent() is available here:
 http://svn.apache.org/repos/asf/myfaces/core/trunk/api/src/main/java/javax/faces/component/UIComponentBase.java
 (No, due to licensing issues, I am not looking at the RI code...)

 As this event subsystem doesn't come for free (in terms of PERF
 costs), I will try to get some numbers on the inclusion of the
 behavior.
 However, the benefit of the relocatable resources feature is that we
 don't need to worry about duplicated resources, as something like
 this:
 ...
  h:outputScript target=body name=fooBody.js/
  h:outputScript target=body name=fooBody.js/
  h:outputScript target=body name=fooBody.js/
 ...

 Is only added once to the particular *target*...

 Greetings,
 Matthias

 On Mon, Oct 26, 2009 at 3:45 PM, Matthias Wessendorf mat...@apache.org 
 wrote:
 Hi,

 in order to avoid dependency to h:head/body/form BUT be able to
 support the Relocatable Resources feature, we should change our
 renderers for head, body and form to check
 for any component resource(s) that has been targeted to one of these guys.

 This would mean that something like this just works:
 tr:document
  xmlns=http://www.w3.org/1999/xhtml;
  xmlns:f=http://java.sun.com/jsf/core;
  xmlns:h=http://java.sun.com/jsf/html;
  xmlns:tr=http://myfaces.apache.org/trinidad;
  title=TESTER of Scripts

    h:outputScript target=body name=myCoolBody.js/
    h:outputScript target=head name=anAwesomeHead.js/

 /tr:document
 == no need to add the nasty h:head/body.

 The call inside of the renderer should be fairly simple:
 ...
    for(UIComponent comp :
 context.getViewRoot().getComponentResources(context, head))
    {
      comp.encodeAll(context);
    }
 ...
 Note: We need to render out these resources pretty much BEFORE we end
 the particular HTML element (e.g.  head, body or form)...

 In order to avoid duplicated code, I think we want to add a utility
 which should be called from particular renderers, like on
 CoreRenderer.java (part of the Trinidad API). This would allow
 extensions to easily use this new API as well...

 suggested change to CoreRenderer.java =
  /**
   * Hook for rendering the component resources for the codetarget/code.
   * @param context Current codeFacesContext/code object for this request.
   * @param target The target for the resources (e.g. head/body/form)
   *
   * @throws IOException
   */
  protected final void encodeComponentResources(
    FacesContext context,
    String       target) throws IOException
  {
    if(target != null)
    {
      UIViewRoot viewRoot = context.getViewRoot();
      for(UIComponent componentResource :
 viewRoot.getComponentResources(context, target))
      {
        componentResource.encodeAll(context);
      }
    }
  }

 As a matter of fact the HeadRenderer's encodeEnd() method would simply
 look like:

  protected void encodeEnd(
    FacesContext        context,
    RenderingContext arc,
    UIComponent         comp,
    FacesBean           bean) throws IOException
  {
    ResponseWriter rw = context.getResponseWriter();

    // trigger the rendering of targeted resource
    // for the HEAD, on UIViewRoot - if there are
    // any...
    encodeComponentResources(context, head);

    rw.endElement(head);
  }

 -Matthias

 --
 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: [Trinidad 2.0] Lifecycle Management Methods (3.1.14)

I created a ticket for this:

https://issues.apache.org/jira/browse/TRINIDAD-1612

and I also created a subtask to put the new event handling
system into the lifecycle methods;

=
https://issues.apache.org/jira/browse/TRINIDAD-1614

On Tue, Oct 27, 2009 at 1:27 PM, Matthias Wessendorf mat...@apache.org wrote:
 Hi,

 the spec defines two new lifecycle methods for JSF 2.0:
 protected void pushComponentToEL(FacesContext context);
 protected void popComponentFromEL(FacesContext context)

 These are the base contract from the new implicit #{component} EL.

 The spec wants an implementation to call these new methods inside of
 the lifecycle
 (processXYZ and encodeBegin). It also says that is should be called
 inside the new visitTree()
 method.

 See [1] for the entire JavaDoc for the class.

 As we - currently - have our own Visitor implementation, I am focusing
 here on the usage of the
 pushComponentToEL/popComponentFromEL to be called (for now) only on
 those lifecylce methods:
 -encodeBegin()
 -processDecodes()
 -processRestoreState()
 -processSaveState()
 -processUpdates()
 -processValidators()

 Regarding the Tree/Visitor implementation, I will follow up on this in
 a separate thread, once I
 managed to write down the diffs between our (Trinidad) impl and the
 one from the spec.

 So, as for now I am proposing that we should integrate the
 pushComponentToEL/popComponentFromEL
 hooks for the mentioned methods.

 If this is really cause very bad performance results, we can
 reevaluate the situation later on, again.

 Any thoughts ?


 [1] 
 http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/javax/faces/component/UIComponent.html

 --
 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: [Trinidad 2.0] Lifecycle Management Methods (3.1.14)

There is a patch attached to TRINIDAD-1614.
This contains both fixes for TRINIDAD-1614 and TRINIDAD-1612

(as TRINIDAD-1614 is just a sub-task)

-Matthias

On Tue, Oct 27, 2009 at 2:00 PM, Matthias Wessendorf mat...@apache.org wrote:
 I created a ticket for this:

 https://issues.apache.org/jira/browse/TRINIDAD-1612

 and I also created a subtask to put the new event handling
 system into the lifecycle methods;

 =
 https://issues.apache.org/jira/browse/TRINIDAD-1614

 On Tue, Oct 27, 2009 at 1:27 PM, Matthias Wessendorf mat...@apache.org 
 wrote:
 Hi,

 the spec defines two new lifecycle methods for JSF 2.0:
 protected void pushComponentToEL(FacesContext context);
 protected void popComponentFromEL(FacesContext context)

 These are the base contract from the new implicit #{component} EL.

 The spec wants an implementation to call these new methods inside of
 the lifecycle
 (processXYZ and encodeBegin). It also says that is should be called
 inside the new visitTree()
 method.

 See [1] for the entire JavaDoc for the class.

 As we - currently - have our own Visitor implementation, I am focusing
 here on the usage of the
 pushComponentToEL/popComponentFromEL to be called (for now) only on
 those lifecylce methods:
 -encodeBegin()
 -processDecodes()
 -processRestoreState()
 -processSaveState()
 -processUpdates()
 -processValidators()

 Regarding the Tree/Visitor implementation, I will follow up on this in
 a separate thread, once I
 managed to write down the diffs between our (Trinidad) impl and the
 one from the spec.

 So, as for now I am proposing that we should integrate the
 pushComponentToEL/popComponentFromEL
 hooks for the mentioned methods.

 If this is really cause very bad performance results, we can
 reevaluate the situation later on, again.

 Any thoughts ?


 [1] 
 http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/javax/faces/component/UIComponent.html

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

[Trinidad 2.0] relocatable res support on existing components (trh:script)?

Hi,

there are some new standard tags that are going to register resources
with the tr:document,
once these tasks are committed/implemented:

https://issues.apache.org/jira/browse/TRINIDAD-1610
https://issues.apache.org/jira/browse/TRINIDAD-1611

Should we add similar support to our existing tags?

Today something like
  trh:script source=#{resource['foo.js']} /

renders inline. Maybe we should give the page author the right to
*target* this to head (or form or body) ?
We also could leverage the new terminology of name=foo.js and
library=corp (which would be similar
to #{resource['corp:foo.js']}.

What do you think ?

-Matthias

-- 
Matthias Wessendorf

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

Re: [MyFaces 2.0] calling popComponentFromEL/pushComponentToEL setParent() ?

ok, we keep it as it is. We will see what the TCK says for MyFaces.
(once we are actually able to run it)

-M

On Tue, Oct 27, 2009 at 1:38 PM, Blake Sullivan
blake.sulli...@oracle.com wrote:
 I don't think that it should do this.  There is no guarantee that any of the
 ancestors will have pushed their context in this case and in the absence of
 such a guarantee, pushing context is dangerous because it means that there
 would be no way to guarantee correct EL context setup for listeners that
 need to look at component attributes.  Note also that because JSF doesn't
 manage the stack of EL contexts, when an event is made under context, the
 only EL-bound attributes that the component can safely retrieve are those on
 itself (directly) and on its children (using invokeOnComponent or tree
 visiting).

 -- Blake Sullivan

 On Oct 27, 2009, at 12:07 PM, Matthias Wessendorf wrote:

 Hi,

 I read up on the UIComponent.visitTree and it says its implementation
 has to call pushComponentToEL()/popComponentFromEL()
 before/after the processing. Somehow I feel that we may should do this
 on the setParent() call as well.

 Similar to our visitTree() implementation ([1]), at the end/beginning
 of the method. I know the spec (and JavaDoc) says nothing
 about this, but from reading on visitTree()'s javadoc, it sounds
 reasonable.

 Any thoughts ?

 -Matthias

 [1]
 http://svn.apache.org/repos/asf/myfaces/core/trunk/api/src/main/java/javax/faces/component/UIComponentBase.java

 --
 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: JSF 2.0 - Bean Validation, Unified EL and other specs

Hi Jan-Kees,

thanks for creating this ticket. I'd like to see something like this.
Sounds (to me) very useful...

-M

On Tue, Oct 27, 2009 at 12:09 PM, Jan-Kees van Andel
jankeesvanan...@gmail.com wrote:
 Just to be complete...

 https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=657

 /JK


 2009/10/27 Ryan Lubke ryan.lu...@sun.com:
 On 10/25/09 10:57 AM, Jan-Kees van Andel wrote:

 Hey (CC MyFaces Dev),

 For MyFaces, I have implemented the first version of Bean Validation
 support. But my implementation had a TCK issue, because I had some
 non-specified public fields. These fields indicated the runtime
 availability of some libraries.
 See: http://issues.apache.org/jira/browse/MYFACES-2386 for the issue.

 To fix it, I've moved the public fields to a separate, package-private
 class (still in the API), to hide them from end users and fix TCK
 issues.
 But the problem with this solution is that the fields are used in more
 than one package (currently validate and component. Probably more
 to come), giving me only one option: Code duplication.

 I personally hate code duplication, which leads me to the question: Is
 it a good idea to put an API in the spec which contains the
 information I'm providing in my current class?

 Initially I wrote this message because I hate code duplication, but
 there might be another benefit, since 3th party libraries may also
 want to check the existence of certain libraries. Especially Bean
 Validation and Web Beans may have impact on framework/component
 authors. I think some API like this is quite important, because JSF
 (since 2.0) doesn't live on its own anymore, but interacts with other
 libraries as well.

 My implementation

 (http://svn.apache.org/viewvc/myfaces/core/trunk/api/src/main/java/javax/faces/validator/_ExternalSpecifications.java?revision=829526view=markup)
 currently works for MyFaces, but the official API may need to be a bit
 more reusable/extensible.
 I was thinking of something simple:
 public interface FacesEnvironment /* This name probably sucks */ {
     public boolean isBeanValidationAvailable();
     public boolean isUnifiedELAvailable();
     // ...
 }

 An interface might be overkill, but the EG may work out the details. ;-)


 Specifics such as interfaces aside, this seems like a useful concept.  I
 would recommend
 logging an issue against the spec [1] for 2.1.

 [1] https://javaserverfaces-spec-public.dev.java.net

 What do you guys think? Useful addition for JSF 2.1?

 Regards,
 Jan-Kees van Andel

 -
 To unsubscribe, e-mail: dev-unsubscr...@javaserverfaces.dev.java.net
 For additional commands, e-mail: dev-h...@javaserverfaces.dev.java.net




 -
 To unsubscribe, e-mail: dev-unsubscr...@javaserverfaces.dev.java.net
 For additional commands, e-mail: dev-h...@javaserverfaces.dev.java.net



 -
 To unsubscribe, e-mail: dev-unsubscr...@javaserverfaces.dev.java.net
 For additional commands, e-mail: dev-h...@javaserverfaces.dev.java.net





-- 
Matthias Wessendorf

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

[Trinidad 2.0] Relocatable Resources - API proposal

2009-10-26 Thread Matthias Wessendorf

Hi,

in order to avoid dependency to h:head/body/form BUT be able to
support the Relocatable Resources feature, we should change our
renderers for head, body and form to check
for any component resource(s) that has been targeted to one of these guys.

This would mean that something like this just works:
tr:document
  xmlns=http://www.w3.org/1999/xhtml;
  xmlns:f=http://java.sun.com/jsf/core;
  xmlns:h=http://java.sun.com/jsf/html;
  xmlns:tr=http://myfaces.apache.org/trinidad;
  title=TESTER of Scripts

h:outputScript target=body name=myCoolBody.js/
h:outputScript target=head name=anAwesomeHead.js/

/tr:document
== no need to add the nasty h:head/body.

The call inside of the renderer should be fairly simple:
...
for(UIComponent comp :
context.getViewRoot().getComponentResources(context, head))
{
  comp.encodeAll(context);
}
...
Note: We need to render out these resources pretty much BEFORE we end
the particular HTML element (e.g.  head, body or form)...

In order to avoid duplicated code, I think we want to add a utility
which should be called from particular renderers, like on
CoreRenderer.java (part of the Trinidad API). This would allow
extensions to easily use this new API as well...

suggested change to CoreRenderer.java =
  /**
   * Hook for rendering the component resources for the codetarget/code.
   * @param context Current codeFacesContext/code object for this request.
   * @param target The target for the resources (e.g. head/body/form)
   *
   * @throws IOException
   */
  protected final void encodeComponentResources(
FacesContext context,
String   target) throws IOException
  {
if(target != null)
{
  UIViewRoot viewRoot = context.getViewRoot();
  for(UIComponent componentResource :
viewRoot.getComponentResources(context, target))
  {
componentResource.encodeAll(context);
  }
}
  }

As a matter of fact the HeadRenderer's encodeEnd() method would simply
look like:

  protected void encodeEnd(
FacesContextcontext,
RenderingContext arc,
UIComponent comp,
FacesBean   bean) throws IOException
  {
ResponseWriter rw = context.getResponseWriter();

// trigger the rendering of targeted resource
// for the HEAD, on UIViewRoot - if there are
// any...
encodeComponentResources(context, head);

rw.endElement(head);
  }

-Matthias

-- 
Matthias Wessendorf

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

Re: [Trinidad 2.0] Relocatable Resources - API proposal

2009-10-26 Thread Matthias Wessendorf

oh, yeah... of course this can only work when we change our
UIXComponentBase's setParent() to trigger the new PostAddToViewEvent
event.

A simple implementation of the setParent() is available here:
http://svn.apache.org/repos/asf/myfaces/core/trunk/api/src/main/java/javax/faces/component/UIComponentBase.java
(No, due to licensing issues, I am not looking at the RI code...)

As this event subsystem doesn't come for free (in terms of PERF
costs), I will try to get some numbers on the inclusion of the
behavior.
However, the benefit of the relocatable resources feature is that we
don't need to worry about duplicated resources, as something like
this:
...
  h:outputScript target=body name=fooBody.js/
  h:outputScript target=body name=fooBody.js/
  h:outputScript target=body name=fooBody.js/
...

Is only added once to the particular *target*...

Greetings,
Matthias

On Mon, Oct 26, 2009 at 3:45 PM, Matthias Wessendorf mat...@apache.org wrote:
 Hi,

 in order to avoid dependency to h:head/body/form BUT be able to
 support the Relocatable Resources feature, we should change our
 renderers for head, body and form to check
 for any component resource(s) that has been targeted to one of these guys.

 This would mean that something like this just works:
 tr:document
  xmlns=http://www.w3.org/1999/xhtml;
  xmlns:f=http://java.sun.com/jsf/core;
  xmlns:h=http://java.sun.com/jsf/html;
  xmlns:tr=http://myfaces.apache.org/trinidad;
  title=TESTER of Scripts

    h:outputScript target=body name=myCoolBody.js/
    h:outputScript target=head name=anAwesomeHead.js/

 /tr:document
 == no need to add the nasty h:head/body.

 The call inside of the renderer should be fairly simple:
 ...
    for(UIComponent comp :
 context.getViewRoot().getComponentResources(context, head))
    {
      comp.encodeAll(context);
    }
 ...
 Note: We need to render out these resources pretty much BEFORE we end
 the particular HTML element (e.g.  head, body or form)...

 In order to avoid duplicated code, I think we want to add a utility
 which should be called from particular renderers, like on
 CoreRenderer.java (part of the Trinidad API). This would allow
 extensions to easily use this new API as well...

 suggested change to CoreRenderer.java =
  /**
   * Hook for rendering the component resources for the codetarget/code.
   * @param context Current codeFacesContext/code object for this request.
   * @param target The target for the resources (e.g. head/body/form)
   *
   * @throws IOException
   */
  protected final void encodeComponentResources(
    FacesContext context,
    String       target) throws IOException
  {
    if(target != null)
    {
      UIViewRoot viewRoot = context.getViewRoot();
      for(UIComponent componentResource :
 viewRoot.getComponentResources(context, target))
      {
        componentResource.encodeAll(context);
      }
    }
  }

 As a matter of fact the HeadRenderer's encodeEnd() method would simply
 look like:

  protected void encodeEnd(
    FacesContext        context,
    RenderingContext arc,
    UIComponent         comp,
    FacesBean           bean) throws IOException
  {
    ResponseWriter rw = context.getResponseWriter();

    // trigger the rendering of targeted resource
    // for the HEAD, on UIViewRoot - if there are
    // any...
    encodeComponentResources(context, head);

    rw.endElement(head);
  }

 -Matthias

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

[MyFaces 2.0] / [JSF 2.0] SPEC not too clear on setParent() description = MYFACES-2389 review request

2009-10-26 Thread Matthias Wessendorf

Hi,

some of the hidden secrets of the new spec have been forgotten to be
spec'd out :-(

While checking on MyFaces's setParent() implementation, I decided to
do a little clean up.

Please see the patch here:
https://issues.apache.org/jira/browse/MYFACES-2389

Generally I am wondering about the previous implementation as nothing
like that has been mentioned in the spec at all.
Can the MyFaces EG members confirm that this version is correct ?

Would be also good if they were able to speed up on this ticket as well:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1384

Greetings,
Matthias

-- 
Matthias Wessendorf

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

Re: [JSF 2.0] JSR 303 support in MyFaces 2.0

Nope, I checked the JavaDoc (I am not looking at the code, for a
couple of reasons),
and there is nothing like that.

So, maybe there is need for such an helper, as there are already today
- as a matter
of practical use - some issues with the current spec.

Let me file an ER for this.

-Matthias

On Wed, Oct 21, 2009 at 6:15 AM, Martin Marinschek
mmarinsc...@apache.org wrote:
 Well, we can definitely not add a public field to the API which is not
 specified. The question is only if maybe the RI added some public
 field which was not specified - then this could be a spec bug.

 regards,

 Martin

 On 10/20/09, Matthias Wessendorf mat...@apache.org wrote:
 I think the question is why there isn't a helper like
 BeanValidation.isBeanValidation() specified ?
 Implementation could be somewhat similar to what MyFaces
 does today. But I wonder why this wasn't done...

 -M

 On Mon, Oct 19, 2009 at 9:14 PM, Matthias Wessendorf mat...@apache.org
 wrote:
 Hi,

 in order to work on Trinidad 2.0 and 303 support (yeah need to check
 what Gerhard did for extVal) I
 took a quick look at the UIInput.

 I noticed a few lines containing a call like this:

 = BeanValidator.isAvailable

 This is a public field which is only there in MyFaces, not in the JSF
 2.0 API ([1]).

 I know that the entire handling of checking if there is a JSR 303
 implementation is
 a little bit ugly, but I am not sure if we should introduce such a
 public field to the
 BeanValidator validator class.

 = wouldn't be good if extensions would start to rely on this field; I
 guess not there on the RI ;-)
 = does this violate the TCK ? Or would it be ? I am not sure here
 two, as it is a public field

 Maybe we should make the make the check become a private thing ?

 -Matthias


 [1] http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/index.html

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



 --

 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: JSF 2.0 - resource handling - localePrefix ?

Hi Udo,

that sounds good. I am pretty sure if the entire process was a little
bit more open,
perhaps this would have been addressed a bit earlier. Oh well

-Matthias

On Wed, Oct 21, 2009 at 12:24 AM, Udo Schnurpfeil u...@schnurpfeil.de wrote:
 By the way,

 Tobago uses also a Resource Management since years, and also uses the good
 old Java style (with suffix).
 We have good experience with that way, with properties, images, scripts,
 styles, etc.

 Regards

 Udo

 Matthias Wessendorf schrieb:

 Got a response from Ed Burns:

 ed
 This is a well documented and understood shortcoming of the Resource
 Handling system.  We will address it in 2.1.
 /ed

 On Tue, Oct 20, 2009 at 2:05 PM, Grant Smith work.gr...@gmail.com wrote:


 I prefer the spec's way. I would hate to have to have the resource
 identifier as part of each file in the library.. Imaging naming hundreds
 of
 .gif files. This way it's just part of the directory name.

 The properties file is just one file per locale, so that's not such a big
 deal.

 On Tue, Oct 20, 2009 at 1:56 PM, Matthias Wessendorf mat...@apache.org
 wrote:


 Hi,

 I am reading SPEC 2.6.1.3 and I am not sure on the localePrefix...

 Imagine I am using a library in the $WEB_ROOT/resources
 so the USA, the resourceIdentifier would be like:
 en_US/mycorp/cool.gif

 and for Germany, it would be:
 de_DE/mycorp/cool.gif

 I wonder why it was done this way ?

 For the properties files, they syntax is following this schema:

 Messages_en_US.properties
 Messages_de_DE.properties

 Perhaps I am not really understanding the benefit of the JSF 2.0
 resource handling, but
 why shouldn't a library contain multiple images (etc), like:

 /mycorp/cool_de_DE.gif
 /mycorp/cool_en_US.gif

 -Matthias

 --
 Matthias Wessendorf

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


 --
 Grant Smith











-- 
Matthias Wessendorf

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

Re: JSF 2.0 - resource handling - localePrefix ?

Hi,

do you know if there is already a bug for that ? If not, let me create one.

-Matthias

On Wed, Oct 21, 2009 at 6:09 AM, Martin Marinschek
mmarinsc...@apache.org wrote:
 Actually, that is a question that I brought up to the EG months ago
 (it might even have been half a year), following a request of Bernd.
 But no discussion ever picked up on this.

 I was - like Bernd and you - also concerned about breaking the normal
 rule, plus creating scarce directory trees.

 regards,

 Martin

 On 10/20/09, Matthias Wessendorf mat...@apache.org wrote:
 Hi,

 I am reading SPEC 2.6.1.3 and I am not sure on the localePrefix...

 Imagine I am using a library in the $WEB_ROOT/resources
 so the USA, the resourceIdentifier would be like:
 en_US/mycorp/cool.gif

 and for Germany, it would be:
 de_DE/mycorp/cool.gif

 I wonder why it was done this way ?

 For the properties files, they syntax is following this schema:

 Messages_en_US.properties
 Messages_de_DE.properties

 Perhaps I am not really understanding the benefit of the JSF 2.0
 resource handling, but
 why shouldn't a library contain multiple images (etc), like:

 /mycorp/cool_de_DE.gif
 /mycorp/cool_en_US.gif

 -Matthias

 --
 Matthias Wessendorf

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



 --

 http://www.irian.at

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

 Professional Support for Apache MyFaces




-- 
Matthias Wessendorf

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

Re: [JSF 2.0] UIInput in MyFaces 2.0

On Wed, Oct 21, 2009 at 5:21 AM, Martin Marinschek
mmarinsc...@apache.org wrote:
 Yeah, forgotten. We are stumbling over quite a few issues while trying
 out the spec in reality, hmm?

I think trying out - for applications - is different than moving a
complex and highly customized
framework to a new spec. But I was not expecting a too smooth
integration. Better we find
those issues now, to be addressed by the next release.

-Matthias


 regards,

 Martin

 On 10/20/09, Andy Schwartz andy.g.schwa...@gmail.com wrote:
 Thanks for logging the spec issue Matthias.  I agree that this was
 just overlooked in the spec.  Should be easy to correct next time
 around.

 Andy



 --

 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: [Trinidad] [API] Making XhtmlConstants (from IMPL module) a public API

On Mon, Oct 19, 2009 at 7:25 AM, Simon Lessard
simon.lessar...@gmail.com wrote:
 Hi all,

 Personally, I would prefer to see that class divided in more specialized
 classes like :

 XhtmlElements
 {
     public static final String DIV = div; (or could be DIVISION)
     public static final String TABLE = table;
     public static final String TABLE_BODY = tbody;
     public static final String TABLE_DATA_CELL = td;
     public static final String TABLE_HEADER_CELL = th;
     public static final String TABLE_ROW = tr;
     // ...
 }

 XhtmlAttributes
 {
     public static final String HANDLER_CLICK = onclick;
     public static final String STYLE_CLASS = class;
     // ...
 }

 And so on. This kind of separation often make the constant names clearer (no
 need to prefix the constant type like ELEMENT_ or ATTR_).

yeah, I mentioned before that this current class has been created while copying
things over to it. Not sure what the motivation was for that. Perhaps
Blake knows
more ?


 About the general idea to move such constants to the API, I'm +1 though.

OK, that's what I do for now;



 Regards,

 ~ Simon

 On Mon, Oct 19, 2009 at 8:35 AM, Scott O'Bryan darkar...@gmail.com wrote:

 Why is this being done again?

 Sent from my iPhone

 On Oct 18, 2009, at 10:32 PM, Blake Sullivan blake.sulli...@oracle.com
 wrote:

 +1

 -- Blake Sullivan

 On Oct 18, 2009, at 9:11 PM, Matthias Wessendorf wrote:

 Maybe we should also rename the old XhtmlConstants class ?
 Would make sense, as all the (x)html stuff is about to be moved to API.

 Since this class is containing misc things, like HTML (gone), events,
 params
 and other rendering stuff (e.g. the * for the inputText
 (secret:true)), we could
 be lazy by renaming it to something like:

 TrinidadRenderingConstants

 We could also try to clean it up even more, by making it multiple
 classes...
 From looking at the comments it looks like it has been copied from
 multiple
 places to a single class; So not sure if we really wanna go to split it
 up even
 more...

 -Matthias

 On Fri, Oct 16, 2009 at 11:21 AM, Blake Sullivan
 blake.sulli...@oracle.com wrote:

 +1

 -- Blake Sullivan

 Matthias Wessendorf said the following On 10/16/2009 11:12 AM PT:

 On Thu, Oct 15, 2009 at 6:12 PM, Blake Sullivan
 blake.sulli...@oracle.com wrote:


 Matthias Wessendorf said the following On 10/15/2009 5:48 PM PT:


 Hi,

 I'd like to move the XhtmlConstants class to the API.
 The only dependency on another IMPL class is very simple.
 It is a constant, that resolves to a String (portlet).

 If nobody disagrees, I will move on with the move.
 Yeah, just on trunk (Trinidad 1.2.x)

 Thx,
 Matthias




 Matthias,

 A bunch of the constants appear to be implementation-dependent.  Rather
 than
 making the entire class public, I think you should come up with a
 proposal
 for which constants you want to move to a public class.


 took a more detailed look and noticed that a bunch of mixed things are
 in that class.

 I think we should maybe just move the XHTML specific stuff to be an
 API part, b/c
 some of the stuff *can* be useful one other (renderer) implementations
 as
 well.

 Here is a list, of what I have in mind:
 public static final String FACET_PORTLET = portlet;
 public static final String SCRIPT_NAME = script;
 public static final String H_ALIGN_END = end;
 public static final String V_ALIGN_MIDDLE = middle;
 public static final String V_ALIGN_TOP = top;
 public static final String DIV_ELEMENT          = div;
 public static final ListString HEADER_ELEMENTS =
  Arrays.asList(new String[]{h1, h2, h3,
                             h4, h5, h6});
 public static final String LINK_ELEMENT         = a;
 public static final String PARAGRAPH_ELEMENT = p;
 public static final String SCRIPT_ELEMENT       = script;
 public static final String SPAN_ELEMENT         = span;
 public static final String TABLE_DATA_ELEMENT   = td;
 public static final String TABLE_BODY_ELEMENT   = tbody;
 public static final String TABLE_ELEMENT        = table;
 public static final String TABLE_HEADER_ELEMENT = th;
 public static final String TABLE_ROW_ELEMENT    = tr;

 public static final String FIELDSET_ELEMENT     = fieldset;
 public static final String LEGEND_ELEMENT       = legend;
 public static final char NBSP_CHAR = 0xA0;
 public static final String NBSP_STRING = String.valueOf(NBSP_CHAR);

 public static final String ALIGN_ATTRIBUTE      = align;
 public static final String COLS_ATTRIBUTE       = cols;
 public static final String COLSPAN_ATTRIBUTE    = colspan;
 public static final String HEIGHT_ATTRIBUTE     = height;
 public static final String HREF_ATTRIBUTE       = href;
 public static final String ID_ATTRIBUTE         = id;
 public static final String NOWRAP_ATTRIBUTE     = nowrap;
 public static final String ONCLICK_ATTRIBUTE    = onclick;
 public static final String ROWS_ATTRIBUTE      = rows;
 public static final String ROWSPAN_ATTRIBUTE    = rowspan;
 public static final String SIZE_ATTRIBUTE

Re: [JSF 2.0] JSR 303 support in MyFaces 2.0

On Wed, Oct 21, 2009 at 9:36 AM, Jan-Kees van Andel
jankeesvanan...@gmail.com wrote:
 I've added those constants. Can't remember why I made them public. I
 assume because they are used by the BeanValidator class.

 The reason to make them static final with the static initializer block
 was because it made them easy to use and also because it's very
 efficient (performance wise).

well, we can't mess up with the dictated API (by the spec)


 Maybe they need to be refactored to some other class than UIInput? I
 think so, especially since Bean Validation is not the only JSF2
 dependency. In the future we'll also have Web Beans and maybe JSR 330?
 The amount of is***Available checks will definitely increase...

we could have some package private stuff, which is fine. But we can't add other
heavy dependencies to the API. As we have to pass - at some day - the TCK.

-Matthias


 Regards,
 Jan-Kees


 2009/10/21 Matthias Wessendorf mat...@apache.org:
 Nope, I checked the JavaDoc (I am not looking at the code, for a
 couple of reasons),
 and there is nothing like that.

 So, maybe there is need for such an helper, as there are already today
 - as a matter
 of practical use - some issues with the current spec.

 Let me file an ER for this.

 -Matthias

 On Wed, Oct 21, 2009 at 6:15 AM, Martin Marinschek
 mmarinsc...@apache.org wrote:
 Well, we can definitely not add a public field to the API which is not
 specified. The question is only if maybe the RI added some public
 field which was not specified - then this could be a spec bug.

 regards,

 Martin

 On 10/20/09, Matthias Wessendorf mat...@apache.org wrote:
 I think the question is why there isn't a helper like
 BeanValidation.isBeanValidation() specified ?
 Implementation could be somewhat similar to what MyFaces
 does today. But I wonder why this wasn't done...

 -M

 On Mon, Oct 19, 2009 at 9:14 PM, Matthias Wessendorf mat...@apache.org
 wrote:
 Hi,

 in order to work on Trinidad 2.0 and 303 support (yeah need to check
 what Gerhard did for extVal) I
 took a quick look at the UIInput.

 I noticed a few lines containing a call like this:

 = BeanValidator.isAvailable

 This is a public field which is only there in MyFaces, not in the JSF
 2.0 API ([1]).

 I know that the entire handling of checking if there is a JSR 303
 implementation is
 a little bit ugly, but I am not sure if we should introduce such a
 public field to the
 BeanValidator validator class.

 = wouldn't be good if extensions would start to rely on this field; I
 guess not there on the RI ;-)
 = does this violate the TCK ? Or would it be ? I am not sure here
 two, as it is a public field

 Maybe we should make the make the check become a private thing ?

 -Matthias


 [1] http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/index.html

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



 --

 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





-- 
Matthias Wessendorf

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

Re: [jira] Updated: (TRINIDAD-1600) Trinidad2 - Dialog navigation clears View Scope

remove the 's' in the https. The issue is the proxy on your side; I
noticed that problem as well.

-M

On Tue, Oct 20, 2009 at 8:13 AM, Max Starets max.star...@oracle.com wrote:
 Hi Martin,

 I have a few questions. Apache JIRA is not working properly (I am unable log
 in), so I will ask them here:

 Can we handle the dialog case better for cases when the delegate
 NavigationHandler is unable to provide the navigation case
 (navigationCase is null)? I think we could essentially execute the old code
 (call handleNavigation(), but save the viewMap before the call
 and then restore it after).
 Given that we need to handle the scenario without a navigationCase (see
 above), wouldn't it be simpler to just keep the old code and
 save/restore the viewMap?

 Thanks,
 Max

 Martin Koci (JIRA) wrote:

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

 Martin Koci updated TRINIDAD-1600:
 --

 Status: Patch Available  (was: Open)



 Trinidad2 - Dialog navigation clears View Scope
 ---

 Key: TRINIDAD-1600
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1600
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.0-core
 Environment: Trinidad 2.0 branch, JSF RI 2.0.0RC2
Reporter: Martin Koci
 Attachments: patch.txt


 JSF 2.0 introduces new scope View Scope implemented with a Map
 UIViewRoot.viewMap. Spec also says that call FacesConfig.setViewRoot()
 clears that Map.
 Problem: Trinidad NavigationHandler uses method handleNavigation for
 detection if a dialog navigation will be performed - however that method
 creates new UIViewRoot and sets it to FacesContext - clears view scope. If
 user places managed bean into view scope and starts a dialog: navigation on
 that view, bean is removed and new instance of the bean is created after
 dialog return.
 Solution: use new JSF 2.0 ConfigurableNavigationHandler API







-- 
Matthias Wessendorf

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

Re: [JSF 2.0] UIInput in MyFaces 2.0

On Mon, Oct 19, 2009 at 9:43 PM, Matthias Wessendorf mat...@apache.org wrote:
 hi,

 looking at more of the new code, I noticed these lines in MyFaces 2.0:

    public static final String EMPTY_VALUES_AS_NULL_PARAM_NAME =
 javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL;
    public static final String VALIDATE_EMPTY_FIELDS_PARAM_NAME =
 javax.faces.VALIDATE_EMPTY_FIELDS;

 According to the latest greatest JavaDoc, only
 VALIDATE_EMPTY_FIELDS_PARAM_NAME is part of the UIInput.
 Not sure if we should make this really a public constant.

 I am also wondering why the other one hasn't been made public ?
 Can one from the EG comment on this ?

Ok, as it is IMO a little bid odd that the constant has been forgotten, I
just created this ticket:

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1374

Basically I feel that MyFaces is technically doing the right thing, it
just has been forgotten in the spec.

-Matthias


 Thanks!
 Matthias

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

[Trinidad 2.0] Ordering of artifacts (sec 11.4.7 in the JSF 2.0 spec)

Hi,

for adding support for 11.4.7, I am proposing we introduce a unique
ID/NAME for the Apache MyFaces Trinidad library

I think that we want something like this (to be added to the
faces-config-base.xml):
faces-config

  name
org.apache.myfaces.trinidad
  /name
...

/faces-config

Not sure if we want something like

org.apache.myfaces.trinidad versus org.apache.myfaces.TRINIDAD...

I am (personally) fine with org.apache.myfaces.trinidad

-Matthias

-- 
Matthias Wessendorf

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

Re: [Trinidad 2.0] Ordering of artifacts (sec 11.4.7 in the JSF 2.0 spec)

https://issues.apache.org/jira/browse/TRINIDAD-1603

On Tue, Oct 20, 2009 at 10:11 AM, Matthias Wessendorf mat...@apache.org wrote:
 Hi,

 for adding support for 11.4.7, I am proposing we introduce a unique
 ID/NAME for the Apache MyFaces Trinidad library

 I think that we want something like this (to be added to the
 faces-config-base.xml):
 faces-config

  name
    org.apache.myfaces.trinidad
  /name
 ...

 /faces-config

 Not sure if we want something like

 org.apache.myfaces.trinidad versus org.apache.myfaces.TRINIDAD...

 I am (personally) fine with org.apache.myfaces.trinidad

 -Matthias

 --
 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: [Trinidad2] Resources API support

On Fri, Oct 16, 2009 at 8:25 AM, Martin Kočí martin.k...@aura.cz wrote:
 Hi,

 please review simple patch
 https://issues.apache.org/jira/browse/TRINIDAD-1596.

 More question about Resource support in trinidad2:

 1) JSF 2 introduced name and library as an alternative to src,
 image or icon for example. According to tag library documentation
 there is support only on h:graphicImage, but surprisingly it works  with
 h:commandButton too (and maybe other).

I see name/library on outputScript/Stylesheet as well.


 Should trinidad support name and library with tr:image (an alternative
 to h:graphicImage)?

hrm. I'd think so.


 If a component has exactly one image attribute (icon in trinidad)
 interpret name/library as alternative to it ? I think name and
 library are too generic - they should be named iconName and
 iconLibrary or something like that.

we should use name/libray!

On things like script you'd have to have a different syntax
(scriptName/scriptLib), which would make things more weird,
I guess



 Folowing components have icon attribute:
 CoreInputListOfValues
 CorePanelBox
 CorePanelHeader
 CorePanelPopup
 CoreShowDetailHeader
 CoreCommandButton
 CoreCommandNavigationItem
 CoreGoButton

 I dont really understand if name/library concept was intended for
 components without behaviour from 'resource'  family like image or CSS.

I think it makes sense. Like one corp folder which has 3 images and 2 files
library=corp name = foo.png OR bar.js

-Matthias

 2) HTML head section
 There are h:outputStylesheet and h:outputScript in JSF 2.0  . Both
 support name and library attrs too. If we will rework trinidad2  to
 Resource API is there any reason why add to trh:styleSheeet
 name/library support?
 I think trh: tags can remain for JSP/old application and without
 name/library attrs and for new trinidad2/Facelets based application
 users can use new tags from JSF 2.0

 Note: name/library are only a option to #{resource} implicit object.


 Regards,

 Martin


-- 
Matthias Wessendorf

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

Re: [VOTE] Release of Portlet Bridge 1.0.0 Beta 2

2009-10-19 Thread Matthias Wessendorf

On Tue, Jul 14, 2009 at 6:16 AM, Scott O'Bryan darkar...@gmail.com wrote:
 OK everyone.  I'm going to restart this vote.

what happened to this vote ?
was it re-done ?

 I've updated the example
 artifacts to include a war that can be run with pluto.

 michael freedman wrote:

 It would be nice if the demo distribution additionally carried a .war file
 for installing the demo on pluto.
   -Mike-

 Scott O'Bryan wrote:

 Hi,

 I'm trying to release the MyFaces Portlet Bridge 1.0.0 Beta 2 and am now
 beginning the formal vote.

 You can find the signed release candidate at [1]

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

 [1] http://people.apache.org/~sobryan/portlet-bridge/1.0.0-beta-2






-- 
Matthias Wessendorf

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

Re: [RESULTS] Release of Portlet Bridge 2.0.0-alpha-2

2009-10-19 Thread Matthias Wessendorf

what happened to this vote ?
was there a release ? I am not seeing an announce email ...

-Matthias

On Thu, Sep 10, 2009 at 4:24 AM, Scott O'Bryan darkar...@gmail.com wrote:
 The vote for the release of Portlet Bridge 2.0.0-alpha-2 has passed. [1]

 +1: Matthias Wessendorf, Mike Freedman, Scott O'Bryan
 +0: none
 -1: none

 Thanks to everyone who voted.
 Scott O'Bryan

 [1]
 http://www.nabble.com/-VOTE--Release-of-Portlet-Bridge-2.0.0-alpha-2-td24958954.html




-- 
Matthias Wessendorf

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

[scripting extension] startup error

2009-10-18 Thread Matthias Wessendorf

hi,

I tried to deploy the scripting WAR file demo to Tomcat 6 (java
1.6.11) on my windows box.

I am getting this:
SCHWERWIEGEND: Exception sending context initialized event to listener
instance of class
org.apache.myfaces.webapp.StartupServletContextListener
java.lang.ExceptionInInitializerError
at 
org.apache.myfaces.shared_impl.webapp.webxml.WebXml.init(WebXml.java:243)
at 
org.apache.myfaces.shared_impl.webapp.webxml.WebXml.getWebXml(WebXml.java:228)
at 
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:72)
at 
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:139)
at 
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3843)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4342)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:830)
at 
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:719)
at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1217)
at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:293)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at 
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.StringIndexOutOfBoundsException: String index out
of range: 1
at java.lang.String.charAt(String.java:687)
at java.util.regex.Matcher.appendReplacement(Matcher.java:703)
at java.util.regex.Matcher.replaceAll(Matcher.java:813)
at java.lang.String.replaceAll(String.java:2190)
at 
org.apache.myfaces.scripting.api.BaseWeaver.loadScriptingClassFromName(BaseWeaver.java:159)
at 
org.apache.myfaces.scripting.core.CoreWeaver.loadScriptingClassFromName(CoreWeaver.java:85)
at 
org.apache.myfaces.scripting.servlet.CustomChainLoader.forName(CustomChainLoader.java:110)
at 
org.apache.myfaces.shared_impl.util.ClassUtils.classForName(ClassUtils.java:158)
at 
org.apache.myfaces.shared_impl.config.MyfacesConfig.clinit(MyfacesConfig.java:120)
... 20 more

the clazz name string that causes the error in BaseWeaver is
org.apache.myfaces.webapp.filter.ExtensionsFilter


-Matthias

-- 
Matthias Wessendorf

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

Re: [Trinidad] [API] Making XhtmlConstants (from IMPL module) a public API

2009-10-18 Thread Matthias Wessendorf

Maybe we should also rename the old XhtmlConstants class ?
Would make sense, as all the (x)html stuff is about to be moved to API.

Since this class is containing misc things, like HTML (gone), events, params
and other rendering stuff (e.g. the * for the inputText
(secret:true)), we could
be lazy by renaming it to something like:

TrinidadRenderingConstants

We could also try to clean it up even more, by making it multiple classes...
From looking at the comments it looks like it has been copied from multiple
places to a single class; So not sure if we really wanna go to split it up even
more...

-Matthias

On Fri, Oct 16, 2009 at 11:21 AM, Blake Sullivan
blake.sulli...@oracle.com wrote:
 +1

 -- Blake Sullivan

 Matthias Wessendorf said the following On 10/16/2009 11:12 AM PT:

 On Thu, Oct 15, 2009 at 6:12 PM, Blake Sullivan
 blake.sulli...@oracle.com wrote:


 Matthias Wessendorf said the following On 10/15/2009 5:48 PM PT:


 Hi,

 I'd like to move the XhtmlConstants class to the API.
 The only dependency on another IMPL class is very simple.
 It is a constant, that resolves to a String (portlet).

 If nobody disagrees, I will move on with the move.
 Yeah, just on trunk (Trinidad 1.2.x)

 Thx,
 Matthias




 Matthias,

 A bunch of the constants appear to be implementation-dependent.  Rather than
 making the entire class public, I think you should come up with a proposal
 for which constants you want to move to a public class.


 took a more detailed look and noticed that a bunch of mixed things are
 in that class.

 I think we should maybe just move the XHTML specific stuff to be an
 API part, b/c
 some of the stuff *can* be useful one other (renderer) implementations as
 well.

 Here is a list, of what I have in mind:
   public static final String FACET_PORTLET = portlet;
   public static final String SCRIPT_NAME = script;
   public static final String H_ALIGN_END = end;
   public static final String V_ALIGN_MIDDLE = middle;
   public static final String V_ALIGN_TOP = top;
   public static final String DIV_ELEMENT  = div;
   public static final ListString HEADER_ELEMENTS =
 Arrays.asList(new String[]{h1, h2, h3,
h4, h5, h6});
   public static final String LINK_ELEMENT = a;
   public static final String PARAGRAPH_ELEMENT = p;
   public static final String SCRIPT_ELEMENT   = script;
   public static final String SPAN_ELEMENT = span;
   public static final String TABLE_DATA_ELEMENT   = td;
   public static final String TABLE_BODY_ELEMENT   = tbody;
   public static final String TABLE_ELEMENT= table;
   public static final String TABLE_HEADER_ELEMENT = th;
   public static final String TABLE_ROW_ELEMENT= tr;

   public static final String FIELDSET_ELEMENT = fieldset;
   public static final String LEGEND_ELEMENT   = legend;
   public static final char NBSP_CHAR = 0xA0;
   public static final String NBSP_STRING = String.valueOf(NBSP_CHAR);

   public static final String ALIGN_ATTRIBUTE  = align;
   public static final String COLS_ATTRIBUTE   = cols;
   public static final String COLSPAN_ATTRIBUTE= colspan;
   public static final String HEIGHT_ATTRIBUTE = height;
   public static final String HREF_ATTRIBUTE   = href;
   public static final String ID_ATTRIBUTE = id;
   public static final String NOWRAP_ATTRIBUTE = nowrap;
   public static final String ONCLICK_ATTRIBUTE= onclick;
   public static final String ROWS_ATTRIBUTE  = rows;
   public static final String ROWSPAN_ATTRIBUTE= rowspan;
   public static final String SIZE_ATTRIBUTE   = size;
   public static final String STYLE_ATTRIBUTE  = style;
   public static final String VALIGN_ATTRIBUTE = valign;
   public static final String WIDTH_ATTRIBUTE  = width;

   public static final String DIR_ATTRIBUTE_VALUE = dir;
   public static final String EMPTY_STRING_ATTRIBUTE_VALUE= ;
   public static final String LEFT_ATTRIBUTE_VALUE= left;
   public static final String MIDDLE_ATTRIBUTE_VALUE  = middle;
   public static final String ONE_HUNDRED_PERCENT_ATTRIBUTE_VALUE = 100%;
   public static final String RIGHT_ATTRIBUTE_VALUE   = right;

 most of the other things are really more specific to internal stuff,
 e.g. event param names etc.

 For the package, I think that the new XhtmlConstants.java could sit in here:
 org.apache.myfaces.trinidad.render


 -Matthias



 -- Blake Sullivan








-- 
Matthias Wessendorf

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

Re: [Trinidad2] Resources API support

2009-10-16 Thread Matthias Wessendorf

quick comment inside

On Fri, Oct 16, 2009 at 8:25 AM, Martin Kočí martin.k...@aura.cz wrote:
 Hi,

 please review simple patch
 https://issues.apache.org/jira/browse/TRINIDAD-1596.

 More question about Resource support in trinidad2:

 1) JSF 2 introduced name and library as an alternative to src,
 image or icon for example. According to tag library documentation
 there is support only on h:graphicImage, but surprisingly it works  with
 h:commandButton too (and maybe other).

 Should trinidad support name and library with tr:image (an alternative
 to h:graphicImage)?

 If a component has exactly one image attribute (icon in trinidad)
 interpret name/library as alternative to it ? I think name and
 library are too generic - they should be named iconName and
 iconLibrary or something like that.

 Folowing components have icon attribute:
 CoreInputListOfValues
 CorePanelBox
 CorePanelHeader
 CorePanelPopup
 CoreShowDetailHeader
 CoreCommandButton
 CoreCommandNavigationItem
 CoreGoButton

 I dont really understand if name/library concept was intended for
 components without behaviour from 'resource'  family like image or CSS.

 2) HTML head section
 There are h:outputStylesheet and h:outputScript in JSF 2.0  . Both
 support name and library attrs too. If we will rework trinidad2  to
 Resource API is there any reason why add to trh:styleSheeet
 name/library support?
 I think trh: tags can remain for JSP/old application and without
 name/library attrs and for new trinidad2/Facelets based application
 users can use new tags from JSF 2.0

I need to go deeper into the research on Resource Handling, and
its impact on Trinidad. Will probably start on this by Monday..

One thing I noticed as well is that you have to target the location (head/body).
Trinidad should not require the h:head/body; instead we should use the head/body
section w/in the tr:document (which is basically using the head/body
tags from trh)

-Matthias


 Note: name/library are only a option to #{resource} implicit object.


 Regards,

 Martin





-- 
Matthias Wessendorf

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

Re: [Trinidad] [API] Making XhtmlConstants (from IMPL module) a public API

2009-10-16 Thread Matthias Wessendorf

On Thu, Oct 15, 2009 at 6:12 PM, Blake Sullivan
blake.sulli...@oracle.com wrote:
 Matthias Wessendorf said the following On 10/15/2009 5:48 PM PT:

 Hi,

 I'd like to move the XhtmlConstants class to the API.
 The only dependency on another IMPL class is very simple.
 It is a constant, that resolves to a String (portlet).

 If nobody disagrees, I will move on with the move.
 Yeah, just on trunk (Trinidad 1.2.x)

 Thx,
 Matthias



 Matthias,

 A bunch of the constants appear to be implementation-dependent.  Rather than
 making the entire class public, I think you should come up with a proposal
 for which constants you want to move to a public class.

took a more detailed look and noticed that a bunch of mixed things are
in that class.

I think we should maybe just move the XHTML specific stuff to be an
API part, b/c
some of the stuff *can* be useful one other (renderer) implementations as well.

Here is a list, of what I have in mind:
  public static final String FACET_PORTLET = portlet;
  public static final String SCRIPT_NAME = script;
  public static final String H_ALIGN_END = end;
  public static final String V_ALIGN_MIDDLE = middle;
  public static final String V_ALIGN_TOP = top;
  public static final String DIV_ELEMENT  = div;
  public static final ListString HEADER_ELEMENTS =
Arrays.asList(new String[]{h1, h2, h3,
   h4, h5, h6});
  public static final String LINK_ELEMENT = a;
  public static final String PARAGRAPH_ELEMENT = p;
  public static final String SCRIPT_ELEMENT   = script;
  public static final String SPAN_ELEMENT = span;
  public static final String TABLE_DATA_ELEMENT   = td;
  public static final String TABLE_BODY_ELEMENT   = tbody;
  public static final String TABLE_ELEMENT= table;
  public static final String TABLE_HEADER_ELEMENT = th;
  public static final String TABLE_ROW_ELEMENT= tr;

  public static final String FIELDSET_ELEMENT = fieldset;
  public static final String LEGEND_ELEMENT   = legend;
  public static final char NBSP_CHAR = 0xA0;
  public static final String NBSP_STRING = String.valueOf(NBSP_CHAR);

  public static final String ALIGN_ATTRIBUTE  = align;
  public static final String COLS_ATTRIBUTE   = cols;
  public static final String COLSPAN_ATTRIBUTE= colspan;
  public static final String HEIGHT_ATTRIBUTE = height;
  public static final String HREF_ATTRIBUTE   = href;
  public static final String ID_ATTRIBUTE = id;
  public static final String NOWRAP_ATTRIBUTE = nowrap;
  public static final String ONCLICK_ATTRIBUTE= onclick;
  public static final String ROWS_ATTRIBUTE  = rows;
  public static final String ROWSPAN_ATTRIBUTE= rowspan;
  public static final String SIZE_ATTRIBUTE   = size;
  public static final String STYLE_ATTRIBUTE  = style;
  public static final String VALIGN_ATTRIBUTE = valign;
  public static final String WIDTH_ATTRIBUTE  = width;

  public static final String DIR_ATTRIBUTE_VALUE = dir;
  public static final String EMPTY_STRING_ATTRIBUTE_VALUE= ;
  public static final String LEFT_ATTRIBUTE_VALUE= left;
  public static final String MIDDLE_ATTRIBUTE_VALUE  = middle;
  public static final String ONE_HUNDRED_PERCENT_ATTRIBUTE_VALUE = 100%;
  public static final String RIGHT_ATTRIBUTE_VALUE   = right;

most of the other things are really more specific to internal stuff,
e.g. event param names etc.

For the package, I think that the new XhtmlConstants.java could sit in here:
org.apache.myfaces.trinidad.render


-Matthias


 -- Blake Sullivan




-- 
Matthias Wessendorf

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

Re: [Trinidad2] Sharing code with myfaces-impl2 in myfaces-shared-core ?

2009-10-15 Thread Matthias Wessendorf

On Thu, Oct 15, 2009 at 6:24 AM, Martin Kočí martin.k...@aura.cz wrote:
 Hi,

 for implementing JSF 2.0 new features in Trinidad2 there is a
 possibility to use myfaces-share project. There are some useful method
 already and many others are on the way.

 This is example why think about it:
 I work on some basic Resource API support for trindiad2. It means for
 example new attributes name and library as a alternative to src or
 icon attributes. An universal method for dealing with this can be like

 method getImageSource in
 http://fisheye5.atlassian.com/browse/~raw,r=1.54/javaserverfaces-sources/jsf-ri/src/com/sun/faces/renderkit/RenderKitUtils.java

 Such method is not in myfaces-impl or myfaces-share yet and thus
 library attribute is not supported now in myfaces 2.0 impl (look in
 button renderer for example).

 Placing one method in myfaces-shared will not lead to duplications over
 myfaces development effort and will bring  faster JSF 2.0 delivery for
 both myfaces 2.0 and Trinidad 2.0. Myfaces-share can be repacked during
 build into trinidad-impl.jar to not burden users with a extra library.

if we share code, building it into the trinidad JAR is the way to go, I agree.

I am not really thrilled about the shared module. It is hard to debug
(e.g. all the impl_shared generated stuff)

Generally, working on common things together is a good idea.

Just keep in mind, that we should not take a too close look to the RI stuff.
(in fact we also can't copy bits..)


Greetings!
Matthias


 What do you think?

 Regards,

 Martin Kočí







-- 
Matthias Wessendorf

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

[Trinidad] maven faces plugin

2009-10-15 Thread Matthias Wessendorf

Hi,

I noticed today that the maven-faces-plugin still requires source/target 1.4
As all the other stuff is currently depending on Java 5, I'd like to go ahead
and change the plugins to be completely on 1.5.

Anyone against it ?

Thanks!
Matthias

-- 
Matthias Wessendorf

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

[Trinidad] [API] Making XhtmlConstants (from IMPL module) a public API

2009-10-15 Thread Matthias Wessendorf

Hi,

I'd like to move the XhtmlConstants class to the API.
The only dependency on another IMPL class is very simple.
It is a constant, that resolves to a String (portlet).

If nobody disagrees, I will move on with the move.
Yeah, just on trunk (Trinidad 1.2.x)

Thx,
Matthias

-- 
Matthias Wessendorf

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

Re: [Trinidad2] FacesBean and JSF 2.0

2009-10-13 Thread Matthias Wessendorf

Hello,

I now applied Max's patch to Trinidad 2.0.0 branch ([1]).

Have fun!

-Matthias

[1] https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x

On Mon, Oct 12, 2009 at 6:48 AM, Max Starets max.star...@oracle.com wrote:
Martin,

Martin Kočí wrote:

Hi,

why I asked about partial state saving is compile-time dependency on
facelets 1.1.X in TrinidadComponentHandler and StateManagerImpl, both on
PARAM_BUILD_BEFORE_RESTORE param. With mojarra 2 jsf-impl and facelets
1.1.x cannot be deployed concurrently.

This code will be commented out in my patch. It will all be sorted out when
we integrate Trinidad's partial state
saving with JSF 2.0.

Few thoughts on facelets2 and trinidad2 :

- change tr.taglib.xml and trh.taglib.xml root element (generated with
maven plugin?) to:

facelet-taglib xmlns=http://java.sun.com/xml/ns/javaee;
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-facelettaglibary_2_0.xsd;
version=2.0

- rewrite TrinidadFaceletViewHandler (if it is still needed) to
ViewDefinitionLanguage

It is going away.

- drop old facelets code from TrinidadComponentHandler,
StateManagerImpl and TrinidadListenersTagRule and dependency from
pom.xml

- and sure more but I'm not familiar with facelets

Regards,

Martin Koci

Max Starets píše v Pá 09. 10. 2009 v 16:50 -0400:

Martin,

I agree we should look at integrating JSF 2.0 partial state saving into
Trinidad seamlessly.
It would not jump to conclusions about FaceBean just yet though.

I am currently working on getting the branch to compile and run with JSF
2.0 (pretty much along the lines
that you were suggesting in your previous e-mail).

I will enter a JIRA for that and submit a patch probably on Monday. Once
we get to a point where we can build
and test, we should start looking at features like partial state saving.

Regards,
Max Starets

Martin Koc(í wrote:

Hi,

for Trinidad2: should we deprecate FacesBean and use StateHelper
instead? I think it is the same idea:

http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/bean/FacesBean.html

https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/component/StateHelper.html
https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/component/PartialStateHolder.html

Concept is related to state saving and I think we should force Trinidad2
to use partial state saving from JSF 2.0 because that was inspired by
trinidad. Am I right?

Martin

--
Matthias Wessendorf

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

Re: [Trinidad] JSF 2.0

Hello Andy,

I created the experimental branch on this location:

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


Greetings,
Matthias


On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz andy.g.schwa...@gmail.com wrote:
 Gang -

 I am interested in taking a closer look at Trinidad/JSF 2.0
 integration.  I suspect that there are other folks who are interested
 in this as well.  Would it be possible to create a Trinidad branch for
 JSF 2.0-related work?  For the moment, I think that an
 experimental/sandbox-type branch that we could use for prototyping
 purposes would be helpful/would facilitate collaboration on this
 effort.

 Thoughts?

 Andy




-- 
Matthias Wessendorf

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

Re: [Trinidad] JSF 2.0

done; added 2.0.0-core

-Matthias

On Thu, Oct 8, 2009 at 12:50 PM, Matthias Wessendorf mat...@apache.org wrote:
 oh, yes. I will add a new version :-)

 Thanks for the feedback!

 On Thu, Oct 8, 2009 at 12:50 PM, Matthias Wessendorf mat...@apache.org 
 wrote:
 the goal is not only to make it running with JSF 2.0;
 the goal is to support JSF 2.0 features w/in Trinidad.

 -Matthias

 On Thu, Oct 8, 2009 at 12:55 PM, Martin Kočí martin.k...@aura.cz wrote:
 Hi,

 I'm using trinidad with mojarra 2.0. These are steps to get trinidad
 compiled and running on JSF 2.0:

 1) Since 2.0 all method on wrappers are public. In this case it is:
 - org.apache.myfaces.trinidadinternal.application.StateManagerImpl -
 make getWrapped public
 - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make
 getWrapped - public

 Those changes are backward compatible with 1.2.


 2) Make NavigationHandlerImpl child of
 javax.faces.application.ConfigurableNavigationHandler


 3) Use javax.faces.context.ExternalContextWrapper instead of
 ExternalContextDecorator

 and make changes:
 - SessionSerializationChecker - add method getWrapped
 - XmlHttpPortletExternalContext -add method getWrapped
 - OverrideDispatch - add method getWrapped
 - ClearRequestExternalContext - add method getWrapped


 4) Use Facelets API from javax.faces instead of com.sun



 I'll create patches - can you add version 2.0 to JIRA please?


 Matthias Wessendorf píše v Čt 08. 10. 2009 v 10:24 +0200:
 Hello Andy,

 I created the experimental branch on this location:

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


 Greetings,
 Matthias


 On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz andy.g.schwa...@gmail.com 
 wrote:
  Gang -
 
  I am interested in taking a closer look at Trinidad/JSF 2.0
  integration.  I suspect that there are other folks who are interested
  in this as well.  Would it be possible to create a Trinidad branch for
  JSF 2.0-related work?  For the moment, I think that an
  experimental/sandbox-type branch that we could use for prototyping
  purposes would be helpful/would facilitate collaboration on this
  effort.
 
  Thoughts?
 
  Andy
 








 --
 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: [Trinidad] JSF 2.0

On Thu, Oct 8, 2009 at 1:33 PM, Martin Kočí martin.k...@aura.cz wrote:

 Matthias Wessendorf píše v Čt 08. 10. 2009 v 12:50 +0200:
 the goal is not only to make it running with JSF 2.0;
 the goal is to support JSF 2.0 features w/in Trinidad.

 Yes, I understand that. Right now I'm working on Resource API support -
 I'll provide some patches for #{resource['image.jpg']} etc.

cool :)



 Martin


 -Matthias

 On Thu, Oct 8, 2009 at 12:55 PM, Martin Kočí martin.k...@aura.cz wrote:
  Hi,
 
  I'm using trinidad with mojarra 2.0. These are steps to get trinidad
  compiled and running on JSF 2.0:
 
  1) Since 2.0 all method on wrappers are public. In this case it is:
  - org.apache.myfaces.trinidadinternal.application.StateManagerImpl -
  make getWrapped public
  - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make
  getWrapped - public
 
  Those changes are backward compatible with 1.2.
 
 
  2) Make NavigationHandlerImpl child of
  javax.faces.application.ConfigurableNavigationHandler
 
 
  3) Use javax.faces.context.ExternalContextWrapper instead of
  ExternalContextDecorator
 
  and make changes:
  - SessionSerializationChecker - add method getWrapped
  - XmlHttpPortletExternalContext -add method getWrapped
  - OverrideDispatch - add method getWrapped
  - ClearRequestExternalContext - add method getWrapped
 
 
  4) Use Facelets API from javax.faces instead of com.sun
 
 
 
  I'll create patches - can you add version 2.0 to JIRA please?
 
 
  Matthias Wessendorf píše v Čt 08. 10. 2009 v 10:24 +0200:
  Hello Andy,
 
  I created the experimental branch on this location:
 
  https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x
 
 
  Greetings,
  Matthias
 
 
  On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz andy.g.schwa...@gmail.com 
  wrote:
   Gang -
  
   I am interested in taking a closer look at Trinidad/JSF 2.0
   integration.  I suspect that there are other folks who are interested
   in this as well.  Would it be possible to create a Trinidad branch for
   JSF 2.0-related work?  For the moment, I think that an
   experimental/sandbox-type branch that we could use for prototyping
   purposes would be helpful/would facilitate collaboration on this
   effort.
  
   Thoughts?
  
   Andy
  
 
 
 
 
 








-- 
Matthias Wessendorf

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

TRINIDAD-1558 - NPE w/ Googlebot

Hi,

there were several issues in the past regarding exceptions w/ the
Googlebot engine.

Does one know if this:
https://issues.apache.org/jira/browse/TRINIDAD-1558

has been fixed with the recent checkins ?

Thanks!
Matthias

-- 
Matthias Wessendorf

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

Re: [VOTE] use of jul or commons logging on myfaces core 2.0

2009-10-06 Thread Matthias Wessendorf

+1 for JUL

On Sat, Oct 3, 2009 at 10:41 AM, Jan-Kees van Andel
jankeesvanan...@gmail.com wrote:
 +1 for JUL.

 Jan-Kees van Andel


 2009/10/1 Mike Kienenberger mkien...@gmail.com:
 +1 for jul -- it's not ideal, but it's the standard and doesn't
 require any dependencies.

 On Thu, Oct 1, 2009 at 12:22 PM, Grant Smith work.gr...@gmail.com wrote:
 +1 java.util.logging.Logger

 On Thu, Oct 1, 2009 at 9:14 AM, Michael Concini mconc...@gmail.com wrote:
 +1 for JUL

 Antonio Petrelli wrote:

 2009/10/1 Werner Punz werner.p...@gmail.com:


 Why don't you consider using SLF4J?
 Probably it is the same question asked over and over again, but I try
 anyway :-D



 That would be a dependency replacement with another.
 Just my personal opinion regarding SLF4J


 Don't bother, I noticed that there is a bridge with which you can use
 JUL messages with SLF4J:
 http://www.slf4j.org/legacy.html
 For a library like MyFaces makes perfectly sense.

 Antonio







 --
 Grant Smith






-- 
Matthias Wessendorf

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

Re: maven template Myfaces + Trinidad

2009-10-06 Thread Matthias Wessendorf

I think it is using this mapping...

servlet-mapping
servlet-namefaces/servlet-name
url-pattern/faces/*/url-pattern
/servlet-mapping

-Matthias

On Sun, Oct 4, 2009 at 9:11 PM, baeschtu baeschtu baesc...@gmail.com wrote:
 hello
 I tried the Myfaces + Trinidad maven template from
 http://wiki.apache.org/myfaces/MyFaces_Archetypes_for_Maven

 mvn archetype:generate -DarchetypeCatalog=http://myfaces.apache.org

 with option 5

 and got an

 java.lang.RuntimeException: FacesContext not found

 when trying to access index.jspx or index.jsf






-- 
Matthias Wessendorf

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

Re: [Trinidad] Build Broken?

2009-10-05 Thread Matthias Wessendorf

Hi Catalin,

can you take a look ?

Thx,
Matthias

On Tue, Oct 6, 2009 at 1:27 AM, Jeanne Waldman
jeanne.wald...@oracle.com wrote:
 This checkin broke the golden files. ckormos, do you mind taking a look?
 Thanks,
 Jeanne
 Revision: 820104
 Author: ckormos
 Date: 2:59:10 PM, Tuesday, September 29, 2009
 Message:
 fix for [TRINIDAD-1520] - NPE from Google Bot (unknown agent) - by default,
 the properties of AgentImpl initialized with unknown values.
 
 Modified :
 /myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/context/Agent.java
 Modified :
 /myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/agent/AgentFactoryImpl.java
 Modified :
 /myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/agent/AgentImpl.java



 Jeanne Waldman wrote, On 10/5/2009 11:06 AM PT:

 I also see:
     label
  class=p_OraHiddenLabel
  for=mainId
     
   test-shortDesc
     /label
 is removed.

 The common denominator is that all the test-failures are in the IE tests.
 I don't see any checkins where this would have obviously caused this
 failure.

 Jeanne Waldman wrote, On 10/5/2009 10:56 AM PT:

 I see the same thing. It seems the change was:
 onload=_checkLoad
 onload=_checkLoadNoPPR()

 Mamallan Uthaman wrote, On 10/1/2009 6:39 PM PT:

 Hi,

 I am getting golden-file mismatch errors (refer below) while building the
 Trinidad trunk. is the build broken?
 Tests run: 821, Failures: 106, Errors: 0, Skipped: 0

 Branch-1.2.12.2 build seems ok.

 Thanks
 Mamallan



-- 
Matthias Wessendorf

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

Re: JSR 299 - being outside of JAvaEE 6 container

On Wed, Sep 16, 2009 at 9:49 PM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
 Actually we are more than this. We can use embeddable OpenEJB in Tomcat with 
 OWB.

which is cool. The more blog entries, the better ;-)

Greetings,
Matthias



 --Gurkan


 
 From: Matthias Wessendorf mat...@apache.org
 To: openwebbeans-dev@incubator.apache.org
 Sent: Wednesday, September 16, 2009 6:09:57 PM
 Subject: JSR 299 - being outside of JAvaEE 6 container

 Hi,

 WebBeans - the RI for 299 - has this:
 http://seamframework.org/Community/WebBeansAndTomcat

 we do have similar, but I didn't find a wiki or so, on it :-)
 (or a blog post)

 Is there some documentation on it ?

 -Matthias

 --
 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][RESULT] Release OpenWebBeans M3

On Thu, Sep 17, 2009 at 10:25 AM, Niall Pemberton
niall.pember...@gmail.com wrote:
 On Thu, Sep 17, 2009 at 3:01 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com 
 wrote:
 Hi Niall;

The usual process is to allow 72hrs for a vote and not just declare it
when 3 votes are received. Also Sebb raised an issue and IMO its good
etiquette to allow discussions to run their course before declaring a
vote.

Votes should generally be permitted to run for at least 72 hours to
provide an opportunity for all concerned persons to participate
regardless of their geographic locations.
from http://www.apache.org/foundation/voting.html

 I have already know those rules!.

 Then I'm surprised you chose to do something different and IMO
 impatience isn't a good enough reason.

same here


 Besides, I was a bit of rush because of waiting too much to release :) 
 Otherwise we were not able to release something that our community uses!

Also Sebb raised an issue and IMO its good
etiquette to allow discussions to run their course before declaring a
vote.

 I responded Sebb explanations. I thought that it may not block this release!

 Sebb indicated that he thought that one of the points he raised was a
 blocker and although you responded you didn't allow time to see if he
 agreed with you. Giving a response is not reaching consensus.
 Sometimes you don't end up agreeing, but you need to allow time to see
 if its possible.

 Niall

 If possible I would like to apply Sebb's concerns in next M4 release that we 
 will try to be perfect :)

 Thanks;

 --Gurkan


 
 From: Niall Pemberton niall.pember...@gmail.com
 To: general@incubator.apache.org
 Sent: Thursday, September 17, 2009 2:26:57 AM
 Subject: Re: [VOTE][RESULT] Release OpenWebBeans M3

 On Wed, Sep 16, 2009 at 10:30 PM, Gurkan Erdogdu
 cgurkanerdo...@gmail.com wrote:
 Hi;

 The [VOTE] is now closed. The [VOTE] to release OpenWebBeans-M3 is
 successful.

 There are three +1 binding

 The usual process is to allow 72hrs for a vote and not just declare it
 when 3 votes are received. Also Sebb raised an issue and IMO its good
 etiquette to allow discussions to run their course before declaring a
 vote.

 Votes should generally be permitted to run for at least 72 hours to
 provide an opportunity for all concerned persons to participate
 regardless of their geographic locations.
 from http://www.apache.org/foundation/voting.html

 The community then tries to gather consensus on an alternative
 proposal that resolves the issue. In the great majority of cases, the
 concerns leading to the negative vote can be addressed.
 from http://www.apache.org/foundation/how-it-works.html#decision-making

 Niall

 +1 Votes
 -
 * Kevan Miller (binding)
 * Matthias Wessendorf (binding)
 * Niall Pemberton (binding)


 I will add distribution artifacts to the  incubator dist/  place and
 upload to m3-incubator-repository

 Thanks to all;

 -- Gurkan


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org





-- 
Matthias Wessendorf

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

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE][RESULT] Release OpenWebBeans M3

On Thu, Sep 17, 2009 at 4:01 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
 Hi Niall;

The usual process is to allow 72hrs for a vote and not just declare it
when 3 votes are received. Also Sebb raised an issue and IMO its good
etiquette to allow discussions to run their course before declaring a
vote.

Votes should generally be permitted to run for at least 72 hours to
provide an opportunity for all concerned persons to participate
regardless of their geographic locations.
from http://www.apache.org/foundation/voting.html

 I have already know those rules!.

 Besides, I was a bit of rush because of waiting too much to release :) 
 Otherwise we were not able to release something that our community uses!

on goal of incubation is also to LEARN the Apache rules, not only to
produce code. As the main focus is to attract this podling to new
developers, there is no need to rush on providing a release for
use-only users. We want committers. These should be able to get the
svn TAG and work on that...



Also Sebb raised an issue and IMO its good
etiquette to allow discussions to run their course before declaring a
vote.

 I responded Sebb explanations. I thought that it may not block this release!

 If possible I would like to apply Sebb's concerns in next M4 release that we 
 will try to be perfect :)

not sure what exactly he said, but please file a JIRA ticket for it,
to not forget about it.

-Matthias



 Thanks;

 --Gurkan


 
 From: Niall Pemberton niall.pember...@gmail.com
 To: general@incubator.apache.org
 Sent: Thursday, September 17, 2009 2:26:57 AM
 Subject: Re: [VOTE][RESULT] Release OpenWebBeans M3

 On Wed, Sep 16, 2009 at 10:30 PM, Gurkan Erdogdu
 cgurkanerdo...@gmail.com wrote:
 Hi;

 The [VOTE] is now closed. The [VOTE] to release OpenWebBeans-M3 is
 successful.

 There are three +1 binding

 The usual process is to allow 72hrs for a vote and not just declare it
 when 3 votes are received. Also Sebb raised an issue and IMO its good
 etiquette to allow discussions to run their course before declaring a
 vote.

 Votes should generally be permitted to run for at least 72 hours to
 provide an opportunity for all concerned persons to participate
 regardless of their geographic locations.
 from http://www.apache.org/foundation/voting.html

 The community then tries to gather consensus on an alternative
 proposal that resolves the issue. In the great majority of cases, the
 concerns leading to the negative vote can be addressed.
 from http://www.apache.org/foundation/how-it-works.html#decision-making

 Niall

 +1 Votes
 -
 * Kevan Miller (binding)
 * Matthias Wessendorf (binding)
 * Niall Pemberton (binding)


 I will add distribution artifacts to the  incubator dist/  place and
 upload to m3-incubator-repository

 Thanks to all;

 -- Gurkan


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org






-- 
Matthias Wessendorf

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

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE][RESULT] Release OpenWebBeans M3

On Thu, Sep 17, 2009 at 10:25 AM, Niall Pemberton
niall.pember...@gmail.com wrote:
 On Thu, Sep 17, 2009 at 3:01 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com 
 wrote:
 Hi Niall;

The usual process is to allow 72hrs for a vote and not just declare it
when 3 votes are received. Also Sebb raised an issue and IMO its good
etiquette to allow discussions to run their course before declaring a
vote.

Votes should generally be permitted to run for at least 72 hours to
provide an opportunity for all concerned persons to participate
regardless of their geographic locations.
from http://www.apache.org/foundation/voting.html

 I have already know those rules!.

 Then I'm surprised you chose to do something different and IMO
 impatience isn't a good enough reason.

 Besides, I was a bit of rush because of waiting too much to release :) 
 Otherwise we were not able to release something that our community uses!

Also Sebb raised an issue and IMO its good
etiquette to allow discussions to run their course before declaring a
vote.

 I responded Sebb explanations. I thought that it may not block this release!

 Sebb indicated that he thought that one of the points he raised was a
 blocker and although you responded you didn't allow time to see if he
 agreed with you. Giving a response is not reaching consensus.
 Sometimes you don't end up agreeing, but you need to allow time to see
 if its possible.

I totally agree, that rushing is not a good practice. Thanks Niall for
jumping in.

-Matthias



 Niall

 If possible I would like to apply Sebb's concerns in next M4 release that we 
 will try to be perfect :)

 Thanks;

 --Gurkan


 
 From: Niall Pemberton niall.pember...@gmail.com
 To: general@incubator.apache.org
 Sent: Thursday, September 17, 2009 2:26:57 AM
 Subject: Re: [VOTE][RESULT] Release OpenWebBeans M3

 On Wed, Sep 16, 2009 at 10:30 PM, Gurkan Erdogdu
 cgurkanerdo...@gmail.com wrote:
 Hi;

 The [VOTE] is now closed. The [VOTE] to release OpenWebBeans-M3 is
 successful.

 There are three +1 binding

 The usual process is to allow 72hrs for a vote and not just declare it
 when 3 votes are received. Also Sebb raised an issue and IMO its good
 etiquette to allow discussions to run their course before declaring a
 vote.

 Votes should generally be permitted to run for at least 72 hours to
 provide an opportunity for all concerned persons to participate
 regardless of their geographic locations.
 from http://www.apache.org/foundation/voting.html

 The community then tries to gather consensus on an alternative
 proposal that resolves the issue. In the great majority of cases, the
 concerns leading to the negative vote can be addressed.
 from http://www.apache.org/foundation/how-it-works.html#decision-making

 Niall

 +1 Votes
 -
 * Kevan Miller (binding)
 * Matthias Wessendorf (binding)
 * Niall Pemberton (binding)


 I will add distribution artifacts to the  incubator dist/  place and
 upload to m3-incubator-repository

 Thanks to all;

 -- Gurkan


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org





-- 
Matthias Wessendorf

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

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [ANNOOUNCE] Welcome David Blevins as a new OpenWebBeans Committer

2009-09-16 Thread Matthias Wessendorf

Welcome aboard, David!

great to have you here-

-M

On Tue, Sep 15, 2009 at 10:07 PM, David Blevins david.blev...@visi.com wrote:
 Thanks All!  Great little community here.

 -David

 On Sep 14, 2009, at 4:54 PM, Kevan Miller wrote:

 All,
 The Apache OpenWebBeans PMC is pleased to announce that David Blevins has
 accepted our invitation to become an OpenWebBeans committer.

 It's great to have David joining our project. Welcome David!

 --kevan






-- 
Matthias Wessendorf

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

Re: JSR 299 - being outside of JAvaEE 6 container

2009-09-16 Thread Matthias Wessendorf

On Wed, Sep 16, 2009 at 5:37 PM, Mark Struberg strub...@yahoo.de wrote:
 You are right, we are actually pretty bad at selling our selfs ;)

 but you may run our guess sample with jetty + MyFaces (currently 1.2) with

 $ mvn -Pjetty clean package jetty:run

I know. Used it already on a JSF2.0 talk :-)


 We could perhaps also move over to the JSF-2 branch of MyFaces.

+1 :)



 LieGrue,
 strub

 --- On Wed, 9/16/09, Matthias Wessendorf mat...@apache.org wrote:

 From: Matthias Wessendorf mat...@apache.org
 Subject: JSR 299 - being outside of JAvaEE 6 container
 To: openwebbeans-dev@incubator.apache.org
 Date: Wednesday, September 16, 2009, 5:09 PM
 Hi,

 WebBeans - the RI for 299 - has this:
 http://seamframework.org/Community/WebBeansAndTomcat

 we do have similar, but I didn't find a wiki or so, on it
 :-)
 (or a blog post)

 Is there some documentation on it ?

 -Matthias

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

2009-09-16 Thread Matthias Wessendorf

find information on howto unsubscribe:

http://myfaces.apache.org/mail-lists.html

2009/9/16 Carsten Kaiser carsten.kai...@valtech.de:
 --
 Carsten Kaiser
 Principal Consultant
 mailto:carsten.kai...@valtech.de
 Mobile: +49 170 5270206

 Valtech GmbH
 Werner-Heisenberg-Straße 2
 63263 Neu-Isenburg
 Germany

 Phone: +49 6102 88468-0
 Fax: +49 6102 88468-28

 http://www.valtech.de

 Geschäftsführer: Ingo Kriescher
 Amtsgericht Düsseldorf HRB48672




-- 
Matthias Wessendorf

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

Re: [TRINIDAD] character encoding issue with 1.0.11

2009-09-15 Thread Matthias Wessendorf

On Tue, Sep 15, 2009 at 8:10 AM, Paul Mander paul.s.man...@gmail.com wrote:

Thanks a lot Mamallan. That solved it.

I wonder why the 1.0 branch is so out of step with the 1.2 branch (trunk)

A while ago, we decided to focused on JSF 1.2, instead of 1.1.
Most of the fixes over last year went into both. But some of them
(including all new features) were only add to 1.2. version of Trinidad

Our goal is really to motivate users to update to JSF 1.2, or JSF 2.0
once that specification is available.

However, we can backport the TRINIDAD-1430 to 1.0.x version of Trinidad.
do you mind to create a JIRA ticket for that ? The next release(s) of Trinidad
1.0.x are only maintenance releases, but there will be some.

Thanks!
Matthias

Mamallan Uthaman wrote:

Hi Paul,

Do you get any exception in the server log? I guess this could be due
to Trinidad-1430.

Thanks
Mamallan

Paul Mander wrote:
We've recently upgraded from 1.0.7 to 1.0.11 and found that we now cannot
enter Turkish characters into forms whereas before we didn't have any
problem in this area. I have narrowed this down to 1.0.10 which was the
last
release when it worked.

The problem arises when entering YURTİÇİ which contains the problem
characters. The page bean receives these in a garbled format using 1.0.11
(fine with 1.0.10).

Looking through the release note all I can see that touches anything
relating to this is https://issues.apache.org/jira/browse/TRINIDAD-974.
It
mentioned in the comments about setting encoding levels for these jspx
files. I have tried

?xml version=1.0 encoding=ISO-8859-9? (Turkish)
?xml version=1.0 encoding=UTF-8?

but they don't work. Interestingly they do garble the input is a
different
way.

Has anyone got any ideas about this. It is extremely urgent that we get
this
fixed as soon as possible.

--
View this message in context:
http://www.nabble.com/-TRINIDAD--character-encoding-issue-with-1.0.11-tp25436068p25448505.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.

--
Matthias Wessendorf

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

Re: [TRINIDAD] character encoding issue with 1.0.11

2009-09-15 Thread Matthias Wessendorf

On Tue, Sep 15, 2009 at 8:55 AM, Paul Mander paul.s.man...@gmail.com wrote:

I'd love to move off 1.1 but we are stuck with WebSphere 6.1. The following
discusses how you can get WAS 6.1 to work with JSF 1.2 but it involves too
much change which will break existing applications.

http://www.denoo.info/2008/02/finally-jsf-12-and-facelets-on-websphere-61/

I do most of my work with large banks and they just don't move that quickly
I'm afraid.

I understand that, we (the MyFaces community) has no problem in (kinda)
continuing the Trinidad 1.0.x stuff, therefore I asked to create a
ticket to back-port
the stuff ;-) I also know that you need the other fix, from the
testing release thread.
Still on my long list.

-Matthias

Matthias Wessendorf-4 wrote:

On Tue, Sep 15, 2009 at 8:10 AM, Paul Mander paul.s.man...@gmail.com
wrote:

Thanks a lot Mamallan. That solved it.

I wonder why the 1.0 branch is so out of step with the 1.2 branch (trunk)

A while ago, we decided to focused on JSF 1.2, instead of 1.1.
Most of the fixes over last year went into both. But some of them
(including all new features) were only add to 1.2. version of Trinidad

Our goal is really to motivate users to update to JSF 1.2, or JSF 2.0
once that specification is available.

However, we can backport the TRINIDAD-1430 to 1.0.x version of Trinidad.
do you mind to create a JIRA ticket for that ? The next release(s) of
Trinidad
1.0.x are only maintenance releases, but there will be some.

Thanks!
Matthias

Mamallan Uthaman wrote:

Hi Paul,

Do you get any exception in the server log? I guess this could be due
to Trinidad-1430.

Thanks
Mamallan

Paul Mander wrote:
We've recently upgraded from 1.0.7 to 1.0.11 and found that we now
cannot
enter Turkish characters into forms whereas before we didn't have any
problem in this area. I have narrowed this down to 1.0.10 which was the
last
release when it worked.

The problem arises when entering YURTİÇİ which contains the problem
characters. The page bean receives these in a garbled format using
1.0.11
(fine with 1.0.10).

?xml version=1.0 encoding=ISO-8859-9? (Turkish)
?xml version=1.0 encoding=UTF-8?

but they don't work. Interestingly they do garble the input is a
different
way.

Has anyone got any ideas about this. It is extremely urgent that we get
this
fixed as soon as possible.

--
View this message in context:
http://www.nabble.com/-TRINIDAD--character-encoding-issue-with-1.0.11-tp25436068p25448505.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.

--
Matthias Wessendorf

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

--
View this message in context:
http://www.nabble.com/-TRINIDAD--character-encoding-issue-with-1.0.11-tp25436068p25448927.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.

--
Matthias Wessendorf

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

Re: [VOTE] Accept Aries proposal for incubation

2009-09-15 Thread Matthias Wessendorf

 draft of OSGi v4.2 core and compendium specifications - which
 includes the Blueprint container specification - is available at:
 http://www.osgi.org/download/osgi-4.2-early-draft3.pdf

 Initial Source

     * The Blueprint container impl from the Geronimo sandbox will be
 moved to the Aries project for further development:
 http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint
     * IBM will also contribute code for:
           o container-managed JPA support in an OSGi environment.
           o making OSGi services visible to Java EE components through
  JNDI. o packaging web components as bundles and a URL handler for
  recognizing and converting non-bundled Web components
     * We will also be soliciting implementations of other OSGi
 enterprise application-centric specifications.

 External Dependencies

     * Apache Ant http://ant.apache.org Apache License
     * Apache Commons http://commons.apache.org Apache License
     * Junit (Java unit test framework) http://junit.sourceforge.net
 CPL v1.0 license: http://junit.sourceforge.net/cpl-v10.html
     * Apache Felix (implementation of the OSGi Core and Compendium
 specifications - compliance level unknown) http://felix.apache.org
 Apache License (hosted by ASF).
     * Eclipse Equinox (compliant implementation of the OSGi Core
 Specification and Compendium specifications)
 http://eclipse.org/equinox/ Eclipse Public License
     * OpenJPA http://openjpa.apache.org Apache License
     * Serp http://serp.sourceforge.net/ BSD
     * Apache Geronimo http://geronimo.apache.org Apache License

 Required Resources
 Mailing lists

 aries-private (with moderated subscriptions)

 aries-dev

 aries-commits

 aries-user

 Subversion Directory

 http://svn.apache.org/repos/asf/incubator/aries

 Issue Tracking

 JIRA (ARIES)

 Web Site

 Confluence (Aries)

 Initial Committers

 Names of initial committers with affiliation and current ASF status:

     * Alan Cabrera (LinkedIn, ASF Member)
     * Alasdair Nottingham (IBM)
     * Andrew Osborne (IBM)
     * Bernd Kolb (SAP)
     * Carsten Ziegeler (Individual, ASF member)
     * Dan Kulp (Progress, ASF member)
     * David Bosschaert (Progress, ASF committer)
     * David Jencks (IBM, ASF member)
     * Dimo Stoilov (SAP)
     * Eoghan Glynn (Progress, ASF committer)
     * Graham Charters (IBM)
     * Guillaume Nodet (Progress, ASF member)
     * Hiram Chirino (Progress, ASF member)
     * Ian Robinson (IBM)
     * James Strachan (Progress, ASF member)
     * Jarek Gawor (IBM, ASF member)
     * Jean-Sebastien Delfino (IBM, ASF committer)
     * Jeremy Hughes (IBM, ASF committer)
     * Joe Bohn (IBM, ASF committer)
     * Lin Sun (IBM, ASF committer)
     * Kiril Mitov (SAP)
     * Mark Nuttall (IBM)
     * Niklas Gustavsson (individual, ASF committer)
     * Nikolai Tankov (SAP)
     * Oisin Hurley (Progress)
     * Peter Peshev (SAP)
     * Raymond Feng (IBM, ASF committer)
     * Rick McGuire (IBM, ASF committer)
     * Roman Roelofsen (ProSyst)
     * Sabine Heider (SAP)
     * Sergey Beryozkin (Progress, ASF committer)
     * Stuart McCulloch (individual, ASF committer)
     * Timothy Ward (IBM)
     * Todor Boev (ProSyst)
     * Valentin Mahrwald (IBM)
     * Violeta Georgieva (SAP)
     * Zoe Slattery (IBM)

 Affiliations

 The majority of the initial committers listed on the proposal
 initially are employed by IBM corp or Progress Software. One objective
 of the incubator is to attract a diverse community of contributors and
 we anticipate future contributors to have other affiliations. Indeed,
 since the proposal was initially posted, further initial committers
 have volunteered from SAP, ProSyst, LinkedIn and some individuals.

 Sponsors
 Champions

 Kevan Miller, Guillaume Nodet

 Nominated Mentors

 Guillaume Nodet, Davanum Srinivas (Dims), Kevan Miller

 Sponsoring Entity

 The incubator. Successful graduation from Incubator should result in
 Aries becoming a new TLP.

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


 --
 Daniel Kulp
 dk...@apache.org
 http://www.dankulp.com/blog

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org





-- 
Matthias Wessendorf

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

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Graduation?

2009-09-11 Thread Matthias Wessendorf

On Wed, Sep 9, 2009 at 7:54 PM, Kevan Miller kevan.mil...@gmail.com wrote:

 On Sep 9, 2009, at 12:26 PM, Mark Struberg wrote:

 Sorry for repeating myself: I think we should wait for the 330 and 299
 specs to settle, and THEN we can decide what to do. I feel uncomfortable
 with being promoted from incubator without having the API pretty stable.

 Once this point is reached, I look pretty confident that OWB will find a
 well established place in the community.

 I understand that point.

 Personally, I think I've been guilty of allowing spec instabilities to
 affect my judgement on community readiness (or at least affecting how much I
 pushed the community to consider graduation). IMO, I think that was wrong. I
 should not be allowing external factors to be affecting my community
 evaluation.

 There is certainly an indirect effect of spec resolution -- as spec issues
 are resolved, hopefully we'll see an increase in users and more projects
 interested in participating. This could happen pre or post graduation...

+1


 --kevan




-- 
Matthias Wessendorf

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

Re: [Trinidad] Possible patch for [Trindad-1397]

2009-09-11 Thread Matthias Wessendorf

can you upload a diff file ?

On Fri, Sep 11, 2009 at 1:05 PM, Elmar Kretzer elm4w...@googlemail.com wrote:
 Hi,
 i got a question concerning a possible patch for
 https://issues.apache.org/jira/browse/TRINIDAD-1397.

 The issue is, that the SelectManyShuttleRenderer uses
 rc.setSkinResourceKeyMap(getResourceKeyMap()); to render the
  SelectManyShuttle styleClasses.
 But at the end of encodeElementContent() the skinResourceKeyMap gets
 not cleared.

 Therefore a panelBox containing a selectManyShuttle gets corrupted 
 styleClasses.

 I could provided a possible patch for this issue, but honestly i don`t
 know how to do this.
 So could anyone advice me?

 thx
 elmar

 Patch Information:

 file 
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SelectManyShuttleRenderer

 Line 293:

    change:
    rc.setSkinResourceKeyMap(getResourceKeyMap());

    to:
   MapString, String originalSkinResourceMap = rc.getSkinResourceKeyMap();
    rc.setSkinResourceKeyMap(getResourceKeyMap());

 Line 326:

   change:
   _clearContext(rc);

  to:
  rc.setSkinResourceKeyMap(originalSkinResourceMap);
  _clearContext(rc);




-- 
Matthias Wessendorf

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

Re: [Trinidad] Possible patch for [Trindad-1397]

2009-09-11 Thread Matthias Wessendorf

https://issues.apache.org/jira/browse/TRINIDAD-1397

Operations

= Attach file

On Fri, Sep 11, 2009 at 1:12 PM, Elmar Kretzer elm4w...@googlemail.com wrote:
 Hi Matthias,

 of course - but i haven`t done this yet.
 can you give me link with a how to?


 elmar

 2009/9/11 Matthias Wessendorf mat...@apache.org:
 can you upload a diff file ?

 On Fri, Sep 11, 2009 at 1:05 PM, Elmar Kretzer elm4w...@googlemail.com 
 wrote:
 Hi,
 i got a question concerning a possible patch for
 https://issues.apache.org/jira/browse/TRINIDAD-1397.

 The issue is, that the SelectManyShuttleRenderer uses
 rc.setSkinResourceKeyMap(getResourceKeyMap()); to render the
  SelectManyShuttle styleClasses.
 But at the end of encodeElementContent() the skinResourceKeyMap gets
 not cleared.

 Therefore a panelBox containing a selectManyShuttle gets corrupted 
 styleClasses.

 I could provided a possible patch for this issue, but honestly i don`t
 know how to do this.
 So could anyone advice me?

 thx
 elmar

 Patch Information:

 file 
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SelectManyShuttleRenderer

 Line 293:

    change:
    rc.setSkinResourceKeyMap(getResourceKeyMap());

    to:
   MapString, String originalSkinResourceMap = rc.getSkinResourceKeyMap();
    rc.setSkinResourceKeyMap(getResourceKeyMap());

 Line 326:

   change:
   _clearContext(rc);

  to:
  rc.setSkinResourceKeyMap(originalSkinResourceMap);
  _clearContext(rc);




 --
 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: Graduation?

+1 on the graduation - I agree with Kevan, that this (little)
community is on the right way.

Instead of being a sub-project, I'd vote to have OWB becoming a TLP.
One reason is that by being standalone it is easier to ensure the project is
tied to closely to Geronimo, which makes distribution on other
containers easier.

-Matthias

On Wed, Sep 9, 2009 at 2:11 AM, Mohammad Nour
El-Dinnour.moham...@gmail.com wrote:
 -1

 Allow me to disagree with you Gurkan, IMHO I think OWN should be a TLP
 project. I know it is to some extent related to JEE but IMO it defines
 a generic and extensible model for dependency injection and contextual
 programming which is not restricted to JEE, so being a sub-project to
 Geronimo will give the community users the impression that we only
 support JEE. I think we should follow the model of Tomcat and OpenEJB,
 which is a separate TLP and being integrable with other ASF projects
 like Geronimo for example.

 And for the communit, being a separate TLP will not be affected and we
 could get more contributers and committers and a big example on that
 is DBlevins.

 On Tue, Sep 8, 2009 at 8:30 PM, Mark Strubergstrub...@yahoo.de wrote:
 +1

 LieGrue,
 strub

 --- On Tue, 9/8/09, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:

 From: Gurkan Erdogdu gurkanerdo...@yahoo.com
 Subject: Re: Graduation?
 To: openwebbeans-dev@incubator.apache.org
 Date: Tuesday, September 8, 2009, 8:23 PM
 Hi Kevan;

 Firstly its very good news for us!

 I personally think that we can continue to implement OWB as
 a sub-project under Geronimo.  Geronimo has a stable
 community so we can also benefit from its diverse community
 and its reputation. Moreover, it ease the integration OWB
 with other Geronimo modules like EJB, JSF etc.

 So this is my +1 as it is a sub-project under Geronimo.

 --Gurkan




 
 From: Kevan Miller kevan.mil...@gmail.com
 To: openwebbeans-dev@incubator.apache.org
 Sent: Tuesday, September 8, 2009 6:00:44 PM
 Subject: Graduation?

 All,
 I wanted to checkpoint with the community about their
 thoughts regarding Incubator Graduation. I don't want the
 community to be too focused on implementation issues and
 forget about an important goal -- getting you out of the
 Apache Incubator!

 IMO, this community displays nearly all of the
 characteristics that I would look for from a successful
 Incubator project: you've successfully created several
 releases while operating in a clear, open, and welcoming
 manner. All of this while facing some significant challenges
 as the JSR 299 spec has been an ever shifting target.

 I'd like to see us moving towards graduation. To start
 things off, is the community interested in becoming a
 top-level project? Or would you rather graduate as a
 sub-project of an existing TLP?

 --kevan










 --
 Thanks
 - Mohammad Nour
 - LinkedIn: http://www.linkedin.com/in/mnour
 
 Life is like riding a bicycle. To keep your balance you must keep moving
 - Albert Einstein




-- 
Matthias Wessendorf

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

JSR 299 / 330

http://weblogs.java.net/blog/rogerk/archive/2009/09/04/contexts-and-dependency-injection-jsr-299-and-glassfish

-- 
Matthias Wessendorf

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

Re: JSR 299 / 330

+1 that would be cool!

On Wed, Sep 9, 2009 at 12:58 PM, Gurkan Erdogducgurkanerdo...@gmail.com wrote:
 Actually we can also blogs/posts/examples. We got very good 2 examples
 related with JSF.

 --Gurkan

 2009/9/9 Matthias Wessendorf mat...@apache.org


 http://weblogs.java.net/blog/rogerk/archive/2009/09/04/contexts-and-dependency-injection-jsr-299-and-glassfish

 --
 Matthias Wessendorf

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




 --
 Gurkan Erdogdu
 http://gurkanerdogdu.blogspot.com




-- 
Matthias Wessendorf

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

Re: About Podling Releases

hey Gurkan,

don't worry that much about the user-base. It will grow.
You guys are implementing a pretty new JSR. Once that is used more and
more in the industry,
the users will come to your project.

-Matthias


On Wed, Sep 9, 2009 at 7:09 PM, Gurkan Erdogdugurkanerdo...@yahoo.com wrote:
 Hi Bertrand;

What's preventing OpenWebBeans from graduating?
That's the best way of streamlining your release process.
 Actually this is ongoing discussion in the openwebbeans dev list. There are 
 two solutions here, sub-project under Geronimo or TLP. But community are 
 voted on being a TLP. The problem is that we have not a solid user base (not 
 so much activity around u...@.. list). Otherwise, I think that we achieved 
 activitites that are expected from podlings to graduate as a TLP.

On a tangential note, I'm not sure what you mean by internal
milestones - if those are just meant for OpenWebBeans developers, SVN
tags might be good enough.
 I mean actual podling releases, not SVN tags. For example, we released M1 and 
 M2. Now M3 is under VOTE.

 --Gurkan




 
 From: Bertrand Delacretaz bdelacre...@apache.org
 To: general@incubator.apache.org
 Sent: Wednesday, September 9, 2009 10:42:35 AM
 Subject: Re: About Podling Releases

 Hi Gurkan,

 On Tue, Sep 8, 2009 at 12:30 PM, Gurkan Erdogducgurkanerdo...@gmail.com 
 wrote:
 ...As an experienced podling releaser guy from the OpenWebBeans podling , it
 takes too much days to release internal milestones of the project

 What's preventing OpenWebBeans from graduating?
 That's the best way of streamlining your release process.

 I had a look at the latest report at
 http://wiki.apache.org/incubator/September2009, but it doesn't mention
 the top 2 or 3 things to resolve prior to graduation, what are
 those?

 On a tangential note, I'm not sure what you mean by internal
 milestones - if those are just meant for OpenWebBeans developers, SVN
 tags might be good enough.

 -Bertrand

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org






-- 
Matthias Wessendorf

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

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VALIDATOR] Proposal for a JSR-303 Bean Validation Implementation

2009-09-08 Thread Matthias Wessendorf

On Fri, Sep 4, 2009 at 10:39 PM, Mohammad Nour
El-Dinnour.moham...@gmail.com wrote:
 I support either solution 1 or 2 from first section of solutions:

 1- We will not be waiting for others till they decide whether donate
 the code or not.

RH donation will not happen - we could fork, the license is just fine for it.
But yeah, why forking a RI ? :-)

I like the incubator style a little bit better than the commons sandbox.


 2- We will get more benefit for ASF as we may gain more committer to
 join the community and help grow it more.

 3- For the non-committers contribution to the code, I think it is not
 a problem as it is the normal case for ASF projects, these
 contributions make us gain more committers in the future and hence
 more support for ASF.

 On Fri, Sep 4, 2009 at 5:37 PM, Donald Woodsdwo...@apache.org wrote:
 Everyone, I think it is time again to reopen the discussions around creating
 a Validator2 release [1], which implements the upcoming JSR-303 Bean
 Validation spec [2] and [3].  Since JSR-303 is now a required component of
 Java EE 6 application servers and must be supported by JSR-314 JSF2 and
 JSR-317 JPA2, there is growing interest in the Apache Geronimo, Apache
 OpenJPA, Apache MyFaces and Apache OpenEJB projects to grow and maintain a
 JSR-303 implementation at Apache.

 First, to meet this goal, I would like us to consider the following options:

 I. - Commons Sandbox
 Utilize the existing validator2 sandbox area [4] to collaborate on a JSR-303
 implementation which would eventually become commons-validator-2.0.
 Pros:  Existing Apache committers can be given access to the sandbox and
 work with the Commons community to become committers.
 Cons:  Non-committers must provide patches and build karma, even before the
 project is moved out of the sandbox (we have interest from two companies to
 help, but most of their potential contributors are not Apache committers.)

 II. - Apache Incubator
 Submit an incubator proposal to create a JSR-303 focused project, which
 would be sponsored by the Commons PMC and/or Geronimo PMC with the goal
 being that the candidate proposal would become a sub-project of Commons as
 the new Validator R2 code base.
 Pros:  Allows us to seed the initial project with non-committers and
 demonstrate there is broad support for this project.
 Cons:  Additional incubator proposal and graduation overhead, along with not
 working closely with the whole Commons community on developing the new code
 base.


 Secondly, we have two existing JSR-303 implementations that we could
 possibly use to help bootstrap this effort:

 I. - Agimatec-Validation project on Google Code
 Code uses ASL 2.0 and I have approached one of the Agimatec GmbH employees
 about possibly donating the existing code to Apache.

 II. - JSR-303 RI
 Code being developed by Red Hat as the RI using ASL 2.0.  Kevin Sutter from
 the OpenJPA team has approached Emmanuel at Red Hat on this subject, but it
 is doubtful we would see a code donation, but could pull it in as
 third-party code to get started.


 Please let me know your thoughts, as we would like to get this bootstrapped
 this month, as the Geronimo community is starting to put together our plans
 for a Geronimo 3.0 release in 2010 for a Java EE 6 application server.


 -Donald Woods
 Apache Geronimo Committer and PMC member
 Apache OpenJPA Committer and PMC member
 dwoods.AT.apache.org


 [1] https://issues.apache.org/jira/browse/VALIDATOR-279

 [2] http://jcp.org/en/jsr/detail?id=303

 [3] http://people.redhat.com/~ebernard/validation/

 [4] https://svn.apache.org/repos/asf/commons/sandbox/validator2/trunk





 --
 Thanks
 - Mohammad Nour
 - LinkedIn: http://www.linkedin.com/in/mnour
 
 Life is like riding a bicycle. To keep your balance you must keep moving
 - Albert Einstein

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org





-- 
Matthias Wessendorf

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

Re: [VALIDATOR] Proposal for a JSR-303 Bean Validation Implementation

2009-09-08 Thread Matthias Wessendorf

On Fri, Sep 4, 2009 at 10:39 PM, Mohammad Nour
El-Dinnour.moham...@gmail.com wrote:
 I support either solution 1 or 2 from first section of solutions:

 1- We will not be waiting for others till they decide whether donate
 the code or not.

RH donation will not happen - we could fork, the license is just fine for it.
But yeah, why forking a RI ? :-)

I like the incubator style a little bit better than the commons sandbox.


 2- We will get more benefit for ASF as we may gain more committer to
 join the community and help grow it more.

 3- For the non-committers contribution to the code, I think it is not
 a problem as it is the normal case for ASF projects, these
 contributions make us gain more committers in the future and hence
 more support for ASF.

 On Fri, Sep 4, 2009 at 5:37 PM, Donald Woodsdwo...@apache.org wrote:
 Everyone, I think it is time again to reopen the discussions around creating
 a Validator2 release [1], which implements the upcoming JSR-303 Bean
 Validation spec [2] and [3].  Since JSR-303 is now a required component of
 Java EE 6 application servers and must be supported by JSR-314 JSF2 and
 JSR-317 JPA2, there is growing interest in the Apache Geronimo, Apache
 OpenJPA, Apache MyFaces and Apache OpenEJB projects to grow and maintain a
 JSR-303 implementation at Apache.

 First, to meet this goal, I would like us to consider the following options:

 I. - Commons Sandbox
 Utilize the existing validator2 sandbox area [4] to collaborate on a JSR-303
 implementation which would eventually become commons-validator-2.0.
 Pros:  Existing Apache committers can be given access to the sandbox and
 work with the Commons community to become committers.
 Cons:  Non-committers must provide patches and build karma, even before the
 project is moved out of the sandbox (we have interest from two companies to
 help, but most of their potential contributors are not Apache committers.)

 II. - Apache Incubator
 Submit an incubator proposal to create a JSR-303 focused project, which
 would be sponsored by the Commons PMC and/or Geronimo PMC with the goal
 being that the candidate proposal would become a sub-project of Commons as
 the new Validator R2 code base.
 Pros:  Allows us to seed the initial project with non-committers and
 demonstrate there is broad support for this project.
 Cons:  Additional incubator proposal and graduation overhead, along with not
 working closely with the whole Commons community on developing the new code
 base.


 Secondly, we have two existing JSR-303 implementations that we could
 possibly use to help bootstrap this effort:

 I. - Agimatec-Validation project on Google Code
 Code uses ASL 2.0 and I have approached one of the Agimatec GmbH employees
 about possibly donating the existing code to Apache.

 II. - JSR-303 RI
 Code being developed by Red Hat as the RI using ASL 2.0.  Kevin Sutter from
 the OpenJPA team has approached Emmanuel at Red Hat on this subject, but it
 is doubtful we would see a code donation, but could pull it in as
 third-party code to get started.


 Please let me know your thoughts, as we would like to get this bootstrapped
 this month, as the Geronimo community is starting to put together our plans
 for a Geronimo 3.0 release in 2010 for a Java EE 6 application server.


 -Donald Woods
 Apache Geronimo Committer and PMC member
 Apache OpenJPA Committer and PMC member
 dwoods.AT.apache.org


 [1] https://issues.apache.org/jira/browse/VALIDATOR-279

 [2] http://jcp.org/en/jsr/detail?id=303

 [3] http://people.redhat.com/~ebernard/validation/

 [4] https://svn.apache.org/repos/asf/commons/sandbox/validator2/trunk





 --
 Thanks
 - Mohammad Nour
 - LinkedIn: http://www.linkedin.com/in/mnour
 
 Life is like riding a bicycle. To keep your balance you must keep moving
 - Albert Einstein

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org





-- 
Matthias Wessendorf

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

Re: [VALIDATOR] Proposal for a JSR-303 Bean Validation Implementation

2009-09-08 Thread Matthias Wessendorf

On Fri, Sep 4, 2009 at 10:39 PM, Mohammad Nour
El-Dinnour.moham...@gmail.com wrote:
 I support either solution 1 or 2 from first section of solutions:

 1- We will not be waiting for others till they decide whether donate
 the code or not.

RH donation will not happen - we could fork, the license is just fine for it.
But yeah, why forking a RI ? :-)

I like the incubator style a little bit better than the commons sandbox.


 2- We will get more benefit for ASF as we may gain more committer to
 join the community and help grow it more.

 3- For the non-committers contribution to the code, I think it is not
 a problem as it is the normal case for ASF projects, these
 contributions make us gain more committers in the future and hence
 more support for ASF.

 On Fri, Sep 4, 2009 at 5:37 PM, Donald Woodsdwo...@apache.org wrote:
 Everyone, I think it is time again to reopen the discussions around creating
 a Validator2 release [1], which implements the upcoming JSR-303 Bean
 Validation spec [2] and [3].  Since JSR-303 is now a required component of
 Java EE 6 application servers and must be supported by JSR-314 JSF2 and
 JSR-317 JPA2, there is growing interest in the Apache Geronimo, Apache
 OpenJPA, Apache MyFaces and Apache OpenEJB projects to grow and maintain a
 JSR-303 implementation at Apache.

 First, to meet this goal, I would like us to consider the following options:

 I. - Commons Sandbox
 Utilize the existing validator2 sandbox area [4] to collaborate on a JSR-303
 implementation which would eventually become commons-validator-2.0.
 Pros:  Existing Apache committers can be given access to the sandbox and
 work with the Commons community to become committers.
 Cons:  Non-committers must provide patches and build karma, even before the
 project is moved out of the sandbox (we have interest from two companies to
 help, but most of their potential contributors are not Apache committers.)

 II. - Apache Incubator
 Submit an incubator proposal to create a JSR-303 focused project, which
 would be sponsored by the Commons PMC and/or Geronimo PMC with the goal
 being that the candidate proposal would become a sub-project of Commons as
 the new Validator R2 code base.
 Pros:  Allows us to seed the initial project with non-committers and
 demonstrate there is broad support for this project.
 Cons:  Additional incubator proposal and graduation overhead, along with not
 working closely with the whole Commons community on developing the new code
 base.


 Secondly, we have two existing JSR-303 implementations that we could
 possibly use to help bootstrap this effort:

 I. - Agimatec-Validation project on Google Code
 Code uses ASL 2.0 and I have approached one of the Agimatec GmbH employees
 about possibly donating the existing code to Apache.

 II. - JSR-303 RI
 Code being developed by Red Hat as the RI using ASL 2.0.  Kevin Sutter from
 the OpenJPA team has approached Emmanuel at Red Hat on this subject, but it
 is doubtful we would see a code donation, but could pull it in as
 third-party code to get started.


 Please let me know your thoughts, as we would like to get this bootstrapped
 this month, as the Geronimo community is starting to put together our plans
 for a Geronimo 3.0 release in 2010 for a Java EE 6 application server.


 -Donald Woods
 Apache Geronimo Committer and PMC member
 Apache OpenJPA Committer and PMC member
 dwoods.AT.apache.org


 [1] https://issues.apache.org/jira/browse/VALIDATOR-279

 [2] http://jcp.org/en/jsr/detail?id=303

 [3] http://people.redhat.com/~ebernard/validation/

 [4] https://svn.apache.org/repos/asf/commons/sandbox/validator2/trunk





 --
 Thanks
 - Mohammad Nour
 - LinkedIn: http://www.linkedin.com/in/mnour
 
 Life is like riding a bicycle. To keep your balance you must keep moving
 - Albert Einstein

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org





-- 
Matthias Wessendorf

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

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release cassandra 0.4.0-rc1

2009-09-07 Thread Matthias Wessendorf

+1 on what Niall said

On Mon, Sep 7, 2009 at 12:26 PM, Niall
Pembertonniall.pember...@gmail.com wrote:
 What about commons javaflow - you're releasing a binary jar for that
 (its not been released by apache commons) and no source code from what
 I can see:

 http://incubator.markmail.org/message/wko4emwcwst5imto

 If you're going to release that code then you should include the
 source and IMO it would be good to tag the code in subversion and give
 it a version number other than 1.0-SNAPSHOT.

 Niall

 On Thu, Sep 3, 2009 at 4:40 PM, Eric Evans eev...@rackspace.com wrote:

 The Cassandra community voted on and approved the release of Apache
 Cassandra 0.4.0-rc1. We would now like to request the approval of the
 Incubator PMC for this release.

 Cassandra is a massively scalable, eventually consistent, distributed,
 structured key-value store.

 Podling vote thread:
 http://www.mail-archive.com/cassandra-...@incubator.apache.org/msg00856.html
 0.4.0-rc1 artifacts: http://people.apache.org/~eevans
 SVN tag:
 https://svn.apache.org/repos/asf/incubator/cassandra/tags/cassandra-0.4.0-rc1
 Project home: http://incubator.apache.org/cassandra/
 Incubation status: http://incubator.apache.org/projects/cassandra.html

 The vote will remain open for 72 hours (or longer if needed).

 There was quite a bit of discussion surrounding the last IPMC vote, so
 here is a list of some of the things that were brought up, and where we
 are are on those issues:

 * No zip archives

 We are still not generating zip archives. Hopefully that won't be an
 issue.

 * Missing SVN properties

 This was addressed in CASSANDRA-368 (i.e. the properties are now in
 place).

 * Licenses in lib/licenses instead of LICENSE.txt

 During the discussion, CASSANDRA-371 was created and a reference has
 since been added to the bottom of LICENSE.txt that directs people to
 lib/licenses for the third-party dependencies.

 The reason for putting third-party licenses in lib/licenses was to ease
 maintenance, which in turn should help guarantee that this information
 is up-to-date and accurate. That still seems like a valid reason so if
 possible, I'd like to wait for the resolution of LEGAL-31

 * JUnit jar in binary archive

 I completely lost track of this after the discussion, and didn't notice
 it until after 0.4.0-rc1 was tagged and the artifacts created. I've
 submitted CASSANDRA-417 so that it won't be forgotten again.

 * Attributions in NOTICE.txt

 During the discussion, I explained the rationale[1] behind our
 NOTICE.txt, but I'm not sure that went anywhere. The example cited was
 Antlr, but by my understanding of the BSD license, there is no
 requirement that the attribution be in a top-level file let alone one
 named NOTICE.txt.

 Again, we're trying to keep things simple so that it is easier to
 maintain and as a result, more accurate and up-to-date. But, if this is
 a sore spot with IPMC voters, we'll put all attributions, required or
 not in NOTICE.txt.

 * NOTICE shouldn't have Developers and Contributors are listed in...

 This is another one I lost track of after the discussion, (CASSANDRA-415
 submitted).



 [1]
 http://www.mail-archive.com/general@incubator.apache.org/msg22190.html

 Regards,

 --
 Eric Evans
 eev...@rackspace.com


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org



 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org





-- 
Matthias Wessendorf

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

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[Announce] Release of Apache MyFaces Trinidad 1.0.11

2009-09-04 Thread Matthias Wessendorf

The Apache MyFaces Trinidad team is pleased to announce the release of
Apache MyFaces Trinidad Core 1.0.11.

Apache MyFaces Trinidad is a JavaServer(tm) Faces 1.1 component library.

Trinidad Core 1.0.11 is available in both binary and source distributions:

 * http://myfaces.apache.org/trinidad/download.html

Apache MyFaces Trinidad is available in the central Maven repository under
Group ID org.apache.myfaces.trinidad.


Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661styleName=Htmlversion=12313509

Enjoy!

--
Matthias Wessendorf

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

Re: MyFaces 2.0 f:ajax question

On Wed, Sep 2, 2009 at 5:36 PM, Matthias Wessendorfmat...@apache.org wrote:
 On Wed, Sep 2, 2009 at 5:29 PM, Bruno Arandabrunoara...@gmail.com wrote:
 Yeah, you are not going to prison just for committing the code. And
 the discussion can continue in legal while things work...

 no, but isn't the general problem that some folks are looking at the RI code 
 ?!
 IMO that's not correct at all. I agree with Curtiss' concerns, as I share 
 them.

 Maybe we should ping legal _before_ committing problematic stuff ?


an interesting note from the Apache Harmony project, we got on legal@:
snip
Harmony, OTOH, says that they have been extremely cautious and have
not allowed any developer to work on any part which they have
previously been exposed to. This is largely precautionary beyond
necessity.
/snip

perhaps we should also ensure a policy like that ?!


 -Matthias


 Cheers,

 Bruno

 2009/9/2 Werner Punz werner.p...@gmail.com:
 That is one of the reasons why I am discussing this here from an Apache
 codebase and license point of view I am pretty sure I am clear here (I also
 will bring this to legal tomorrow), but I am still not sure if I can commit
 the code due
 to the stance some of the contributing companies have regarding code.

 My personal point of view for now is this:

 a) bring this discussion to legal

 b) commit the code - if legal gives its ok, if someone thinks it is
 infringing (which i doubt) we still can rip it out



 Werner


 Curtiss Howard schrieb:

 The only concern I have is that my company considers a person
 contaminated if they've been exposed to some other code base and
 therefore any code written by that person carries the risk of
 infrigement (i.e., if you saw a company's code for class X and write
 your own implementation of X without looking at their code ever again,
 you could remember things you saw and your implementation could
 subsequently copy parts of their code with literally being a copy).  I
 would be careful.

 Thanks,


 Curtiss Howard







 --
 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] Release Tobago 1.0.23

+1

On Thu, Sep 3, 2009 at 8:13 AM, Bernd Bohmannbernd.bohm...@atanion.com wrote:
 Hello,

 I would like to release Tobago 1.0.23.

 For a detail list please consult the release notes:

 http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12314159

 The version is available at the staging location and the
 revision number of the release is 810617 and tagged as tobago-1.0.23.

 Staging distribution:

 http://people.apache.org/~bommel/repo

 Staging repository:

 http://people.apache.org/~bommel/repo


 The Vote is open for 72h.

 [ ] +1
 [ ] +0
 [ ] -1




-- 
Matthias Wessendorf

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

Result - Re: [VOTE] Release of Trinidad 1.0.11

Thanks for voting, we got 5 +1 votes:
-Matthias Wessendorf
-Gerhard Petracek
-Paul Mander (not-binding)
-Bernd Bohmann
-Burno Aranda

and one +0:
-Grant Smith

I'll followup w/ the required steps to get the release out of the door.

Thx,
Matthias

On Wed, Sep 2, 2009 at 7:02 PM, Bruno Arandabrunoara...@gmail.com wrote:
 +1

 2009/9/2 Bernd Bohmann bernd.bohm...@googlemail.com:
 +1

 Regards

 Bernd

 On Tue, Sep 1, 2009 at 10:23 AM, Paul Manderpaul.s.man...@gmail.com wrote:

 +1

 grantsmith wrote:

 +0 sorry no time this week :(

 On Mon, Aug 31, 2009 at 10:25 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


 2009/8/31 Matthias Wessendorf mat...@apache.org

 +1

 On Mon, Aug 31, 2009 at 6:32 PM, Matthias Wessendorfmat...@apache.org
 wrote:
  Hi,
 
  I was running the needed tasks to get the 1.0.11 release of the Apache
  MyFaces Trinidad CORE out. The artifacts are deployed to my private
  Apache account ([1]).
 
  Please take a look at the 1.0.11 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/trinidad1011/http://people.apache.org/%7Ematzew/trinidad1011/
 
  --
  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





 --
 Grant Smith



 --
 View this message in context: 
 http://www.nabble.com/-VOTE--Release-of-Trinidad-1.0.11-tp25226372p25236265.html
 Sent from the My Faces - Dev mailing list archive at Nabble.com.







-- 
Matthias Wessendorf

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

Re: MyFaces 2.0 f:ajax question

On Thu, Sep 3, 2009 at 12:29 PM, Curtiss Howardcurtiss.how...@gmail.com wrote:
 an interesting note from the Apache Harmony project, we got on legal@:
 snip
 Harmony, OTOH, says that they have been extremely cautious and have
 not allowed any developer to work on any part which they have
 previously been exposed to. This is largely precautionary beyond
 necessity.
 /snip

 perhaps we should also ensure a policy like that ?!


 +1.  I can't speak for everyone, but that is definitely how my company
 operates.  IANAL, but I've been lectured by several and my concern is
 that if MyFaces developers take the attitude that seeing how the RI
 does it isn't a big deal then my role on this project may be in
 jeopardy because I won't know if I've been inadvertantly exposed to a
 copy-but-not-really-a-copy-and-paste of Sun code and it could expose
 my company to all sorts of unforeseen legal implications.

+1


 I know it seems silly to be so paranoid about code that's available
 freely, but the reality is that MyFaces is shipped in commercial
 products and it would be unethical to leave those products vulnerable
 to legal attack because they may be violating Sun's IP unknowingly.
 There is precedent here... remember SCO?

unfortunately yes...


 So, in this case I strongly suggest that MyFaces contributors follow
 the advice of the legal lowest common denominator (or in this case
 perhaps it's the greatest common denominator :D) and not look at RI
 code AT ALL.

+1

Apache had a (similar) issue in the past. JBoss sent a *letter* to Apache,
as they thought some code from JBoss container was looking
identically... [1]
Sure we aren't about copying code here, but I attach this _resource_
more as an FYI.

-Matthias

[1] http://markmail.org/message/5v6kuqp7rgmn35fo


 Thanks,


 Curtiss Howard


-- 
Matthias Wessendorf

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

[Announce] Release of Apache MyFaces Trinidad 1.0.11

The Apache MyFaces Trinidad team is pleased to announce the release of
Apache MyFaces Trinidad Core 1.0.11.

Apache MyFaces Trinidad is a JavaServer(tm) Faces 1.1 component library.

Trinidad Core 1.0.11 is available in both binary and source distributions:

 * http://myfaces.apache.org/trinidad/download.html

Apache MyFaces Trinidad is available in the central Maven repository under
Group ID org.apache.myfaces.trinidad.


Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661styleName=Htmlversion=12313509

Enjoy!

--
Matthias Wessendorf

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

Re: Scripting Extensions, java!!! reloading now working (with limitations)

On Thu, Sep 3, 2009 at 2:20 PM, Werner Punzwerner.p...@gmail.com wrote:
 Ok... another scripting extension question.

 I probably will work the last things out I have to deal with on friday,
 or monday next week.
 (Some classpath issues are still pending in the java area)

 So far we have covered groovy and java but currently under JDK 1.2

 What should we do next

 a) Either integrate more scripting languages, probably jruby could be a
 possible candidate due to being able to handle dynamic compilation, jython I
 am not sure for now I have to check out what it can do)

 b) Integrate JCI for java dynamic recompilation to handle pre jdk6 jdks

 c) Start with the myfaces 2.0 integration

 d) Start with the documentation on the wiki

 I would prefer c) to get things going for 2.0

+1


 But I wanted to ask the community first.


 Werner


 Werner Punz schrieb:

 Ok the current1.2 branch currently is not in the nightly builds.
 This will be fixed soon  in the meanwhile do a manual checkout of the
 current1.2 branch that should resolve the problem.
 I committed the changes to the startup infrastructure about a week ago.
 So checking out should work.






-- 
Matthias Wessendorf

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

[Announce] Release of Apache MyFaces Trinidad 1.0.11