from:"Matthias Wessendorf"

Yeah, I understand that.

Any interest in helping with the fix ? :)

-Matthias

On Thu, Feb 25, 2010 at 8:47 AM, Ganesh gan...@j4fry.org wrote:
 Also this blocks me from testing the beta with DojoFaces which might reveal
 other issues ...

 Best regards,
 Ganesh

 Matthias Wessendorf schrieb:

 Again...

 MYFACES-2543

 *snip*
 If the answer to this question is no, Facelets in JSF 2.0 is
 backwards compatible with pre-JSF 2.0 Facelets and such an application
 must not continue to bundle the Facelets jar file along with the
 application, and must not continue to set the Facelets configuration
 parameters.
 *snip*

 So, this is actually blocking a reasonable use-case. Please keep the
 bug open ;-)

 -Matthias






-- 
Matthias Wessendorf

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

Re: [Facelets] deploying old Facelets templates with MyFaces 2

+1 on sooner arrival as later. Current behavior is just lame

On Thu, Feb 25, 2010 at 1:33 PM, Jakob Korherr jakob.korh...@gmail.com wrote:
 Hi Leo,

 It is a really easy fix - I just removed the version check in
 TagLibraryConfig to make old libraries work. If the EG changes the spec in
 this field we can apply this later. In the meantime, I think we clearly
 should support old facelets taglibs.

 Regards,
 Jakob

 2010/2/25 Leonardo Uribe lu4...@gmail.com

 Hi

 Before commit it I would like to have the description about how this
 should work and ask or notify the EG about this behavior (so if they decide
 something different we have a chance to do it right). Since ri is doing
 something in this field, I think we can commit a solution for that.

 regards,

 Leonardo Uribe

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

 I'll do it! I also have a working version running locally at the moment,
 I just have to test it a little more. Then I'll commit it ;)

 Regards,
 Jakob

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

 Yeah, I understand that.

 Any interest in helping with the fix ? :)

 -Matthias

 On Thu, Feb 25, 2010 at 8:47 AM, Ganesh gan...@j4fry.org wrote:
  Also this blocks me from testing the beta with DojoFaces which might
  reveal
  other issues ...
 
  Best regards,
  Ganesh
 
  Matthias Wessendorf schrieb:
 
  Again...
 
  MYFACES-2543
 
  *snip*
  If the answer to this question is no, Facelets in JSF 2.0 is
  backwards compatible with pre-JSF 2.0 Facelets and such an
  application
  must not continue to bundle the Facelets jar file along with the
  application, and must not continue to set the Facelets configuration
  parameters.
  *snip*
 
  So, this is actually blocking a reasonable use-case. Please keep the
  bug open ;-)
 
  -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: [Facelets] deploying old Facelets templates with MyFaces 2

but... the spec *clearly* says that if you extend from OLD facelet classes,
you have to have to ship it.

On Thu, Feb 25, 2010 at 1:37 PM, Leonardo Uribe lu4...@gmail.com wrote:
 Hi

 If we read every facelet 1.1.x tag lib xml file, it is possible to get
 ClassNotFoundException. The problem with this behavior is that it does not
 give the chance to users to fix it without change the original jar file.

 regards,

 Leonardo Uribe

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

 Hi Leo,

 It is a really easy fix - I just removed the version check in
 TagLibraryConfig to make old libraries work. If the EG changes the spec in
 this field we can apply this later. In the meantime, I think we clearly
 should support old facelets taglibs.

 Regards,
 Jakob

 2010/2/25 Leonardo Uribe lu4...@gmail.com

 Hi

 Before commit it I would like to have the description about how this
 should work and ask or notify the EG about this behavior (so if they decide
 something different we have a chance to do it right). Since ri is doing
 something in this field, I think we can commit a solution for that.

 regards,

 Leonardo Uribe

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

 I'll do it! I also have a working version running locally at the moment,
 I just have to test it a little more. Then I'll commit it ;)

 Regards,
 Jakob

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

 Yeah, I understand that.

 Any interest in helping with the fix ? :)

 -Matthias

 On Thu, Feb 25, 2010 at 8:47 AM, Ganesh gan...@j4fry.org wrote:
  Also this blocks me from testing the beta with DojoFaces which might
  reveal
  other issues ...
 
  Best regards,
  Ganesh
 
  Matthias Wessendorf schrieb:
 
  Again...
 
  MYFACES-2543
 
  *snip*
  If the answer to this question is no, Facelets in JSF 2.0 is
  backwards compatible with pre-JSF 2.0 Facelets and such an
  application
  must not continue to bundle the Facelets jar file along with the
  application, and must not continue to set the Facelets configuration
  parameters.
  *snip*
 
  So, this is actually blocking a reasonable use-case. Please keep the
  bug open ;-)
 
  -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: [Facelets] deploying old Facelets templates with MyFaces 2

From the spec (10.1.2):


A decision was made early in this process to strive for backwards
compatibility between the latest popular version of Facelets and
Facelets in JSF 2.0. The sole determinant to backwards compatibility
lies in the answer to the question,


===
is there any Java code in the application, or in libraries used by
the application, that extends from or depends on any class in package
com.sun.facelets and/or its sub-packages?

If the answer to this question is yes, Facelets in JSF 2.0 is not
backwards compatibile with Facelets and such an application must
continue to bundle the Facelets jar file along with the application,
continue to set the Facelets configuration parameters, and also set
the javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER context-param to
true. Please see Section 11.1.3 Application Configuration Parameters
for details on this option. Any code that extends or depends on any
class in package com.sun.facelets and/or its sub-packages must be
modified to depend on the appropriate classes in package
javax.faces.webapp.vdl and/or its subpackages.
===

Also note the *java* in java code.

-Matthias


On Thu, Feb 25, 2010 at 1:56 PM, Leonardo Uribe lu4...@gmail.com wrote:
 Hi

 The problem is the spec is not explicit about that. I think the way it this
 written those paragraph are as if it was a guideline and that's is the
 problem because this should be explicit.

 The behavior proposed (throw ClassNotFoundException or ClassCastException
 and kick all users to use facelets 1.1.x) is valid, so it is ok to commit
 it.

 regards,

 Leonardo Uribe

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

 Hi,

 But the users DO want to run the old facelets taglibs and, as discussed
 before, 95% of the old taglibs don't rely on com.sun.facelets classes,
 they just define tags via xhtml files.

 If they get a ClassCastException the just have to use the old
 facelets-1.1.x. This is excatly what the spec says!

 Regards,
 Jakob

 2010/2/25 Leonardo Uribe lu4...@gmail.com

 Hi

 If we read every facelet 1.1.x tag lib xml file, it is possible to get
 ClassNotFoundException. The problem with this behavior is that it does not
 give the chance to users to fix it without change the original jar file.

 regards,

 Leonardo Uribe

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

 Hi Leo,

 It is a really easy fix - I just removed the version check in
 TagLibraryConfig to make old libraries work. If the EG changes the spec 
 in
 this field we can apply this later. In the meantime, I think we clearly
 should support old facelets taglibs.

 Regards,
 Jakob

 2010/2/25 Leonardo Uribe lu4...@gmail.com

 Hi

 Before commit it I would like to have the description about how this
 should work and ask or notify the EG about this behavior (so if they 
 decide
 something different we have a chance to do it right). Since ri is doing
 something in this field, I think we can commit a solution for that.

 regards,

 Leonardo Uribe

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

 I'll do it! I also have a working version running locally at the
 moment, I just have to test it a little more. Then I'll commit it ;)

 Regards,
 Jakob

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

 Yeah, I understand that.

 Any interest in helping with the fix ? :)

 -Matthias

 On Thu, Feb 25, 2010 at 8:47 AM, Ganesh gan...@j4fry.org wrote:
  Also this blocks me from testing the beta with DojoFaces which
  might reveal
  other issues ...
 
  Best regards,
  Ganesh
 
  Matthias Wessendorf schrieb:
 
  Again...
 
  MYFACES-2543
 
  *snip*
  If the answer to this question is no, Facelets in JSF 2.0 is
  backwards compatible with pre-JSF 2.0 Facelets and such an
  application
  must not continue to bundle the Facelets jar file along with the
  application, and must not continue to set the Facelets
  configuration
  parameters.
  *snip*
 
  So, this is actually blocking a reasonable use-case. Please keep
  the
  bug open ;-)
 
  -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: [Facelets] deploying old Facelets templates with MyFaces 2

can you try, now ?

On Thu, Feb 25, 2010 at 7:53 PM, Jakob Korherr jakob.korh...@gmail.com wrote:
 Hi,

 I implemented the lookup for the presence of the facelets-1.1.x view-handler
 in the faces-config.xml in the factory, so that the users don't have to
 explicitly set the related web.xml config parameter when they already said
 that they want to use facelets-1.1.x in faces-config.xml (via defining the
 facelets-1.1.x view-handler). Mojarra actually does exactly the same.

 Regards,
 Jakob

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

 On Thu, Feb 25, 2010 at 7:15 PM, Leonardo Uribe lu4...@gmail.com wrote:
  Hi Ganesh
 
  I think dojofaces will not work until apply the patch on MYFACES-2564
  (look
  on subversion commits). This change was reverted but now we need it to
  complete the solution. Anyway we need to change it a little and maybe
  remove
  the code that checks for facelets view handler and takes into account to

 right, as I understand it users are asked/forced to get rid of that.

 -M

  check if it is facelets for jsf 2.0 working or not.



 
  regards,
 
  Leonardo Uribe
 
  2010/2/25 Matthias Wessendorf mat...@apache.org
 
  it should work, by now, just go svn up on trunk.
 
  I am interested in the results of testing your project.
 
  thx
 
  On Thu, Feb 25, 2010 at 7:08 PM, Ganesh gan...@j4fry.org wrote:
   Hi Matthias,
  
   Currently I'm putting my effords into dojofaces, so interest is
   there,
   but
   time is scarce ... sorry.
  
   Best regards,
   Ganesh
  
   Matthias Wessendorf schrieb:
  
   Yeah, I understand that.
  
   Any interest in helping with the fix ? :)
  
   -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: [Facelets] deploying old Facelets templates with MyFaces 2

it should work, by now, just go svn up on trunk.

I am interested in the results of testing your project.

thx

On Thu, Feb 25, 2010 at 7:08 PM, Ganesh gan...@j4fry.org wrote:
 Hi Matthias,

 Currently I'm putting my effords into dojofaces, so interest is there, but
 time is scarce ... sorry.

 Best regards,
 Ganesh

 Matthias Wessendorf schrieb:

 Yeah, I understand that.

 Any interest in helping with the fix ? :)

 -Matthias





-- 
Matthias Wessendorf

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

Re: [Facelets] deploying old Facelets templates with MyFaces 2

On Thu, Feb 25, 2010 at 7:15 PM, Leonardo Uribe lu4...@gmail.com wrote:
 Hi Ganesh

 I think dojofaces will not work until apply the patch on MYFACES-2564 (look
 on subversion commits). This change was reverted but now we need it to
 complete the solution. Anyway we need to change it a little and maybe remove
 the code that checks for facelets view handler and takes into account to

right, as I understand it users are asked/forced to get rid of that.

-M

 check if it is facelets for jsf 2.0 working or not.




 regards,

 Leonardo Uribe

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

 it should work, by now, just go svn up on trunk.

 I am interested in the results of testing your project.

 thx

 On Thu, Feb 25, 2010 at 7:08 PM, Ganesh gan...@j4fry.org wrote:
  Hi Matthias,
 
  Currently I'm putting my effords into dojofaces, so interest is there,
  but
  time is scarce ... sorry.
 
  Best regards,
  Ganesh
 
  Matthias Wessendorf schrieb:
 
  Yeah, I understand that.
 
  Any interest in helping with the fix ? :)
 
  -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: UIData.setDataModel must not be used anymore?

HEy Mark,

interesting found!

On Thu, Feb 25, 2010 at 6:25 PM, Mark Struberg strub...@yahoo.de wrote:
 I found the following source in UIData of the latest from trunk (2.0.0):

    protected void setDataModel(DataModel dataModel)
    {
        throw new UnsupportedOperationException(this method is here only to 
 maintain binary compatibility w/ the RI);
    }

 which make a few libraries crash.

 Is there any reason for that change?
 Or better: is this defined in the JSF-2 spec?

Nope, I'd say. This has been done almost 4 years ago:
http://bit.ly/bXtzWq

I took a look at the official JavaDoc and they actually say
something meaningful...
http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/javax/faces/component/UIData.html#setDataModel(javax.faces.model.DataModel)


 What is the reason for that change?

log-message
added 23 methods for binary compatibility w/ the RI
12 methods throw UnsupportedOperationException in this commit
added 1.5 features to FactoryFinder
added new class called HtmlColumn
/log-message

I can track down 2morrow if there was some *old* tck issue or similar

-Matthias


 I worked around by using DataModel#setWrappedData(Object) instead, but not 
 sure about the side effects...

 txs and LieGrue,
 strub

 __
 Do You Yahoo!?
 Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz 
 gegen Massenmails.
 http://mail.yahoo.com




-- 
Matthias Wessendorf

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

Re: Request class is an empty placeholder

)
        at

 javax.servlet.http.HttpServletRequestWrapper.getHeader(HttpServletRequestWrapper.java:80)

        at

 org.apache.myfaces.trinidadinternal.context.external.ServletRequestHeaderMap.getAttribute
 (ServletRequestHeaderMap.java:42)
        at

 org.apache.myfaces.trinidadinternal.context.external.ServletRequestHeaderMap.getAttribute
 (ServletRequestHeaderMap.java:30)
        at

 org.apache.myfaces.trinidadinternal.context.external.AbstractAttributeMap.get(AbstractAtt
 ributeMap.java:73)
        at

 org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit.isAjaxRequest(CoreRender
 Kit.java:148)
        at

 org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit.isPartialRequest(CoreRen
 derKit.java:163)
        at

 org.apache.myfaces.trinidadinternal.config.xmlHttp.XmlHttpConfigurator.getExternalContext
 (XmlHttpConfigurator.java:61)
        at

 org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(Glob
 alConfiguratorImpl.java:351)
        at

 org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.init
 (FacesContextFactoryImpl.java:90)
        at

 org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(Faces
 ContextFactoryImpl.java:68)
        at

 org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFaces
 Initializer.java:140)
        at

 org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.jav
 a:109)
        at

 org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServlet
 ContextListener.java:155)
        at

 org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3934)
        at
 org.apache.catalina.core.StandardContext.start(StandardContext.java:4429)
        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:526)
        at
 org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:987)
        at

 org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:909)
        at
 org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:495)
        at
 org.apache.catalina.startup.HostConfig.start(HostConfig.java:1206)
        at
 org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:314)
        at

 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
        at
 org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
        at
 org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
        at
 org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
        at
 org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
        at
 org.apache.catalina.core.StandardService.start(StandardService.java:516)
        at
 org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:583)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at

 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at

 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)


 I have search with this error on forums, but no one resolve it.
 Could you please help me out regarding this issue?
 At least, let me know the exact problem, so that I can work on it.

 Thank You.
 --
 View this message in context:
 http://old.nabble.com/Request-class-is-an-empty-placeholder-tp27714410p27714410.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] [PROPOSAL] Validation incubator for JSR-303 Bean Validation

, OpenJPA, OpenEJB,
 OpenWebBeans and MyFaces.

 Homogeneous Developers

 The list of initial committers are geographically distributed across the
 U.S., Europe and Africa with no one company being associated with a
 majority of the developers. Many of these initial developers are
 experienced Apache committers already and all are experienced with
 working in distributed development communities. It is our hope that,
 through the incubator, further contributors with a broad background of
 experience but common interest will become involved with this project.

 Reliance on Salaried Developers

 To the best of our knowledge, none of the initial committers are being
 paid to develop code for this project.

 Relationships with Other Apache Products

 A number of existing ASF projects require an implementation of JSR303
 including Geronimo, OpenJPA and MyFaces. It is hoped that members of
 those projects will be interested in contributing to and adopting this
 implementation.

 Apache Geronimo - Apache Geronimo is a server runtime framework and
 fully certified Java EE 5 application server runtime. It is interested
 in using this project, to provide the required JSR-303 implementation
 for the upcoming Geronimo 3.0 server, which will be a Java EE 6
 certified release.

 Apache OpenJPA - Apache OpenJPA is a JPA provider, who needs to
 integrate and test with a JSR-303 provider as part of JSR-317 JPA2
 specification. In the future, we may decide to include the Validation
 artifacts in our distribution for Java SE users.

 Apache MyFaces - Apache MyFaces is a JSF provider, who needs to
 integrate and test with a JSR-303 provider as part of the JSR-314 JSF2
 specification. It is our hope, that the preferred Bean Validation
 provider will become Validation instead of the Hibernate RI, after the
 project exits the incubator.

 A Excessive Fascination with the Apache Brand

 The Agimatec-Validation code is currently being hosted on Google Code.
 The developers (Agimatec Gmbh) did not approach Apache, but were instead
 approached by Donald Woods about moving the code to Apache in hopes to
 build a broader and more vibrant community around the code and as the
 eventual next generation Commons Validator codebase.

 Documentation

 JSR303 Bean Validation Specification:

    * http://jcp.org/en/jsr/detail?id=303

 Agimatec Validation Project:

    * http://code.google.com/p/agimatec-validation/

 Initial Source

 The intiial source comprises code developed as as part of the
 agimatec-validation project on googlecode:

    * http://code.google.com/p/agimatec-validation/source/browse/

 Source and Intellectual Property Submission Plan
 SGA has been submitted. Source tarball has not been uploaded to SVN yet.

 External Dependencies

    * Runtime
          o Apache Geronimo Bean Validation 1.0 Spec API
          o Apache Commons BeanUtils
          o Apache Commons Lang
          o Apache Commons Logging
          o Apache Commons Collections
          o XStream
    * Optional
          o org.freemarker - freemarker template to generate JSON output
    * Tests
          o JUnit
          o Log4J

 Required Resources

    * Mailing lists
          o validation-private (with moderated subscriptions)
          o validation-dev
          o validation-user
          o validation-commits
    * Subversion directory
          o https://svn.apache.org/repos/asf/incubator/validation
    * Website
          o Confluence (VALIDATION)
    * Issue Tracking
          o JIRA (VALIDATION)

 Initial Committers

 Names of initial committers with affiliation and current ASF status:

    * Roman Stumm [roman.stumm at agimatec.de] - (Agimatec GmbH, CLA filed)
    * Donald Woods [dwoods] - (IBM, ASF committer)
    * Niall Pemberton [niallp] - (EMC, ASF committer)
    * Mohammad Nour El-Din [mnour] - (Thebe Technology, ASF committer)
    * Simone Tripodi [simone.tripodi at gmail.com] - (Asemantics S.r.l,
 CLA filed)
    * Jeremy Bauer [jrbauer] - (IBM, ASF committer)
    * Gerhard Petracek [gpetracek] - (IRIAN Solutions GmbH, ASF committer)
    * Mark Struberg [struberg] - (ASF committer)

 Sponsors

 Champion

    * Kevan Miller

 Nominated Mentors

    * Kevan Miller
    * Niall Pemberton
    * Luciano Resende

 Sponsoring Entity

    * Apache Incubator PMC


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




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




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

[Facelets] deploying old Facelets templates with MyFaces 2

2010-02-24 Thread Matthias Wessendorf

Again...

MYFACES-2543

*snip*
If the answer to this question is no, Facelets in JSF 2.0 is
backwards compatible with pre-JSF 2.0 Facelets and such an application
must not continue to bundle the Facelets jar file along with the
application, and must not continue to set the Facelets configuration
parameters.
*snip*

So, this is actually blocking a reasonable use-case. Please keep the
bug open ;-)

-Matthias


-- 
Matthias Wessendorf

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

Re: [TRINIDAD 1.0.12] LocaleSymbols* at LocaleElements*.js files are empty in 1.0.12 release

2010-02-24 Thread Matthias Wessendorf

.',
 'org.apache.myfaces.trinidad.convert.DateTimeConverter.DATE_HINT':'Example:
 {0}',
 'org.apache.myfaces.trinidad.convert.DateTimeConverter.TIME_HINT':'Example:
 {0}',
 'org.apache.myfaces.trinidad.validator.DateTimeRangeValidator.MAXIMUM':'The
 date is after the valid range.',
 'javax.faces.validator.LongRangeValidator.MINIMUM_detail':'The number
 must be greater than or equal to {2}.',
 'javax.faces.LongRange':'The number is not a whole number.',
 'org.apache.myfaces.trinidad.validator.RangeValidator.RANGE_HINT':'Enter
 a number between {0} and {1}.',
 'org.apache.myfaces.trinidad.validator.DoubleRangeValidator.NOT_IN_RANGE':'The
 number is outside the valid range.',
 'org.apache.myfaces.trinidad.UIXEditableValue.REQUIRED':'A value is 
 required.',
 'org.apache.myfaces.trinidad.validator.ByteLengthValidator.MAXIMUM':'The
 value is too long.',
 'org.apache.myfaces.trinidad.validator.RangeValidator.MINIMUM_HINT':'Enter
 a number greater than or equal to {0}.',
 'org.apache.myfaces.trinidad.convert.ByteConverter.MINIMUM_detail':'The
 number must be greater than or equal to {2}.',
 'org.apache.myfaces.trinidad.validator.LengthValidator.EXACT_detail':'Enter
 exactly {2} characters.',
 'org.apache.myfaces.trinidad.validator.DateRestrictionValidator.DAY_detail':'Enter
 one of the valid dates.',
 'org.apache.myfaces.trinidad.validator.DateRestrictionValidator.MONTH_detail':'Enter
 a date in one of the following months: {2}',
 'org.apache.myfaces.trinidad.validator.DoubleRangeValidator.MINIMUM_detail':'The
 number must be greater than or equal to {2}.',
 'org.apache.myfaces.trinidad.validator.DoubleRangeValidator.MAXIMUM':'The
 number is too high.',
 'org.apache.myfaces.trinidad.convert.ByteConverter.MAXIMUM':'The
 number is too high.',
 'org.apache.myfaces.trinidad.convert.ByteConverter.MAXIMUM_detail':'The
 number must be less than or equal to {2}.',
 'org.apache.myfaces.trinidad.convert.FloatConverter.CONVERT':'The
 value is not a number.',
 'org.apache.myfaces.trinidad.convert.DateTimeConverter.CONVERT_DATE':'The
 date is not in the correct format.',
 'org.apache.myfaces.trinidad.validator.DateTimeRangeValidator.MINIMUM_HINT':'Enter
 a date on or after {0}.',
 'org.apache.myfaces.trinidad.convert.ByteConverter.MINIMUM':'The
 number is too low.',
 'org.apache.myfaces.trinidad.convert.DateTimeConverter.CONVERT_TIME_detail':'Enter
 a time in the same format as this example: {2}',
 'org.apache.myfaces.trinidad.UIXEditableValue.CONVERSION':'The value
 is not the in correct format.',
 'javax.faces.LongRange_detail':'Enter a whole number.',
 'org.apache.myfaces.trinidad.UIXTableSelectMany.REQUIRED':'A row
 selection is required.',
 'org.apache.myfaces.trinidad.component.core.input.CoreInputFile.INPUT_FILE_ERROR':'An
 error occurred uploading the file.',
 'org.apache.myfaces.trinidad.convert.NumberConverter.CONVERT_CURRENCY_detail':'Enter
 a currency in the same format as this example: {2}',
 'org.apache.myfaces.trinidad.convert.ColorConverter.CONVERT':'The
 color is not in the correct format.',
 'org.apache.myfaces.trinidad.convert.IntegerConverter.CONVERT_detail':'Enter
 a whole number.',
 'org.apache.myfaces.trinidad.convert.LongConverter.MINIMUM_detail':'The
 number must be greater than or equal to {2}.'
 }


 Regards,

 -- Rafa




 On Tue, Feb 23, 2010 at 6:15 PM, Matthias Wessendorf mat...@apache.orgwrote:

 Hey,

 I just launched demo, all fine. JS in there, e.g:


 http://localhost:8080/trinidad-demo/adf/jsLibs/resources/LocaleElements_en1_0_11.js?loc=en


 however, the only problem is the invalid version. Will fix that ;-)

 -Matthias

 2010/2/23 Rafa Pérez raja...@gmail.com:
  Hi all,
 
  we have been having some problems with PPR since last update of Trinidad.
  Today, we have seen that Locale*.js files are empty and this is causing
 our
  problem. I think there have been some problems with packaging but, how is
 it
  possible that no one took care of this??
  I think Trinidad 1.0.x is being taking apart smoothly...
 
  Will it be a 1.0.13 release soon to fix this problem?
 
  Regards,
 
  -- Rafa
 



 --
 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] RC1 for 1.2.14 with the new skin?

Hi,

should we generate a RC1 for the 1.2.14 release, to have the new skin
hitting the road ?
I am all for it ;-)

-Matthias

-- 
Matthias Wessendorf

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

Re: AW: Stuck making JSF 2.0 work with MyFaces

://myfaces.apache.org/tomahawk;
   
body
h:form enctype=multipart/form-data id=myForm
firstName : h:inputText value=#{user.firstName} /br /
lastName : h:inputText value=#{user.lastName} /br /
pic : t:inputFileUpload id=file storage=file
 accept=image/*
styleClass=myStyle value=#{user.file}/br /
h:commandButton action=#{user.createUser} value=Create
 user/
/h:form
/body
/html
   
The problem is that the page does not get transformed. In the
  browser
  I
get
the exact same code above, not the XHTML code expected.
Please tell me, how can I solve this?
--
View this message in context:
   
  
 
 http://old.nabble.com/Stuck-making-JSF-2.0-work-with-MyFaces-tp27689327p27689327.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
   
   
   
   
   
  
   --
   View this message in context:
  
 
 http://old.nabble.com/Stuck-making-JSF-2.0-work-with-MyFaces-tp27689327p27690169.html
   Sent from the MyFaces - Users mailing list archive at Nabble.com.
  
  
  
  
 
  --
  View this message in context:
 
 http://old.nabble.com/Stuck-making-JSF-2.0-work-with-MyFaces-tp27689327p27691396.html
  Sent from the MyFaces - Users mailing list archive at Nabble.com.
 
 
 
 

 --
 View this message in context:
 http://old.nabble.com/Stuck-making-JSF-2.0-work-with-MyFaces-tp27689327p27691667.html
 Sent from the MyFaces - Users mailing list archive at Nabble.com.





 --
 View this message in context: 
 http://old.nabble.com/Stuck-making-JSF-2.0-work-with-MyFaces-tp27689327p27698952.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 1.0.12] LocaleSymbols* at LocaleElements*.js files are empty in 1.0.12 release

Hey,

I just launched demo, all fine. JS in there, e.g:

http://localhost:8080/trinidad-demo/adf/jsLibs/resources/LocaleElements_en1_0_11.js?loc=en


however, the only problem is the invalid version. Will fix that ;-)

-Matthias

2010/2/23 Rafa Pérez raja...@gmail.com:
 Hi all,

 we have been having some problems with PPR since last update of Trinidad.
 Today, we have seen that Locale*.js files are empty and this is causing our
 problem. I think there have been some problems with packaging but, how is it
 possible that no one took care of this??
 I think Trinidad 1.0.x is being taking apart smoothly...

 Will it be a 1.0.13 release soon to fix this problem?

 Regards,

 -- Rafa




-- 
Matthias Wessendorf

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

Re: Regarding Trinidad 2.0

I'd not say production ready, but we use it.
currently the ajax jsf2.0 is not in there.

(therefore we labeled it as alpha...)

On Tue, Feb 23, 2010 at 6:36 PM,  venkat.rama...@thomsonreuters.com wrote:

 Hi

 Is Trinidad 2 production quality ?  Is the alpha release of Trinidad 
 compatible with JSF 2.0 ?

 Thanks
 Venkat

 -Original Message-
 From: mwessend...@gmail.com [mailto:mwessend...@gmail.com] On Behalf Of 
 Matthias Wessendorf
 Sent: Tuesday, February 23, 2010 2:55 PM
 To: MyFaces Discussion
 Subject: Re: AW: Stuck making JSF 2.0 work with MyFaces

 use Trinidad2 :-)

 On Tue, Feb 23, 2010 at 7:25 AM, cristiJ cristi_ju...@yahoo.com wrote:

 i checked out icefaces and primefaces. I think I'm going to wait untill
 Tomahawk will be released for JSF 2.0.
 Apache has done tremendous work so far.
 I hope you willl have time to upgrade Tomahawk soon



 Jakob Korherr wrote:

 Maybe tomahawk is causing the problems, because there is currently no real
 working branch of tomahawk for JSF 2.0. However there will be one soon.

 Please remove tomahawk completely from your webapp and try again!

 Regards,
 Jakob

 2010/2/22 cristiJ cristi_ju...@yahoo.com


 Hi,

 yes, I just tried it. For both of theses URLs :
 http://localhost:8080/app02/faces/index.xhtml
 http://localhost:8080/app02

 the file does not get translated to XHTML, it arrives in the browser with
 the f and h customs.
 This happens only when I add MyFaces.
 I tried adding my self a custom component, defined by this class :

 import javax.faces.component.FacesComponent;
 import javax.faces.component.html.HtmlInputText;

 @FacesComponent(value = HtmlInputFile)
 public class HtmlInputFile extends HtmlInputText {

   �...@override
    public String getRendererType() {
        return javax.faces.File;
    }

 }

 with this balusc.taglib.xml config file

 ?xml version=1.0 encoding=UTF-8?
 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-facelettaglibrary_2_0.xsd;
    version=2.0

     namespacehttp://balusc.net/jsf/html/namespace
    tag
        tag-nameinputFile/tag-name
        component
            component-typeHtmlInputFile/component-type
        /component
    /tag
 /facelet-taglib

 and with the web.xml as such:

 context-param
        param-namejavax.faces.FACELETS_LIBRARIES/param-name
         param-value/WEB-INF/balusc.taglib.xml/param-value
 /context-param


 The page is:

 ?xml version='1.0' encoding='UTF-8' ?
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html xmlns=http://www.w3.org/1999/xhtml;
      xmlns:h=http://java.sun.com/jsf/html;
       xmlns:hh=http://balusc.net/jsf/html;
     body
        h:form enctype=multipart/form-data id=myForm
            firstName : h:inputText value=#{user.firstName} /br /
            lastName : h:inputText value=#{user.lastName} /br /
            city : h:inputText value=#{user.city} /br /
            price : h:inputText value=#{user.price} /br /
             pic : hh:inputFileUpload id=file value=#{user.file}/br
 /
             h:commandButton  action=#{user.createUser} value=Create
 user/
        /h:form
    /body
 /html

 and the xhtml is translated properly. I can't understand what is the
 conflict for MyFaces!?


 Jakob Korherr wrote:
 
  Hi,
 
  Does your URL in your browser include /faces/index.xhtml?
 
  Regards,
  Jakob
 
  2010/2/22 cristiJ cristi_ju...@yahoo.com
 
 
  Hi,
 
  Yes, you understood correctly, neither of h: or f: components are not
  processed.
  I have a very simple index.xhtml file :
 
  ?xml version='1.0' encoding='UTF-8' ?
  !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
  http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
  html xmlns=http://www.w3.org/1999/xhtml;
       xmlns:h=http://java.sun.com/jsf/html;
       xmlns:t=http://myfaces.apache.org/tomahawk;
     body
         h:form enctype=multipart/form-data id=myForm
             firstName : h:inputText value=#{user.firstName} /br /
             lastName : h:inputText value=#{user.lastName} /br /
              city : h:inputText value=#{user.city} /br /
             price : h:inputText value=#{user.price} /br /
              pic : t:inputFileUpload id=file storage=file
  accept=image/* styleClass=myStyle value=#{user.file}/br /
             h:commandButton  action=#{user.createUser} value=Create
  user/
         /h:form
     /body
  /html
 
  The web.xml file for it is:
 
  ?xml version=1.0 encoding=UTF-8?
  web-app version=3.0 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-app_3_0.xsd;
     context-param
         param-namejavax.faces.PROJECT_STAGE/param-name
         param-valueDevelopment/param-value

Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation

+1  to accept Validation into the Incubator

afterwards we still can see where it actually ends up

however I for sure want to see this at Apache.

If you guys need a champion or mentor, count me in !!

-M

On Tue, Feb 23, 2010 at 11:45 PM, Donald Woods dwo...@apache.org wrote:
 We're leaving the TLP/sub-project decision till graduation...

 -Donald


 On 2/23/10 5:36 PM, Brett Porter wrote:
 As I understand it from the proposal, they intend to be Apache Commons 
 Validation.

 On 24/02/2010, at 4:19 AM, Nick Kew wrote:

 On Tue, 23 Feb 2010 10:57:33 -0500
 Donald Woods dwo...@apache.org wrote:

 Given the lack of response on the proposal and the push from our
 champion to get moving :-), I'll assume lazy consensus and call a vote.

 I would like to present for a vote the following proposal to be
 sponsored by the Incubator PMC for a new Validation podling.  The goal
 is to build a community around delivering a JSR-303 Bean Validation
 implementation based on a new incoming codebase from Agimatec GmbH.

 The proposal is available on the wiki at and included below:

   http://wiki.apache.org/incubator/ValidationProposal

 -1 to a project that could end up being called Apache Validation or
 just Validation.  That's too big/general a word for a project name.

 No objection under a changed name.  I'd suggest adding an
 adjective to indicate what is being validated.

 --
 Nick Kew

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


 --
 Brett Porter
 br...@apache.org
 http://brettporter.wordpress.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

FYI: caucho will use JSF2 RI

2010-02-19 Thread Matthias Wessendorf

http://blog.caucho.com/?p=384

-- 
Matthias Wessendorf

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

Fwd: [ANNOUNCE] MyFaces Core v2.0.0-beta-2 Release

2010-02-19 Thread Matthias Wessendorf

FYI


-- Forwarded message --
From: Leonardo Uribe lu4...@apache.org
Date: Fri, Feb 19, 2010 at 10:36 PM
Subject: [ANNOUNCE] MyFaces Core v2.0.0-beta-2 Release
To: annou...@apache.org, annou...@myfaces.apache.org
Cc: d...@myfaces.apache.org, us...@myfaces.apache.org


The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.0.0-beta-2.

MyFaces Core is a JavaServer(tm) Faces 2.0 implementation as specified
by JSR-314.

MyFaces Core 2.0.0-beta-2 is available in both binary and source distributions.

  * http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Release Notes - MyFaces Core - Version 2.0.0-beta-2

Bug

  * [MYFACES-2480] - @ResourceDependencies does not work on custom behaviors
  * [MYFACES-2500] - ResponseWriter clone should not include itself
  * [MYFACES-2507] - onClick on commandLink does not trigger loading
of required jsf.js
  * [MYFACES-2516] - Allow any child for f:event in the case of a
PreRenderViewEvent
  * [MYFACES-2517] - Problem with flash and GET
  * [MYFACES-2520] - UnsupportedOperationException when launching
Trinidad 2 w/ MyFaces2 in Jetty
  * [MYFACES-2522] - f:event wrong attribute name
  * [MYFACES-2525] - Split javax.faces package in OSGi
  * [MYFACES-2526] - javax.faces.view.facelets.ResourceResolver support
  * [MYFACES-2527] - Support for decorator design pattern: RenderKit(s)
  * [MYFACES-2530] - ActionSourceRule does not deal with jsf 1.1
ActionSouce instances
  * [MYFACES-2532] - getClientId() should not be called from listener
registering tree changes on DefaultFaceletsStateManagementStrategy and
PostAddToViewEvent
  * [MYFACES-2533] - FaceletViewDeclarationLanguage call
StateManager.saveView() before write document
  * [MYFACES-2534] - ComponentSupport.addFacet adds a panel when there
is only one component as a child
  * [MYFACES-2535] - view-param on navigation case redirects not being
handled properly
  * [MYFACES-2537] - FacesConfigurator.sortRelativeOrderingList()
algorithm is broken trying to resolve some examples
  * [MYFACES-2540] - Facelets server state saving does not work
  * [MYFACES-2541] - Support for actionlistener method without
ActionEvent parameter
  * [MYFACES-2544] - UIViewRoot skips uncorrectly encodeBegin
  * [MYFACES-2547] - FacesConfigurator absolute ordering does not
handle files with no name correctly
  * [MYFACES-2551] - Set charset=iso-8859-1 using f:view in facelets
page makes current page not being rendered
  * [MYFACES-2553] - Handle MethodExpressions on composite:attribute correctly
  * [MYFACES-2556] - FaceletViewDeclarationLanguage should use
javax.faces.event.ActionEvent instead of java.awt.event.ActionEvent
  * [MYFACES-2557] - AbortProcessingExceptions must be handled by the
ExceptionHandler
  * [MYFACES-2558] - composite:attributes action, actionListener,
validator and valueChangeListener don't need the attribute
method-signature

Improvement

  * [MYFACES-2510] - Remove RendererUtils.NOTHING
  * [MYFACES-2545] - ProjectStage can be set via System Property and
ProjectStage!=Production should create a log entry
  * [MYFACES-2548] - META-INF resource lookup in OSGi environment
  * [MYFACES-2549] - Support for valueChangeListener method without
ValueChangeEvent parameter

New Feature

  * [MYFACES-2531] - Support for name/library attributes with h:commandButton
  * [MYFACES-2542] - Don't throw exception if no SelectItems found

Task

  * [MYFACES-2483] - Find a way to allow c:if work with partial state
saving enabled
  * [MYFACES-2502] - Component state is lost for composite component
childs of facets relocated by composite:insertChildren or
composite:insertFacet
  * [MYFACES-2503] - f:event should support no arg method on listener attribute
  * [MYFACES-2511] - Handle
javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR correctly
  * [MYFACES-2512] - Ensure invocation of nextHandler.apply() in
ValidatorTagHandlerDelegate when in wrapping-mode
  * [MYFACES-2514] - An empty default-validators in faces-config
should disable default validators
  * [MYFACES-2518] - BeanValidator should not be installed if bean
validation is not available
  * [MYFACES-2519] - f:event could be registered twice if it is child
of UIViewRoot
  * [MYFACES-2524] - Change ExternalSpecifications to enable using it
in automated tests
  * [MYFACES-2538] - Remove resourceVersion and libraryVersion from
resource identifiers

regards,

Leonardo Uribe



-- 
Matthias Wessendorf

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

Re: [core] Backwards compatibility (e.g. MYFACES-2543)

Yes.- this is a BUG it needs to support more than just 2.0
(Dan/Ed commented on the open list)

-Matthias

On Thu, Feb 11, 2010 at 2:35 PM, Matthias Wessendorf mat...@apache.org wrote:
 nope, but the web.xml setting for Trinidad's alternate view handler;

 it is complaining about the facelets embedded faces-config

 -Matthias

 On Thu, Feb 11, 2010 at 2:22 PM, Jakob Korherr jakob.korh...@gmail.com 
 wrote:
 have you installed the com.sun.facelets.FaceletViewHandler in faces-config?
 and which error did you get?


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

 @ javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER

 I tried (Glassfish v3) to deploy a JSF 1.2 application (with Facelets
 1.1.14) and that javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER
 parameter == true;

 I get an error there as well :-)

 -Matthias

 On Wed, Feb 10, 2010 at 11:08 AM, Jakob Korherr jakob.korh...@gmail.com
 wrote:
  No I have not filed any bugs. Feel free to file them ;)
 
  Regards,
  Jakob
 
  2010/2/10 Matthias Wessendorf mat...@apache.org
 
  On Wed, Feb 10, 2010 at 10:44 AM, Ganesh gan...@j4fry.org wrote:
   IMHO the spec is very clear about this and the stuff in the appendix
   is
   a
   spec bug. From the spec (10.1.2):
  
   A decision was made early in this process to strive for backwards
   compatibility between the latest popular version of Facelets and
   Facelets in
   JSF 2.0. The sole determinant to backwards compatibility lies in the
   answer
   to the question, “is there any Java code in the application, or in
   libraries
   used by the application, that extends from or depends on any class in
   package com.sun.facelets and/or its sub-packages?”
   ■ If the answer to this question is “yes”, Facelets in JSF 2.0 is not
   backwards compatibile with Facelets and such an application must
   continue to
   bundle the Facelets jar file along with the application, continue to
   set
   the
   Facelets configuration parameters, and also set the
   javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER
   context-param to true. Please see Section 11.1.3 “Application
   Configuration Parameters” for details on this
   option. Any code that extends or depends on any class in package
   com.sun.facelets and/or its sub-packages
   must be modified to depend on the appropriate classes in package
   javax.faces.webapp.vdl and/or its subpackages.
 
  yes (see previous email(s))
 
 
   ■ If the answer to this question is “no”, Facelets in JSF 2.0 is
   backwards
   compatible with pre-JSF 2.0 Facelets and such an application must not
   continue to bundle the Facelets jar file along with the application,
   and
   must not continue to set the Facelets configuration parameters.
   Thankfully, most applications that use Facelets fall into the latter
   category, or, if they fall in the former, their dependence will
   easily
   be
   migrated to the new public classes.
 
  ok. please; file a bug on that appendix thing.
 
  thjx
  -m
 
  
   Best regards,
   Ganesh
  
   Matthias Wessendorf schrieb:
  
   On Wed, Feb 10, 2010 at 6:26 AM, Ganesh gan...@j4fry.org wrote:
  
   Many Facelets taglibs don't use Facelets tag handlers,
   but simply wrap some xhtml templates. Nothing will stop these
   libraries
   to
   work with MyFaces if we allow old version taglibs.
   If we insist on refusing them people will simply switch to Mojarra
   to
   get
   their application to run.
  
   I know; that's what I meant with my comment before
  
   The argument of a xsd:restriction in the spec will
   help little. Just
   taking old Facelets is *not* a solution, because the
   rest of the application may want to use the new features.
   Please try filing this as a bug to Mojarra as Matthias
   proposed - if they fix it, MyFaces may insist on version=2.0, but
   if
   they
   don't I think we shouldn't
   either.
  
   I agree
  
   I've carried the question whether a JSF 2.0 compatible
   implementation
   is
   required to refuse old version facelets taglibs into the EG - let's
   see,
   what they have to say
  
   technically, I think now we are correct.
  
   @Jakob: Did you create such a bug against the RI ?
   (that they allow old Facelets) maybe another on
   not being (too) clear in the spec about it...
   -Matthias
  
   on this ...
  
   Best regards,
   Ganesh
  
   I see both ways; I think I don't like the fact that the RI has
   this
   bug
   :)
   So, end of the story is, almost everybody will blame this to us
   ;-)
   Oh, crappy MyFaces doesn't work etc :) All the FUD! :)
  
  
  
  
 
 
 
  --
  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

MYFACES-2564

Hey Michael,

I closed your MYFACES-2564 ticket, as we discussed this already.
There is another open ticket for the problem

-Matthias

-- 
Matthias Wessendorf

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

Re: MYFACES-2564

On Thu, Feb 18, 2010 at 6:05 PM, Jakob Korherr jakob.korh...@gmail.com wrote:
 I just reopend the issue, because it has nothing to do with the facelets
 taglibs version problem as Michael said.

:-) I just saw ...If the answer to this question is no, Facelets in
JSF 2
and closed it :-)


 However the changes are incorrect. Please see my comment in jira and please
 revert the changes.

 Regards,
 Jakob

 2010/2/18 Michael Concini mconc...@gmail.com

 I'm aware of the previous discussion, however my understanding was that it
 related more to supporting the using the legacy facelets library and doesn't
 appear to have anything to do with faces-config versioning.

 My fix in MYFACES-2564 just brings us into consistent behavior with how
 verseion info in config files are supposed to be treated.  As I've been made
 to understand it, they are only for use in schema validation and not for use
 in determining which runtime behaviors are supported.

 -Mike

 On 2/18/2010 11:10 AM, Matthias Wessendorf wrote:

 Hey Michael,

 I closed your MYFACES-2564 ticket, as we discussed this already.
 There is another open ticket for the problem

 -Matthias








-- 
Matthias Wessendorf

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

Re: Result (was: [VOTE] release for myfaces core 2.0.0-beta-2)

yeah! :)

On Thu, Feb 18, 2010 at 9:27 PM, Leonardo Uribe lu4...@gmail.com wrote:
 Hi

 Thanks to all people who vote.

 We have 7 +1

 Bernd Bohmann
 Gerhard Petracek
 Matthias Wessendorf
 Grant Smith
 Werner Punz
 Jakob Korherr
 Leonardo Uribe

 so we can continue with the necessary steps to release myfaces core
 2.0.0-beta-2

 regards,

 Leonardo Uribe





-- 
Matthias Wessendorf

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

Re: Dependency on javax.validation*

and here the ticket goes:

https://issues.apache.org/jira/browse/OWB-286

-Matthias

On Thu, Feb 18, 2010 at 11:29 AM, Matthias Wessendorf mat...@apache.org wrote:
 hi,

 deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the
 following exception.

 I understand that JavaEE has some requirement on this, but I actually
 don't care about
 JSR 303 (in this scenario).

 Should there be a more lenient way? E.g. logging a WARNING ?
 IMO this also cause trouble when one want's to use OWB on older app-servers.

 My (little) project is here:
 https://facesgoodies.googlecode.com/svn/MS/trunk

 run = mvn -Pmyfaces



 java.lang.NoClassDefFoundError: javax/validation/Validator
        at 
 org.apache.webbeans.component.javaee.ValidatorBean.init(ValidatorBean.java:36)
        at 
 org.apache.webbeans.config.BeansDeployer.configureDefaultBeans(BeansDeployer.java:196)
        at 
 org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:137)
        at 
 org.apache.webbeans.lifecycle.DefaultLifecycle.applicationStarted(DefaultLifecycle.java:202)
        at 
 org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:60)
        at 
 org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
        at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
        at 
 org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239)
        at 
 org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
        at 
 org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466)
        at 
 org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124)
        at 
 org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at 
 org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
        at 
 org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
        at 
 org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at 
 org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
        at 
 org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at 
 org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
        at org.mortbay.jetty.Server.doStart(Server.java:224)
        at 
 org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at 
 org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
        at 
 org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441)
        at 
 org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383)
        at 
 org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210)
        at 
 org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184)
        at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
        at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
        at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
        at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
        at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
        at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
        at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
        at 
 org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: java.lang.ClassNotFoundException: javax.validation.Validator
        at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190

Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator

On Thu, Feb 18, 2010 at 2:24 PM, Gurkan Erdogdu
cgurkanerdo...@gmail.com wrote:
Pretty harsh :-)
 Not intended :)

I know; it wasn't you that wrote the spec :-)


he 299 spec _require_ validator API
 Yes. Look at specification 3.6 Additional Beans

does weld (candi) also have this *hard* dependency on the
javax.validation API ?
 For weld -- yes
 http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java
 http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml

it says optionaltrue/optional :-)

-Matthias


 Thanks;

 --Gurkan

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

 Pretty harsh :-)

 IMO JSF2 is doing better here.
 It just checks if the dependency in question (yeah, javax.validation) is
 present
 if not = don't bother...
 But... I have to say that JSF 2.0 was released _before_ the JAvaEE6
 was available.

 I understand your motivation for closing the ticket, but I wonder if
 there actual
 interest in solving this in a more convenient way.

 Regarding JSF2 and Validation API:
 Not only JSF2 was there _before_ JavaEE6. Playing nice here is a
  gained experience when targeting a JAva EE platform (kinda)
 independent release;

 Interesting q:
 -the 299 spec _require_ validator API

 if yes = OK :)

 If no =
 -does weld (candi) also have this *hard* dependency on the
 javax.validation API ?

 -Matthias

 On Thu, Feb 18, 2010 at 2:00 PM, Gurkan Erdogdu
 cgurkanerdo...@gmail.com wrote:
  I have remarked several times about issues related with Java EE 6
  dependencies. I emphasize the fact that JSR-299 is a Java EE 6
 specification
  not for Jetty, Tomcat or any other containers that is not Java EE 6. But
 we
  are doing the best to run it possible on those containers.
 
  But we must not create plugins for every Java EE service dependency
 because
  of this does not work in some containers that are not Java EE 6
 compatible.
 
  Therefore, if you would like to use it you have to add validation-api or
 any
  dependent api to your container. In our samples we add those dependent
 Java
  EE dependencies to our WEB-INF/lib.
 
  Therefore this is not a bug, I will close this issue.
 
  2010/2/18 Mark Struberg (JIRA) j...@apache.org
 
 
     [
 
 https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835162#action_12835162
 ]
 
  Mark Struberg commented on OWB-286:
  ---
 
  too bad, this slipped into webbeans-core.
  We have to move all this stuff into an own plugin.
 
   java.lang.NoClassDefFoundError: javax/validation/Validator
   --
  
                   Key: OWB-286
                   URL: https://issues.apache.org/jira/browse/OWB-286
               Project: OpenWebBeans
            Issue Type: Bug
              Reporter: Matthias Weßendorf
              Assignee: Gurkan Erdogdu
  
   deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the
   following exception.
   I understand that JavaEE has some requirement on this, but I actually
   don't care about
   JSR 303 (in this scenario).
   Should there be a more lenient way? E.g. logging a WARNING ?
   IMO this also cause trouble when one want's to use OWB on older
  app-servers.
   My (little) project is here:
   https://facesgoodies.googlecode.com/svn/MS/trunk
   run = mvn -Pmyfaces
   java.lang.NoClassDefFoundError: javax/validation/Validator
          at
 
 org.apache.webbeans.component.javaee.ValidatorBean.init(ValidatorBean.java:36)
          at
 
 org.apache.webbeans.config.BeansDeployer.configureDefaultBeans(BeansDeployer.java:196)
          at
  org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:137)
          at
 
 org.apache.webbeans.lifecycle.DefaultLifecycle.applicationStarted(DefaultLifecycle.java:202)
          at
 
 org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:60)
          at
 
 org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
          at
  org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
          at
 
 org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239)
          at
 
 org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
          at
  org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466)
          at
 
 org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124)
          at
  org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
          at
 
 org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
          at
 
 org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
          at
  org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50

Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator

exactly

On Thu, Feb 18, 2010 at 3:40 PM, Joseph Bergmark bergm...@apache.org wrote:
I agree that the 3rd and 4th bullets in 3.6 make this a hard requirement.

It seems the tradeoff to me is:
1) Additional complexity of another plugin based approach to avoid this
scenario.
or
2) Handling of the CNF exception inside OWB with a warning message

vs.

The user having to bundle an API jar they don't necessarily care about
inside their application when running in a not full JEE environment.

While the latter doesn't seem like a huge burden, I've seen cases where
users have dozens on API jars inside their application and sometimes they
don't even know why or what side affects that may cause when they later run
inside a JEE environment and start changing classloader settings.

one benefit of ranting in comments :-)
users better get that, but I agree with a ton of (lame) dependencies
it can be come quite un-handy.

http://facesgoodies.googlecode.com/svn/MS/trunk/pom.xml

==
!--
This is a lame dependency, required by the JSR 299 specification.
Not the fault of Apache OWB, but we have to have this here in order to
be able to use Apache OWB outside of the typical EE realm. (Yes here in
Jetty).
--
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-validation_1.0_spec/artifactId
version1.0/version
scoperuntime/scope
/dependency
==

Sincerely,

Joe

On Thu, Feb 18, 2010 at 8:24 AM, Gurkan Erdogdu
cgurkanerdo...@gmail.comwrote:

Pretty harsh :-)
Not intended :)

he 299 spec _require_ validator API
Yes. Look at specification 3.6 Additional Beans

does weld (candi) also have this *hard* dependency on the
javax.validation API ?
For weld -- yes

http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java
http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml

Thanks;

--Gurkan

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

Pretty harsh :-)

IMO JSF2 is doing better here.
It just checks if the dependency in question (yeah, javax.validation) is
present
if not = don't bother...
But... I have to say that JSF 2.0 was released _before_ the JAvaEE6
was available.

I understand your motivation for closing the ticket, but I wonder if
there actual
interest in solving this in a more convenient way.

Regarding JSF2 and Validation API:
Not only JSF2 was there _before_ JavaEE6. Playing nice here is a
gained experience when targeting a JAva EE platform (kinda)
independent release;

Interesting q:
-the 299 spec _require_ validator API

if yes = OK :)

If no =
-does weld (candi) also have this *hard* dependency on the
javax.validation API ?

-Matthias

On Thu, Feb 18, 2010 at 2:00 PM, Gurkan Erdogdu
cgurkanerdo...@gmail.com wrote:
I have remarked several times about issues related with Java EE 6
dependencies. I emphasize the fact that JSR-299 is a Java EE 6
specification
not for Jetty, Tomcat or any other containers that is not Java EE 6.
But
we
are doing the best to run it possible on those containers.

But we must not create plugins for every Java EE service dependency
because
of this does not work in some containers that are not Java EE 6
compatible.

Therefore, if you would like to use it you have to add validation-api
or
any
dependent api to your container. In our samples we add those dependent
Java
EE dependencies to our WEB-INF/lib.

Therefore this is not a bug, I will close this issue.

2010/2/18 Mark Struberg (JIRA) j...@apache.org

[

https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835162#action_12835162
]

Mark Struberg commented on OWB-286:
---

too bad, this slipped into webbeans-core.
We have to move all this stuff into an own plugin.

java.lang.NoClassDefFoundError: javax/validation/Validator
--

Key: OWB-286
URL: https://issues.apache.org/jira/browse/OWB-286
Project: OpenWebBeans
Issue Type: Bug
Reporter: Matthias Weßendorf
Assignee: Gurkan Erdogdu

deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the
following exception.
I understand that JavaEE has some requirement on this, but I
actually
don't care about
JSR 303 (in this scenario).
Should there be a more lenient way? E.g. logging a WARNING ?
IMO this also cause trouble when one want's to use OWB on older
app-servers.
My (little) project is here:
https://facesgoodies.googlecode.com/svn/MS/trunk
run = mvn -Pmyfaces
java.lang.NoClassDefFoundError: javax/validation/Validator

Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator

On Thu, Feb 18, 2010 at 4:52 PM, Mark Struberg strub...@yahoo.de wrote:
I don't buy this.

The only Validator imports in weld are under the
main/java/org/jboss/weld/bean/builtin/ee/ and this whole package imo only
get's used (and classloaded) if you are running in an EE container. At least
that's how I remember that it used to be half a year ago when I looked at
weld sources the last time.

Also, I don't really care what weld is doing! If we have a way to do this
better, then we should do it!

So please don't close it, but I agree that this is not a 'bug' and we should
change this to 'feature', ok?
It would make another really cool OWB feature!

not only a cool feature. Actually playing nice with customers (the
guys that are supposed to use OWB ;-) )

LieGrue,
strub

--- Gurkan Erdogdu cgurkanerdo...@gmail.com schrieb am Do, 18.2.2010:

Von: Gurkan Erdogdu cgurkanerdo...@gmail.com
Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError:
javax/validation/Validator
An: dev@openwebbeans.apache.org
Datum: Donnerstag, 18. Februar, 2010 14:33 Uhr
it says
optionaltrue/optional :-)
Optional because runtime environment provides this :) IF
there is no
validation-api it throws ClassNFException as you have got.

It means that, if you provide scope as optional and your
maven project use
it, its optional dependency does not transitively passed to
using project.
You have to provide explicitly this dependency.

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

On Thu, Feb 18, 2010 at 2:24 PM, Gurkan Erdogdu
cgurkanerdo...@gmail.com
wrote:
Pretty harsh :-)
Not intended :)

I know; it wasn't you that wrote the spec :-)

he 299 spec _require_ validator API
Yes. Look at specification 3.6 Additional Beans

does weld (candi) also have this
*hard* dependency on the
javax.validation API ?
For weld -- yes

http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java
http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml

it says optionaltrue/optional :-)

-Matthias

Thanks;

--Gurkan

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

Pretty harsh :-)

IMO JSF2 is doing better here.
It just checks if the dependency in question
(yeah, javax.validation) is
present
if not = don't bother...
But... I have to say that JSF 2.0 was
released _before_ the JAvaEE6
was available.

I understand your motivation for closing the
ticket, but I wonder if
there actual
interest in solving this in a more convenient
way.

Regarding JSF2 and Validation API:
Not only JSF2 was there _before_ JavaEE6.
Playing nice here is a
gained experience when targeting a JAva
EE platform (kinda)
independent release;

Interesting q:
-the 299 spec _require_ validator API

if yes = OK :)

If no =
-does weld (candi) also have this *hard*
dependency on the
javax.validation API ?

-Matthias

On Thu, Feb 18, 2010 at 2:00 PM, Gurkan
Erdogdu
cgurkanerdo...@gmail.com
wrote:
I have remarked several times about
issues related with Java EE 6
dependencies. I emphasize the fact that
JSR-299 is a Java EE 6
specification
not for Jetty, Tomcat or any other
containers that is not Java EE 6.
But
we
are doing the best to run it possible on
those containers.

But we must not create plugins for every
Java EE service dependency
because
of this does not work in some containers
that are not Java EE 6
compatible.

Therefore, if you would like to use it
you have to add validation-api
or
any
dependent api to your container. In our
samples we add those dependent
Java
EE dependencies to our WEB-INF/lib.

Therefore this is not a bug, I will
close this issue.

2010/2/18 Mark Struberg (JIRA) j...@apache.org

[

https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835162#action_12835162
]

Mark Struberg commented on OWB-286:
---

too bad, this slipped into
webbeans-core.
We have to move all this stuff into
an own plugin.

java.lang.NoClassDefFoundError:
javax/validation/Validator

Key: OWB-286

URL: https://issues.apache.org/jira/browse/OWB-286

Project: OpenWebBeans

Issue Type: Bug

Reporter: Matthias Weßendorf

Assignee: Gurkan Erdogdu

Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator

+1 on Log4j

Not sure on the WebbeansLogger (would need to see the code, before
rating in here)
I usually tend to add some more convenient methods on-top of jul.

-Matthias

On Thu, Feb 18, 2010 at 6:58 PM, Joseph Bergmark bergm...@apache.org wrote:
+1, but I'm not sure I see the need to remove WebbeansLogger. That provides
an abstraction layer on top of whatever logging technology you want to use,
which may make switching loggers easier if we needed to in the future. The
only down side to the current WebBeansLogger is that the methods are tied
pretty closely to log4j logging levels.

Sincerely,

Joe

On Thu, Feb 18, 2010 at 12:37 PM, Mark Struberg strub...@yahoo.de wrote:

Hi Paul!

+1 and please let's get rid of our WebbeansLogger, since this layer
actually hides the _real_ source of the logging :/

LieGrue,
strub

--- Paul J. Reder rede...@remulak.net schrieb am Do, 18.2.2010:

Von: Paul J. Reder rede...@remulak.net
Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError:
javax/validation/Validator
An: dev@openwebbeans.apache.org
Datum: Donnerstag, 18. Februar, 2010 18:11 Uhr
Slightly off-topic, but along these
same lines...

While working on the logging patches I've submitted, I
noticed that OWB uses
log4j instead of JDK logging (thus requiring log4j to be
pulled in - the link
to current topic). Is there a specific reason we're using
log4j? Could
I submit a patch to migrate to using the JDK logger that is
already present?

If that is acceptable then I will open a separate JIRA
issue and continue
discussion there.

Thanks,

Paul J. Reder

On 02/18/2010 11:07 AM, Matthias Wessendorf wrote:
On Thu, Feb 18, 2010 at 4:52 PM, Mark Strubergstrub...@yahoo.de
wrote:
I don't buy this.

The only Validator imports in weld are under the
main/java/org/jboss/weld/bean/builtin/ee/ and this whole
package imo only get's used (and classloaded) if you are
running in an EE container. At least that's how I remember
that it used to be half a year ago when I looked at weld
sources the last time.

Also, I don't really care what weld is doing! If
we have a way to do this better, then we should do it!

So please don't close it, but I agree that this is
not a 'bug' and we should change this to 'feature', ok?
It would make another really cool OWB feature!

not only a cool feature. Actually playing nice with
customers (the
guys that are supposed to use OWB ;-) )

LieGrue,
strub

--- Gurkan Erdogducgurkanerdo...@gmail.com
schrieb am Do, 18.2.2010:

Von: Gurkan Erdogducgurkanerdo...@gmail.com
Betreff: Re: [jira] Commented: (OWB-286)
java.lang.NoClassDefFoundError:
javax/validation/Validator
An: dev@openwebbeans.apache.org
Datum: Donnerstag, 18. Februar, 2010 14:33
Uhr
it says
optionaltrue/optional
:-)
Optional because runtime environment provides
this :) IF
there is no
validation-api it throws ClassNFException as
you have got.

It means that, if you provide scope as
optional and your
maven project use
it, its optional dependency does not
transitively passed to
using project.
You have to provide explicitly this
dependency.

2010/2/18 Matthias Wessendorfmat...@apache.org

On Thu, Feb 18, 2010 at 2:24 PM, Gurkan
Erdogdu
cgurkanerdo...@gmail.com
wrote:
Pretty harsh :-)
Not intended :)

I know; it wasn't you that wrote the spec
:-)

he 299 spec _require_
validator API
Yes. Look at specification 3.6
Additional Beans

does weld (candi) also
have this
*hard* dependency on the
javax.validation API ?
For weld -- yes

http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java
http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml

it
saysoptionaltrue/optional :-)

-Matthias

Thanks;

--Gurkan

2010/2/18 Matthias Wessendorfmat...@apache.org

Pretty harsh :-)

IMO JSF2 is doing better here.
It just checks if the dependency
in question
(yeah, javax.validation) is
present
if not = don't
bother...
But... I have to say that JSF 2.0
was
released _before_ the JAvaEE6
was available.

I understand your motivation for
closing the
ticket, but I wonder if
there actual
interest in solving this in a more
convenient
way.

Regarding JSF2 and Validation
API:
Not only JSF2 was there _before_
JavaEE6.
Playing nice here is a
gained experience
when targeting a JAva
EE platform (kinda)
independent release;

Interesting q:
-the 299 spec _require_ validator
API

if yes = OK :)

If no =
-does weld (candi) also have this
*hard*
dependency on the
javax.validation API ?

-Matthias

On Thu, Feb 18, 2010 at 2:00 PM,
Gurkan
Erdogdu
cgurkanerdo

Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator

eh... I mean, I am always in fav of using jul (java.util.logging).
In myfaces we also try to get rid of log4j :-)

As Mark said jul is OK, but has some downsides, therefore I usually
create a tiny logger abstraction on-top of it...

-Matthias

On Thu, Feb 18, 2010 at 8:31 PM, Matthias Wessendorf mat...@apache.org wrote:
+1 on Log4j

Not sure on the WebbeansLogger (would need to see the code, before
rating in here)
I usually tend to add some more convenient methods on-top of jul.

-Matthias

Sincerely,

Joe

On Thu, Feb 18, 2010 at 12:37 PM, Mark Struberg strub...@yahoo.de wrote:

Hi Paul!

+1 and please let's get rid of our WebbeansLogger, since this layer
actually hides the _real_ source of the logging :/

LieGrue,
strub

--- Paul J. Reder rede...@remulak.net schrieb am Do, 18.2.2010:

If that is acceptable then I will open a separate JIRA
issue and continue
discussion there.

Thanks,

Paul J. Reder

On 02/18/2010 11:07 AM, Matthias Wessendorf wrote:
On Thu, Feb 18, 2010 at 4:52 PM, Mark Strubergstrub...@yahoo.de
wrote:
I don't buy this.

The only Validator imports in weld are under the
main/java/org/jboss/weld/bean/builtin/ee/ and this whole
package imo only get's used (and classloaded) if you are
running in an EE container. At least that's how I remember
that it used to be half a year ago when I looked at weld
sources the last time.

Also, I don't really care what weld is doing! If
we have a way to do this better, then we should do it!

So please don't close it, but I agree that this is
not a 'bug' and we should change this to 'feature', ok?
It would make another really cool OWB feature!

not only a cool feature. Actually playing nice with
customers (the
guys that are supposed to use OWB ;-) )

LieGrue,
strub

--- Gurkan Erdogducgurkanerdo...@gmail.com
schrieb am Do, 18.2.2010:

Von: Gurkan Erdogducgurkanerdo...@gmail.com
Betreff: Re: [jira] Commented: (OWB-286)
java.lang.NoClassDefFoundError:
javax/validation/Validator
An: dev@openwebbeans.apache.org
Datum: Donnerstag, 18. Februar, 2010 14:33
Uhr
it says
optionaltrue/optional
:-)
Optional because runtime environment provides
this :) IF
there is no
validation-api it throws ClassNFException as
you have got.

It means that, if you provide scope as
optional and your
maven project use
it, its optional dependency does not
transitively passed to
using project.
You have to provide explicitly this
dependency.

2010/2/18 Matthias Wessendorfmat...@apache.org

On Thu, Feb 18, 2010 at 2:24 PM, Gurkan
Erdogdu
cgurkanerdo...@gmail.com
wrote:
Pretty harsh :-)
Not intended :)

I know; it wasn't you that wrote the spec
:-)

he 299 spec _require_
validator API
Yes. Look at specification 3.6
Additional Beans

does weld (candi) also
have this
*hard* dependency on the
javax.validation API ?
For weld -- yes

http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java
http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml

it
saysoptionaltrue/optional :-)

-Matthias

Thanks;

--Gurkan

2010/2/18 Matthias Wessendorfmat...@apache.org

Pretty harsh :-)

IMO JSF2 is doing better here.
It just checks if the dependency
in question
(yeah, javax.validation) is
present
if not = don't
bother...
But... I have to say that JSF 2.0
was
released _before_ the JAvaEE6
was available.

I understand your motivation for
closing the
ticket, but I wonder if
there actual
interest in solving this in a more
convenient
way.

Regarding JSF2 and Validation
API:
Not only JSF2 was there _before_
JavaEE6.
Playing nice here is a
gained experience
when targeting a JAva
EE

[Maven] release procedure and nexus

2010-02-17 Thread Matthias Wessendorf

Hi,

I read up on this:
http://maven.apache.org/developers/release/apache-release.html

I am wondering what folks think about moving bit over to that
procedure (including Nexus as repository manager).

= http://repository.apache.org

We'd need to file a sub-task of this jira ticket:
http://issues.apache.org/jira/browse/INFRA-1896

To me it is not entirely clear if that would mean to deployment to
people.apache.org

-- 
Matthias Wessendorf

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

Re: [VOTE] codi as a new myfaces extensions sub-project

+1

On Tue, Feb 16, 2010 at 12:00 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
 +1
 regards,
 gerhard
 http://www.irian.at

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

 Professional Support for Apache MyFaces


 2010/2/16 Gerhard Petracek gpetra...@apache.org

 hi @ all,
 we have collected a lot of possible features for ext-cdi/codi and we have
 several people who are interested in working on it [1].
 so we should vote about the new module officially.

 ---
 [ ] +1 for: codi should become a myfaces extensions sub-project
 [ ] +0
 [ ] -1 for: codi shouldn't become a myfaces extensions sub-project

 ---
 the module should be hosted at [2].
 i think we have a clear winner for the name: MyFaces CODI
 (svn and jira will use (ext-)cdi to be consistent with the other extension
 modules.)
 regards,
 gerhard
 [1] http://wiki.apache.org/myfaces/Extensions/CDI/DevDoc/Drafts
 [2] http://svn.apache.org/repos/asf/myfaces/extensions/cdi/
 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

RESULT - Re: [VOTE] Release of Trinidad 2.0.0-alpha2

Thx for voting.

We got 4 votes, all +1:
-Matthias Wessendorf
-Max Starets
-Gerhard Petracek
-Gabrielle Crawford

I will run the final steps to get this release out

-Matthias

On Fri, Feb 12, 2010 at 7:35 PM, Gabrielle Crawford
gabrielle.crawf...@oracle.com wrote:
 +1

 Gerhard Petracek wrote:

 +1

 regards,
 gerhard

 http://www.irian.at

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

 Professional Support for Apache MyFaces


 2010/2/12 Matthias Wessendorf mat...@apache.org
 mailto:mat...@apache.org

    +1

    On Fri, Feb 12, 2010 at 3:15 PM, Matthias Wessendorf
    mat...@apache.org mailto:mat...@apache.org wrote:
     Hi,
    
     I was running the needed tasks to get the second alpha release
    of the Apache
     MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my
    private
     Apache account ([1]). The distribution is located at [2].
    
     Please take a look at the 2.0.0-alpha2 artifacts and vote
    
     
     [ ] +1 for community members who have reviewed the bits
     [ ] +0
     [ ] -1 for fatal flaws that should cause these bits not to be
    released,
      and why..
     
    
     Thanks,
     Matthias
    
     [1] http://people.apache.org/~matzew/staging_repo/
    http://people.apache.org/%7Ematzew/staging_repo/
     [2] http://people.apache.org/~matzew/trinidad-2.0.0-alpha2_dist/
    http://people.apache.org/%7Ematzew/trinidad-2.0.0-alpha2_dist/
    
     --
     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: [Vote] Trinidad plugins 2.0.1 release

Thx for voting.

We got 3 votes, all +1:
-Matthias Wessendorf
-Max Starets
-Gerhard Petracek

I will run the final steps to get this release out

-Matthias

On Fri, Feb 12, 2010 at 3:38 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
 +1
 regards,
 gerhard

 http://www.irian.at

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

 Professional Support for Apache MyFaces


 2010/2/12 Max Starets max.star...@oracle.com

 +1.


 Matthias Wessendorf wrote:

 Hi,

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

 yes, it contains this fix:
 https://issues.apache.org/jira/browse/TRINIDAD-1681

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

 Please take a look at the 2.0.1 artifacts and vote.

 How to test those JARs ?

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

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

 Thanks,
 Matthias

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








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

Thx for voting.

We got 3 votes, all +1:
-Matthias Wessendorf
-Max Starets
-Gerhard Petracek

I will run the final steps to get this release out

-Matthias

On Fri, Feb 12, 2010 at 3:19 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
 +1
 regards,
 gerhard

 http://www.irian.at

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

 Professional Support for Apache MyFaces


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

 +1

 On Thu, Feb 11, 2010 at 10:28 PM, Matthias Wessendorf mat...@apache.org
 wrote:
  Hi,
 
  I was running the needed tasks to get the 1.0.12 release of the Apache
  MyFaces Trinidad CORE out. The artifacts are deployed to my private
  Apache account ([1]). The distribution is located at [2].
 
  Please take a look at the 1.0.12 artifacts and vote
 
  
  [ ] +1 for community members who have reviewed the bits
  [ ] +0
  [ ] -1 for fatal flaws that should cause these bits not to be released,
   and why..
  
 
  Thanks,
  Matthias
 
  [1] http://people.apache.org/~matzew/staging_repo/
  [2] http://people.apache.org/~matzew/trinidad-1.0.12_dist/
 
  --
  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: [Vote] Trinidad plugins 1.2.12 release

Thx for voting.

We got 4 votes, all +1:
-Matthias Wessendorf
-Max Starets
-Leo Uribe
-Gabrielle Crawford

I will run the final steps to get this release out

-Matthias

On Thu, Feb 11, 2010 at 11:30 PM, Gabrielle Crawford
gabrielle.crawf...@oracle.com wrote:
 +1

 Matthias Wessendorf wrote:

 Hi,

 I was running the needed tasks to get the 1.2.12 release of the Apache
 MyFaces Trinidad Maven 2 Plugins.

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

 Please take a look at the 1.2.12 artifacts and vote.

 How to test those JARs ?

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

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

 Thanks,
 Matthias

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






-- 
Matthias Wessendorf

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

[ANN] Release of Apache MyFaces Trinidad's Maven plugins (1.2.12)

Hi,

The Apache MyFaces community is pleased to announce its
1.2.12 release of the Apache MyFaces Trinidad Maven2 plugins.

These Maven2 plugins have been deployed to the Apache Maven2 repository.
They are mirrored by ibiblio as well.

release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661styleName=Htmlversion=12314452

-- 
Matthias Wessendorf

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

[ANN] Release of Apache MyFaces Trinidad's Maven plugins (2.0.1)

Hi,

The Apache MyFaces community is pleased to announce its
2.0.1 release of the Apache MyFaces Trinidad Maven2 plugins.

This release contains support for the new JSF 2.0 related API/metadata.

These Maven2 plugins have been deployed to the Apache Maven2 repository and they
should be mirrored by ibiblio as well (very soon).

release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661styleName=Htmlversion=12314512

-- 
Matthias Wessendorf

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

[Announce] Release of Apache MyFaces Trinidad 2.0.0-alpha-2

The Apache MyFaces Trinidad team is pleased to announce the release of
Apache MyFaces Trinidad Core 2.0.0-alpha-2.

Apache MyFaces Trinidad 2 is a JavaServer(tm) Faces 2.0 component library.

Note: This is the second release of the Apache MyFaces Trinidad 2 series and it
is an alpha relases.

Apache MyFaces Trinidad Core 2.0.0-alpha-2 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=12314513

Enjoy!
Matthias


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

The Apache MyFaces Trinidad team is pleased to announce the release of
Apache MyFaces Trinidad Core 1.0.12.

Apache MyFaces Trinidad is a JavaServer(tm) Faces 1.1 component library.

Trinidad Core 1.0.12 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=12314137

Enjoy!

-- 
Matthias Wessendorf

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

[ANN] Release of Apache MyFaces Trinidad's Maven plugins (1.2.12)

Hi,

The Apache MyFaces community is pleased to announce its
1.2.12 release of the Apache MyFaces Trinidad Maven2 plugins.

These Maven2 plugins have been deployed to the Apache Maven2 repository.
They are mirrored by ibiblio as well.

release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661styleName=Htmlversion=12314452

-- 
Matthias Wessendorf

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

[ANN] Release of Apache MyFaces Trinidad's Maven plugins (2.0.1)

Hi,

The Apache MyFaces community is pleased to announce its
2.0.1 release of the Apache MyFaces Trinidad Maven2 plugins.

This release contains support for the new JSF 2.0 related API/metadata.

These Maven2 plugins have been deployed to the Apache Maven2 repository and they
should be mirrored by ibiblio as well (very soon).

release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661styleName=Htmlversion=12314512

-- 
Matthias Wessendorf

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

[Announce] Release of Apache MyFaces Trinidad 2.0.0-alpha-2

The Apache MyFaces Trinidad team is pleased to announce the release of
Apache MyFaces Trinidad Core 2.0.0-alpha-2.

Apache MyFaces Trinidad 2 is a JavaServer(tm) Faces 2.0 component library.

Note: This is the second release of the Apache MyFaces Trinidad 2 series and it
is an alpha relases.

Apache MyFaces Trinidad Core 2.0.0-alpha-2 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=12314513

Enjoy!
Matthias


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

The Apache MyFaces Trinidad team is pleased to announce the release of
Apache MyFaces Trinidad Core 1.0.12.

Apache MyFaces Trinidad is a JavaServer(tm) Faces 1.1 component library.

Trinidad Core 1.0.12 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=12314137

Enjoy!

-- 
Matthias Wessendorf

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

Re: [VOTE] release for myfaces core 2.0.0-beta-2

2010-02-15 Thread Matthias Wessendorf


+1

Sent from my iPod.

On 16.02.2010, at 01:20, Grant Smith work.gr...@gmail.com wrote:


+1

On Mon, Feb 15, 2010 at 12:41 PM, Werner Punz  
werner.p...@gmail.com wrote:

+1

Jakob Korherr schrieb:
+1

Regards,
Jakob

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

   +1

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



   Hi,

   I was running the needed tasks to get the 2.0.0-beta-2 release
   of Apache
   MyFaces core out.

   This artifacts are very close to pass all TCK tests.

   Please note that this vote concerns all of the following parts:
1. Maven artifact group org.apache.myfaces.shared
   v4.0.1-beta-2  [1]
2. Maven artifact group org.apache.myfaces.core
   v2.0.0-beta-2  [1]
3. Maven artifact group org.apache.myfaces.test v1.0.0- 
beta [1]


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

   [3] for binary and source packages).

   The release notes could be found at [4].

   Also the clirr test does not show binary incompatibilities with
   myfaces-api.

   Please take a look at the 2.0.0-beta-2 artifacts and vote!

   Please note: This vote is majority approval with a minimum of
   three
   +1 votes (see [3]).

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

   Thanks,
   Leonardo Uribe

   [1] http://people.apache.org/~lu4242/myfaces200beta2
   http://people.apache.org/%7Elu4242/myfaces200beta2

   [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
   [3] http://people.apache.org/~lu4242/myfaces200beta2binsrc
   http://people.apache.org/%7Elu4242/myfaces200beta2binsrc

   [4]
   
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314539
   https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314539 









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

[JSF2] spec issue ? (was: Trinidad 2 JIRA: TRINIDAD-1724)

2010-02-13 Thread Matthias Wessendorf

Hey guys,

background:
https://issues.apache.org/jira/browse/TRINIDAD-1724

Max, so you are saying the changed the API (XSD) file for the
facelettaglibrary
(not the faces-config, right?)

But the online version of it, simply lacks the method-signature:
http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd

So does the MyFaces 2 version of it:
http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/resources/org/apache/myfaces/resource/web-facelettaglibrary_2_0.xsd?view=log

So, not sure if there was some errata for this, but I guess we need to
add that to our MyFaces XSD as well.

So, let me file a myfaces bug...

Max/Andy:
Is one of you guys aware of a bug ticket, for when the RI added the
change to their facelettaglibrary?

-Matthias

-- 
Matthias Wessendorf

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

Re: [JSF2] spec issue ? (was: Trinidad 2 JIRA: TRINIDAD-1724)

2010-02-13 Thread Matthias Wessendorf

Ok,

here is the bug:
https://issues.apache.org/jira/browse/MYFACES-2554

-Matthias

On Sat, Feb 13, 2010 at 10:45 AM, Matthias Wessendorf mat...@apache.org wrote:
 Hey guys,

 background:
 https://issues.apache.org/jira/browse/TRINIDAD-1724

 Max, so you are saying the changed the API (XSD) file for the
 facelettaglibrary
 (not the faces-config, right?)

 But the online version of it, simply lacks the method-signature:
 http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd

 So does the MyFaces 2 version of it:
 http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/resources/org/apache/myfaces/resource/web-facelettaglibrary_2_0.xsd?view=log

 So, not sure if there was some errata for this, but I guess we need to
 add that to our MyFaces XSD as well.

 So, let me file a myfaces bug...

 Max/Andy:
 Is one of you guys aware of a bug ticket, for when the RI added the
 change to their facelettaglibrary?

 -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] 1.2.14 and new skin

Hey Catalin,

what is your take on the new skin? Is it stable enough for a 1.2.14 release?
I'd not mind to generate stuff for it over the weekend.

-Matthias

-- 
Matthias Wessendorf

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

Re: [Trinidad] 1.2.14 and new skin

or... we wait a bit.

On the 2.0.x branch, I currently disabled the demo (as a fyi)
But Skin I merged over! :)

-Matthias

On Fri, Feb 12, 2010 at 9:48 AM, Catalin Kormos
catalin.kor...@gmail.com wrote:
 Hi Matthias,

 The skin is stable enough, there are no big issues with, but we are
 currently working on improving the skinning for some of the
 components. I guess this shouldn't stop a release of Trinidad IMHO.

 regards,
 Catalin

 On 2/12/10, Matthias Wessendorf mat...@apache.org wrote:
 Hey Catalin,

 what is your take on the new skin? Is it stable enough for a 1.2.14 release?
 I'd not mind to generate stuff for it over the weekend.

 -Matthias

 --
 Matthias Wessendorf

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



 --
 
 Codebeat
 www.codebeat.ro




-- 
Matthias Wessendorf

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

[Trinidad2] current branches

Hi,

as a FYI (b/c some merging etc has been done):

The maven-plugins location is (still) here:
https://svn.apache.org/repos/asf/myfaces/trinidad-maven/branches/2.0.x-branch/

and the core is (still) here:
https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x/

However, both versions have been updated (as their pom.xml says)...

-Matthias

-- 
Matthias Wessendorf

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

Re: [Trinidad] 1.2.14 and new skin

kick ass! great!

On Fri, Feb 12, 2010 at 10:20 AM, Catalin Kormos
catalin.kor...@gmail.com wrote:
 Ok, let's wait a little bit :), we are working on fixing the component
 showcase on the 2.0.x also.

 On 2/12/10, Matthias Wessendorf mat...@apache.org wrote:
 or... we wait a bit.

 On the 2.0.x branch, I currently disabled the demo (as a fyi)
 But Skin I merged over! :)

 -Matthias

 On Fri, Feb 12, 2010 at 9:48 AM, Catalin Kormos
 catalin.kor...@gmail.com wrote:
 Hi Matthias,

 The skin is stable enough, there are no big issues with, but we are
 currently working on improving the skinning for some of the
 components. I guess this shouldn't stop a release of Trinidad IMHO.

 regards,
 Catalin

 On 2/12/10, Matthias Wessendorf mat...@apache.org wrote:
 Hey Catalin,

 what is your take on the new skin? Is it stable enough for a 1.2.14
 release?
 I'd not mind to generate stuff for it over the weekend.

 -Matthias

 --
 Matthias Wessendorf

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



 --
 
 Codebeat
 www.codebeat.ro




 --
 Matthias Wessendorf

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



 --
 
 Codebeat
 www.codebeat.ro




-- 
Matthias Wessendorf

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

[Vote] Trinidad plugins 2.0.1 release

Hi,

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

yes, it contains this fix:
https://issues.apache.org/jira/browse/TRINIDAD-1681

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

Please take a look at the 2.0.1 artifacts and vote.

How to test those JARs ?

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


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


Thanks,
Matthias

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

-- 
Matthias Wessendorf

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

Re: Trinidad: nightly builds

teh continuum has some *problems*

On Fri, Feb 12, 2010 at 10:59 AM, Mathias Walter mathias.wal...@gmx.net wrote:
 Hi,

 the last nightly build is from 9th of February. Why is there no newer nightly 
 build?

 --
 Kind regards
 Mathias





-- 
Matthias Wessendorf

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

Re: [Vote] Trinidad plugins 2.0.1 release

+1

On Fri, Feb 12, 2010 at 11:07 AM, Matthias Wessendorf mat...@apache.org wrote:
 Hi,

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

 yes, it contains this fix:
 https://issues.apache.org/jira/browse/TRINIDAD-1681

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

 Please take a look at the 2.0.1 artifacts and vote.

 How to test those JARs ?

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

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

 Thanks,
 Matthias

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

 --
 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: nightly builds

solved :), i committed that dependency a bit to fast ;-)
(the vote for it is on the dev@)

On Fri, Feb 12, 2010 at 11:17 AM, Mathias Walter mathias.wal...@gmx.net wrote:
 Hi again,

 Okay, Continuum has problems ... So I tried building Trinidad by myself with
 Maven 2.2.1. I'm sure it has worked a few month ago. But today I get the
 following warnings/errors:

 D:\Develop\Java\trinidadmvn -Dmaven.test.skip=true install
 [INFO] Scanning for projects...
 [INFO] Reactor build order:
 [INFO]   Apache MyFaces Trinidad 1.2
 [INFO]   Apache MyFaces Trinidad Build
 [INFO]   Apache MyFaces Trinidad API
 [INFO]   Apache MyFaces Trinidad Impl
 [INFO]   Apache MyFaces Trinidad Examples
 [INFO]   Apache MyFaces Trinidad Blank Demo
 [INFO]   Apache MyFaces Trinidad Demo
 [INFO]   Apache MyFaces Trinidad Components Showcase
 [INFO]
 
 [INFO] Building Apache MyFaces Trinidad 1.2
 [INFO]    task-segment: [install]
 [INFO]
 
 Downloading:
 http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trin
 idadbuild/maven-xrts-plugin/1.2.12/maven-xrts-plugin-1.2.12.pom
 [INFO] Unable to find resource
 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in
 repository apache.snapshots
 (http://people.apache.org/repo/m2-snapshot-repository)
 Downloading:
 http://repo1.maven.org/maven2/org/apache/myfaces/trinidadbuild/maven-xrts-pl
 ugin/1.2.12/maven-xrts-plugin-1.2.12.pom
 [INFO] Unable to find resource
 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in
 repository central (http://repo1.maven.org/maven2)
 Downloading:
 http://download.java.net/maven/1/org.apache.myfaces.trinidadbuild/poms/maven
 -xrts-plugin-1.2.12.pom
 [INFO] Unable to find resource
 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in
 repository java.net (http://download.java.net/maven/1)
 Downloading:
 http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trin
 idadbuild/maven-xrts-plugin/1.2.12/maven-xrts-plugin-1.2.12.pom
 [INFO] Unable to find resource
 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in
 repository apache.snapshots
 (http://people.apache.org/repo/m2-snapshot-repository)
 Downloading:
 http://repo1.maven.org/maven2/org/apache/myfaces/trinidadbuild/maven-xrts-pl
 ugin/1.2.12/maven-xrts-plugin-1.2.12.pom
 [INFO] Unable to find resource
 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in
 repository central (http://repo1.maven.org/maven2)
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] Error building POM (may not be this project's POM).


 Project ID: org.apache.myfaces.trinidadbuild:maven-xrts-plugin

 Reason: POM 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin' not found
 in repository: Unable to download the artifact from any repository

  org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12

 from the specified remote repositories:
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  central (http://repo1.maven.org/maven2),
  java.net (http://download.java.net/maven/1)

  for project org.apache.myfaces.trinidadbuild:maven-xrts-plugin


 What did I made wrong? Or is this problem related to the new Trinidad Maven
 plugins?

 --
 Kind regards,
 Mathias


 -Original Message-
 From: mwessend...@gmail.com [mailto:mwessend...@gmail.com] On Behalf Of
 Matthias Wessendorf
 Sent: Friday, February 12, 2010 11:08 AM
 To: MyFaces Development
 Subject: Re: Trinidad: nightly builds

 teh continuum has some *problems*

 On Fri, Feb 12, 2010 at 10:59 AM, Mathias Walter
 mathias.wal...@gmx.net wrote:
  Hi,
 
  the last nightly build is from 9th of February. Why is there no newer
 nightly build?
 
  --
  Kind regards
  Mathias
 
 



 --
 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: nightly builds

triggered the continuum; nightly is now from 2day

On Fri, Feb 12, 2010 at 11:23 AM, Matthias Wessendorf mat...@apache.org wrote:
 solved :), i committed that dependency a bit to fast ;-)
 (the vote for it is on the dev@)

 On Fri, Feb 12, 2010 at 11:17 AM, Mathias Walter mathias.wal...@gmx.net 
 wrote:
 Hi again,

 Okay, Continuum has problems ... So I tried building Trinidad by myself with
 Maven 2.2.1. I'm sure it has worked a few month ago. But today I get the
 following warnings/errors:

 D:\Develop\Java\trinidadmvn -Dmaven.test.skip=true install
 [INFO] Scanning for projects...
 [INFO] Reactor build order:
 [INFO]   Apache MyFaces Trinidad 1.2
 [INFO]   Apache MyFaces Trinidad Build
 [INFO]   Apache MyFaces Trinidad API
 [INFO]   Apache MyFaces Trinidad Impl
 [INFO]   Apache MyFaces Trinidad Examples
 [INFO]   Apache MyFaces Trinidad Blank Demo
 [INFO]   Apache MyFaces Trinidad Demo
 [INFO]   Apache MyFaces Trinidad Components Showcase
 [INFO]
 
 [INFO] Building Apache MyFaces Trinidad 1.2
 [INFO]    task-segment: [install]
 [INFO]
 
 Downloading:
 http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trin
 idadbuild/maven-xrts-plugin/1.2.12/maven-xrts-plugin-1.2.12.pom
 [INFO] Unable to find resource
 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in
 repository apache.snapshots
 (http://people.apache.org/repo/m2-snapshot-repository)
 Downloading:
 http://repo1.maven.org/maven2/org/apache/myfaces/trinidadbuild/maven-xrts-pl
 ugin/1.2.12/maven-xrts-plugin-1.2.12.pom
 [INFO] Unable to find resource
 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in
 repository central (http://repo1.maven.org/maven2)
 Downloading:
 http://download.java.net/maven/1/org.apache.myfaces.trinidadbuild/poms/maven
 -xrts-plugin-1.2.12.pom
 [INFO] Unable to find resource
 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in
 repository java.net (http://download.java.net/maven/1)
 Downloading:
 http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trin
 idadbuild/maven-xrts-plugin/1.2.12/maven-xrts-plugin-1.2.12.pom
 [INFO] Unable to find resource
 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in
 repository apache.snapshots
 (http://people.apache.org/repo/m2-snapshot-repository)
 Downloading:
 http://repo1.maven.org/maven2/org/apache/myfaces/trinidadbuild/maven-xrts-pl
 ugin/1.2.12/maven-xrts-plugin-1.2.12.pom
 [INFO] Unable to find resource
 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in
 repository central (http://repo1.maven.org/maven2)
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] Error building POM (may not be this project's POM).


 Project ID: org.apache.myfaces.trinidadbuild:maven-xrts-plugin

 Reason: POM 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin' not found
 in repository: Unable to download the artifact from any repository

  org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12

 from the specified remote repositories:
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  central (http://repo1.maven.org/maven2),
  java.net (http://download.java.net/maven/1)

  for project org.apache.myfaces.trinidadbuild:maven-xrts-plugin


 What did I made wrong? Or is this problem related to the new Trinidad Maven
 plugins?

 --
 Kind regards,
 Mathias


 -Original Message-
 From: mwessend...@gmail.com [mailto:mwessend...@gmail.com] On Behalf Of
 Matthias Wessendorf
 Sent: Friday, February 12, 2010 11:08 AM
 To: MyFaces Development
 Subject: Re: Trinidad: nightly builds

 teh continuum has some *problems*

 On Fri, Feb 12, 2010 at 10:59 AM, Mathias Walter
 mathias.wal...@gmx.net wrote:
  Hi,
 
  the last nightly build is from 9th of February. Why is there no newer
 nightly build?
 
  --
  Kind regards
  Mathias
 
 



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

[VOTE] Release of Trinidad 2.0.0-alpha2

Hi,

I was running the needed tasks to get the second alpha release of the Apache
MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private
Apache account ([1]). The distribution is located at [2].

Please take a look at the 2.0.0-alpha2 artifacts and vote


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


Thanks,
Matthias

[1] http://people.apache.org/~matzew/staging_repo/
[2] http://people.apache.org/~matzew/trinidad-2.0.0-alpha2_dist/

-- 
Matthias Wessendorf

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

Re: [VOTE] Release of Trinidad 2.0.0-alpha2

+1

On Fri, Feb 12, 2010 at 3:15 PM, Matthias Wessendorf mat...@apache.org wrote:
 Hi,

 I was running the needed tasks to get the second alpha release of the Apache
 MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private
 Apache account ([1]). The distribution is located at [2].

 Please take a look at the 2.0.0-alpha2 artifacts and vote

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

 Thanks,
 Matthias

 [1] http://people.apache.org/~matzew/staging_repo/
 [2] http://people.apache.org/~matzew/trinidad-2.0.0-alpha2_dist/

 --
 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] 1.2.14 and new skin

the trinidad-demo works
= cd to_the_dir;
mvn jetty:run -PjettyConfig



On Fri, Feb 12, 2010 at 3:27 PM, Marius Petoi marius.pe...@codebeat.ro wrote:
 Hello,

 I am trying to run the new demo with Trinidad 2.0. Unfortunately, nothing
 gets rendered. In web.xml, I use the following configuration for facelets:

 !-- Facelets configuration, comment to use JSP --

   context-param
     param-namejavax.faces.FACELETS_VIEW_MAPPINGS/param-name
     param-value*.xhtml/param-value
     !-- to run facelets for jspx files comment the line above and uncomment
 line below--
     !--param-value*.xhtml;*.jspx/param-value--

   /context-param

   context-param
     param-namejavax.faces.FACELETS_SKIP_COMMENTS/param-name
     param-valuetrue/param-value
   /context-param

   context-param
     param-namejavax.faces.FACELETS_LIBRARIES/param-name
     param-value/WEB-INF/tr-demo.taglib.xml/param-value
   /context-param

 Do you have any idea what other properties I should set? The TrinidadFilter
 gets entered, but no component is rendered. Do you, perhaps, have any
 example using facelets with Trinidad 2.0?

 Thank you!
 Marius

 On Fri, Feb 12, 2010 at 11:26 AM, Matthias Wessendorf mat...@apache.org
 wrote:

 kick ass! great!

 On Fri, Feb 12, 2010 at 10:20 AM, Catalin Kormos
 catalin.kor...@gmail.com wrote:
  Ok, let's wait a little bit :), we are working on fixing the component
  showcase on the 2.0.x also.
 
  On 2/12/10, Matthias Wessendorf mat...@apache.org wrote:
  or... we wait a bit.
 
  On the 2.0.x branch, I currently disabled the demo (as a fyi)
  But Skin I merged over! :)
 
  -Matthias
 
  On Fri, Feb 12, 2010 at 9:48 AM, Catalin Kormos
  catalin.kor...@gmail.com wrote:
  Hi Matthias,
 
  The skin is stable enough, there are no big issues with, but we are
  currently working on improving the skinning for some of the
  components. I guess this shouldn't stop a release of Trinidad IMHO.
 
  regards,
  Catalin
 
  On 2/12/10, Matthias Wessendorf mat...@apache.org wrote:
  Hey Catalin,
 
  what is your take on the new skin? Is it stable enough for a 1.2.14
  release?
  I'd not mind to generate stuff for it over the weekend.
 
  -Matthias
 
  --
  Matthias Wessendorf
 
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  twitter: http://twitter.com/mwessendorf
 
 
 
  --
  
  Codebeat
  www.codebeat.ro
 
 
 
 
  --
  Matthias Wessendorf
 
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  twitter: http://twitter.com/mwessendorf
 
 
 
  --
  
  Codebeat
  www.codebeat.ro
 



 --
 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] 1.2.14 and new skin

same here

On Fri, Feb 12, 2010 at 4:21 PM, Marius Petoi marius.pe...@codebeat.ro wrote:
 I'm talking about the 2.0 version of Trinidad...

 On Fri, Feb 12, 2010 at 4:30 PM, Matthias Wessendorf mat...@apache.org
 wrote:

 the trinidad-demo works
 = cd to_the_dir;
 mvn jetty:run -PjettyConfig



 On Fri, Feb 12, 2010 at 3:27 PM, Marius Petoi marius.pe...@codebeat.ro
 wrote:
  Hello,
 
  I am trying to run the new demo with Trinidad 2.0. Unfortunately,
  nothing
  gets rendered. In web.xml, I use the following configuration for
  facelets:
 
  !-- Facelets configuration, comment to use JSP --
 
    context-param
      param-namejavax.faces.FACELETS_VIEW_MAPPINGS/param-name
      param-value*.xhtml/param-value
      !-- to run facelets for jspx files comment the line above and
  uncomment
  line below--
      !--param-value*.xhtml;*.jspx/param-value--
 
    /context-param
 
    context-param
      param-namejavax.faces.FACELETS_SKIP_COMMENTS/param-name
      param-valuetrue/param-value
    /context-param
 
    context-param
      param-namejavax.faces.FACELETS_LIBRARIES/param-name
      param-value/WEB-INF/tr-demo.taglib.xml/param-value
    /context-param
 
  Do you have any idea what other properties I should set? The
  TrinidadFilter
  gets entered, but no component is rendered. Do you, perhaps, have any
  example using facelets with Trinidad 2.0?
 
  Thank you!
  Marius
 
  On Fri, Feb 12, 2010 at 11:26 AM, Matthias Wessendorf
  mat...@apache.org
  wrote:
 
  kick ass! great!
 
  On Fri, Feb 12, 2010 at 10:20 AM, Catalin Kormos
  catalin.kor...@gmail.com wrote:
   Ok, let's wait a little bit :), we are working on fixing the
   component
   showcase on the 2.0.x also.
  
   On 2/12/10, Matthias Wessendorf mat...@apache.org wrote:
   or... we wait a bit.
  
   On the 2.0.x branch, I currently disabled the demo (as a fyi)
   But Skin I merged over! :)
  
   -Matthias
  
   On Fri, Feb 12, 2010 at 9:48 AM, Catalin Kormos
   catalin.kor...@gmail.com wrote:
   Hi Matthias,
  
   The skin is stable enough, there are no big issues with, but we are
   currently working on improving the skinning for some of the
   components. I guess this shouldn't stop a release of Trinidad IMHO.
  
   regards,
   Catalin
  
   On 2/12/10, Matthias Wessendorf mat...@apache.org wrote:
   Hey Catalin,
  
   what is your take on the new skin? Is it stable enough for a
   1.2.14
   release?
   I'd not mind to generate stuff for it over the weekend.
  
   -Matthias
  
   --
   Matthias Wessendorf
  
   blog: http://matthiaswessendorf.wordpress.com/
   sessions: http://www.slideshare.net/mwessendorf
   twitter: http://twitter.com/mwessendorf
  
  
  
   --
   
   Codebeat
   www.codebeat.ro
  
  
  
  
   --
   Matthias Wessendorf
  
   blog: http://matthiaswessendorf.wordpress.com/
   sessions: http://www.slideshare.net/mwessendorf
   twitter: http://twitter.com/mwessendorf
  
  
  
   --
   
   Codebeat
   www.codebeat.ro
  
 
 
 
  --
  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] 1.2.14 and new skin

cool; so let's wait a bit


On Fri, Feb 12, 2010 at 7:00 PM, Mathias Walter mathias.wal...@gmx.net wrote:
 Hi,

 the skin has still a few bugs. I'll test it with different applications
 further.

 --
 Kind regards,
 Mathias


 -Original Message-
 From: mwessend...@gmail.com [mailto:mwessend...@gmail.com] On Behalf Of
 Matthias Wessendorf
 Sent: Friday, February 12, 2010 9:32 AM
 To: MyFaces Development
 Subject: [Trinidad] 1.2.14 and new skin

 Hey Catalin,

 what is your take on the new skin? Is it stable enough for a 1.2.14
 release?
 I'd not mind to generate stuff for it over the weekend.

 -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: [core] Backwards compatibility (e.g. MYFACES-2543)

@ javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER

I tried (Glassfish v3) to deploy a JSF 1.2 application (with Facelets
1.1.14) and that javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER
parameter == true;

I get an error there as well :-)

-Matthias

On Wed, Feb 10, 2010 at 11:08 AM, Jakob Korherr jakob.korh...@gmail.com wrote:
 No I have not filed any bugs. Feel free to file them ;)

 Regards,
 Jakob

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

 On Wed, Feb 10, 2010 at 10:44 AM, Ganesh gan...@j4fry.org wrote:
  IMHO the spec is very clear about this and the stuff in the appendix is
  a
  spec bug. From the spec (10.1.2):
 
  A decision was made early in this process to strive for backwards
  compatibility between the latest popular version of Facelets and
  Facelets in
  JSF 2.0. The sole determinant to backwards compatibility lies in the
  answer
  to the question, “is there any Java code in the application, or in
  libraries
  used by the application, that extends from or depends on any class in
  package com.sun.facelets and/or its sub-packages?”
  ■ If the answer to this question is “yes”, Facelets in JSF 2.0 is not
  backwards compatibile with Facelets and such an application must
  continue to
  bundle the Facelets jar file along with the application, continue to set
  the
  Facelets configuration parameters, and also set the
  javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER
  context-param to true. Please see Section 11.1.3 “Application
  Configuration Parameters” for details on this
  option. Any code that extends or depends on any class in package
  com.sun.facelets and/or its sub-packages
  must be modified to depend on the appropriate classes in package
  javax.faces.webapp.vdl and/or its subpackages.

 yes (see previous email(s))


  ■ If the answer to this question is “no”, Facelets in JSF 2.0 is
  backwards
  compatible with pre-JSF 2.0 Facelets and such an application must not
  continue to bundle the Facelets jar file along with the application, and
  must not continue to set the Facelets configuration parameters.
  Thankfully, most applications that use Facelets fall into the latter
  category, or, if they fall in the former, their dependence will easily
  be
  migrated to the new public classes.

 ok. please; file a bug on that appendix thing.

 thjx
 -m

 
  Best regards,
  Ganesh
 
  Matthias Wessendorf schrieb:
 
  On Wed, Feb 10, 2010 at 6:26 AM, Ganesh gan...@j4fry.org wrote:
 
  Many Facelets taglibs don't use Facelets tag handlers,
  but simply wrap some xhtml templates. Nothing will stop these
  libraries
  to
  work with MyFaces if we allow old version taglibs.
  If we insist on refusing them people will simply switch to Mojarra to
  get
  their application to run.
 
  I know; that's what I meant with my comment before
 
  The argument of a xsd:restriction in the spec will
  help little. Just
  taking old Facelets is *not* a solution, because the
  rest of the application may want to use the new features.
  Please try filing this as a bug to Mojarra as Matthias
  proposed - if they fix it, MyFaces may insist on version=2.0, but if
  they
  don't I think we shouldn't
  either.
 
  I agree
 
  I've carried the question whether a JSF 2.0 compatible implementation
  is
  required to refuse old version facelets taglibs into the EG - let's
  see,
  what they have to say
 
  technically, I think now we are correct.
 
  @Jakob: Did you create such a bug against the RI ?
  (that they allow old Facelets) maybe another on
  not being (too) clear in the spec about it...
  -Matthias
 
  on this ...
 
  Best regards,
  Ganesh
 
  I see both ways; I think I don't like the fact that the RI has this
  bug
  :)
  So, end of the story is, almost everybody will blame this to us ;-)
  Oh, crappy MyFaces doesn't work etc :) All the FUD! :)
 
 
 
 



 --
 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: [core] Backwards compatibility (e.g. MYFACES-2543)

nope, but the web.xml setting for Trinidad's alternate view handler;

it is complaining about the facelets embedded faces-config

-Matthias

On Thu, Feb 11, 2010 at 2:22 PM, Jakob Korherr jakob.korh...@gmail.com wrote:
 have you installed the com.sun.facelets.FaceletViewHandler in faces-config?
 and which error did you get?


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

 @ javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER

 I tried (Glassfish v3) to deploy a JSF 1.2 application (with Facelets
 1.1.14) and that javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER
 parameter == true;

 I get an error there as well :-)

 -Matthias

 On Wed, Feb 10, 2010 at 11:08 AM, Jakob Korherr jakob.korh...@gmail.com
 wrote:
  No I have not filed any bugs. Feel free to file them ;)
 
  Regards,
  Jakob
 
  2010/2/10 Matthias Wessendorf mat...@apache.org
 
  On Wed, Feb 10, 2010 at 10:44 AM, Ganesh gan...@j4fry.org wrote:
   IMHO the spec is very clear about this and the stuff in the appendix
   is
   a
   spec bug. From the spec (10.1.2):
  
   A decision was made early in this process to strive for backwards
   compatibility between the latest popular version of Facelets and
   Facelets in
   JSF 2.0. The sole determinant to backwards compatibility lies in the
   answer
   to the question, “is there any Java code in the application, or in
   libraries
   used by the application, that extends from or depends on any class in
   package com.sun.facelets and/or its sub-packages?”
   ■ If the answer to this question is “yes”, Facelets in JSF 2.0 is not
   backwards compatibile with Facelets and such an application must
   continue to
   bundle the Facelets jar file along with the application, continue to
   set
   the
   Facelets configuration parameters, and also set the
   javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER
   context-param to true. Please see Section 11.1.3 “Application
   Configuration Parameters” for details on this
   option. Any code that extends or depends on any class in package
   com.sun.facelets and/or its sub-packages
   must be modified to depend on the appropriate classes in package
   javax.faces.webapp.vdl and/or its subpackages.
 
  yes (see previous email(s))
 
 
   ■ If the answer to this question is “no”, Facelets in JSF 2.0 is
   backwards
   compatible with pre-JSF 2.0 Facelets and such an application must not
   continue to bundle the Facelets jar file along with the application,
   and
   must not continue to set the Facelets configuration parameters.
   Thankfully, most applications that use Facelets fall into the latter
   category, or, if they fall in the former, their dependence will
   easily
   be
   migrated to the new public classes.
 
  ok. please; file a bug on that appendix thing.
 
  thjx
  -m
 
  
   Best regards,
   Ganesh
  
   Matthias Wessendorf schrieb:
  
   On Wed, Feb 10, 2010 at 6:26 AM, Ganesh gan...@j4fry.org wrote:
  
   Many Facelets taglibs don't use Facelets tag handlers,
   but simply wrap some xhtml templates. Nothing will stop these
   libraries
   to
   work with MyFaces if we allow old version taglibs.
   If we insist on refusing them people will simply switch to Mojarra
   to
   get
   their application to run.
  
   I know; that's what I meant with my comment before
  
   The argument of a xsd:restriction in the spec will
   help little. Just
   taking old Facelets is *not* a solution, because the
   rest of the application may want to use the new features.
   Please try filing this as a bug to Mojarra as Matthias
   proposed - if they fix it, MyFaces may insist on version=2.0, but
   if
   they
   don't I think we shouldn't
   either.
  
   I agree
  
   I've carried the question whether a JSF 2.0 compatible
   implementation
   is
   required to refuse old version facelets taglibs into the EG - let's
   see,
   what they have to say
  
   technically, I think now we are correct.
  
   @Jakob: Did you create such a bug against the RI ?
   (that they allow old Facelets) maybe another on
   not being (too) clear in the spec about it...
   -Matthias
  
   on this ...
  
   Best regards,
   Ganesh
  
   I see both ways; I think I don't like the fact that the RI has
   this
   bug
   :)
   So, end of the story is, almost everybody will blame this to us
   ;-)
   Oh, crappy MyFaces doesn't work etc :) All the FUD! :)
  
  
  
  
 
 
 
  --
  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

[Vote] Trinidad plugins 1.2.12 release

Hi,

I was running the needed tasks to get the 1.2.12 release of the Apache
MyFaces Trinidad Maven 2 Plugins.

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

Please take a look at the 1.2.12 artifacts and vote.

How to test those JARs ?

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


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


Thanks,
Matthias

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

-- 
Matthias Wessendorf

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

Re: [Vote] Trinidad plugins 1.2.12 release

+1

On Thu, Feb 11, 2010 at 4:47 PM, Matthias Wessendorf mat...@apache.org wrote:
 Hi,

 I was running the needed tasks to get the 1.2.12 release of the Apache
 MyFaces Trinidad Maven 2 Plugins.

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

 Please take a look at the 1.2.12 artifacts and vote.

 How to test those JARs ?

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

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

 Thanks,
 Matthias

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

 --
 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] Commented: (TRINIDAD-1677) Tag Documentation to list default value for attributes

Vote for 1.2.12 is out:

http://markmail.org/message/ip5pam4cldtdfrfc

Jeanne, please vote ;-)

On Wed, Feb 10, 2010 at 9:58 PM, Matthias Wessendorf mat...@apache.org wrote:
 On Wed, Feb 10, 2010 at 9:45 PM, Maria Kaval maria.ka...@oracle.com wrote:
 Thanks for the clarification. Yes, we are currently picking up 
 Trinidad-maven 1.2.11 for our RCF trunk.  One option would be to do a new 
 release of the plugins now that JIRA 1677 and JIRA 1679 have been checked 
 in.  Is there a plan to make a Trinidad 1.2.12 release of the plugins?

 Matthias: I want to run Trinidad 2 maven plugins release 2morrow;
 doing that for trunk is fine as well; Almost all automated ;-)

 -Matthias


 Maria

 -Original Message-
 From: Matthias Weßendorf (JIRA) [mailto:d...@myfaces.apache.org]
 Sent: Wednesday, February 10, 2010 12:39 PM
 To: Maria Kaval
 Subject: [jira] Commented: (TRINIDAD-1677) Tag Documentation to list default 
 value for attributes


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

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

 that has been released. We generally don't patch TAGs as these are final.
 Are you on 1.2.11 ? that means you are on an officially released version;
 options are taking one of the existing branches or trunk;

 Tag Documentation to list default value for attributes
 --

                 Key: TRINIDAD-1677
                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1677
             Project: MyFaces Trinidad
          Issue Type: Improvement
          Components: Documentation
    Affects Versions:  1.2.11-plugins
            Reporter: Maria Kaval
            Assignee: Jeanne Waldman
            Priority: Minor
             Fix For:  1.2.12-plugins

         Attachments: JIRA1677_trunk.patch, JIRA1677_trunk2.patch, 
 JIRA1677patch_for_1_2_11.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 The tag documentation today does not list the default value for a given 
 attribute of a component. Listing the default value for an attribute will 
 help clarify how a component works for application developers.

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





 --
 Matthias Wessendorf

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




-- 
Matthias Wessendorf

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

Re: [Vote] Trinidad plugins 1.2.12 release

Leo,

this is for 1.2.12

@fix: it is a bit more than just replacing the header;
we use it for merging with the base document; on it...

-Matthias

On Thu, Feb 11, 2010 at 5:20 PM, Leonardo Uribe lu4...@gmail.com wrote:
 Hi

 If maven faces plugin 2.0.1 will be released, I have to vote -1 for that
 specific plugin and version, because GenerateFaceletsTaglibsMojo should
 generate facelets tag lib with version 2.0 to allow later trinidad for jsf
 2.0 works correctly with myfaces core 2.0.x. It is a very simple fix to do
 but I think this is a blocker issue for release another version of trinidad
 for jsf 2.0.

 regards,

 Leonardo Uribe

 2010/2/11 Max Starets max.star...@oracle.com

 +1
 Matthias Wessendorf wrote:

 Hi,

 I was running the needed tasks to get the 1.2.12 release of the Apache
 MyFaces Trinidad Maven 2 Plugins.

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

 Please take a look at the 1.2.12 artifacts and vote.

 How to test those JARs ?

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

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

 Thanks,
 Matthias

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








-- 
Matthias Wessendorf

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

[VOTE] Release of Trinidad 1.0.12

Hi,

I was running the needed tasks to get the 1.0.12 release of the Apache
MyFaces Trinidad CORE out. The artifacts are deployed to my private
Apache account ([1]). The distribution is located at [2].

Please take a look at the 1.0.12 artifacts and vote


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


Thanks,
Matthias

[1] http://people.apache.org/~matzew/staging_repo/
[2] http://people.apache.org/~matzew/trinidad-1.0.12_dist/

-- 
Matthias Wessendorf

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

Re: [VOTE] Release of Trinidad 1.0.12

+1

On Thu, Feb 11, 2010 at 10:28 PM, Matthias Wessendorf mat...@apache.org wrote:
 Hi,

 I was running the needed tasks to get the 1.0.12 release of the Apache
 MyFaces Trinidad CORE out. The artifacts are deployed to my private
 Apache account ([1]). The distribution is located at [2].

 Please take a look at the 1.0.12 artifacts and vote

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

 Thanks,
 Matthias

 [1] http://people.apache.org/~matzew/staging_repo/
 [2] http://people.apache.org/~matzew/trinidad-1.0.12_dist/

 --
 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] Resolved: (MYFACES-2543) Facelets Taglib jars are not recognized


+1 on that
Go ahead and re-open it

Sent from my iPod.

On 12.02.2010, at 06:36, Ganesh gan...@j4fry.org wrote:

Leo, can you please read this again? I thought we agreed on this  
being a MyFaces bug. IMHO te spec is clear and I don't agree on  
closing the issue.


From the spec (10.1.2):

A decision was made early in this process to strive for backwards  
compatibility between the latest popular version of Facelets and  
Facelets in JSF 2.0. The sole determinant to backwards compatibility  
lies in the answer to the question, “is there any Java code in the a 
pplication, or in libraries used by the application, that extends fr 
om or depends on any class in package com.sun.facelets and/or its su 
b-packages?”
■ If the answer to this question is “yes”, Facelets in JSF 2.0  
is not backwards compatibile with Facelets and such an application m 
ust continue to bundle the Facelets jar file along with the applicat 
ion, continue to set the Facelets configuration parameters, and also 
 set the javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER
context-param to true. Please see Section 11.1.3 “Application Conf 
iguration Parameters” for details on this
option. Any code that extends or depends on any class in package  
com.sun.facelets and/or its sub-packages
must be modified to depend on the appropriate classes in package  
javax.faces.webapp.vdl and/or its subpackages.
■ If the answer to this question is “no”, Facelets in JSF 2.0  
is backwards compatible with pre-JSF 2.0 Facelets and such an applic 
ation must not continue to bundle the Facelets jar file along with t 
he application, and must not continue to set the Facelets configurat 
ion parameters.
Thankfully, most applications that use Facelets fall into the latter  
category, or, if they fall in the former, their dependence will  
easily be migrated to the new public classes.

Can we please reopen the issue and fix it?

Best regards,
Ganesh

Leonardo Uribe (JIRA) schrieb:
[ https://issues.apache.org/jira/browse/MYFACES-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel 
 ]

Leonardo Uribe resolved MYFACES-2543.
-
  Resolution: Won't Fix
   Fix Version/s: 2.0.0-beta-2
Assignee: Leonardo Uribe
This issue is closed as won't fix, because no advance can be done  
from this point. To solve it we have to change the package  
convention to com.sun.facelets, and that is a bad idea. Note a  
workaround could be done to allow previous jsf 1.2 libs to work  
with jsf 2.0 as described on jsf 2.0 spec chapter 10

Facelets Taglib jars are not recognized
---

   Key: MYFACES-2543
   URL: https://issues.apache.org/jira/browse/MYFACES-2543
   Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
  Affects Versions: 2.0.0-beta
   Environment: Facelets
  Reporter: Ganesh Jung
  Assignee: Leonardo Uribe
   Fix For: 2.0.0-beta-2

   Attachments: MyFaces_Test.jar


Facelets taglibs defined according to the spec 10.3.2 are not  
recognized.

This page uses a test taglib (see attachment):
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
   http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
 xmlns:f=http://java.sun.com/jsf/core;
 xmlns:h=http://java.sun.com/jsf/html;
 xmlns:ui=http://java.sun.com/jsf/facelets;
 xmlns:test=http://j4fry.org/test;
   body
   test:button /
   /body
/html
but test:button is not resolved...

Re: [jira] Resolved: (MYFACES-2543) Facelets Taglib jars are not recognized


What's up with this part of the spec:
…

 xsd:restriction base=xsd:token
xsd:enumeration value=2.0/
 /xsd:restriction

…

did you file a bug? Or do you want me to file it??

Sent from my iPod.

On 12.02.2010, at 07:15, Matthias Wessendorf mwessend...@gmail.com  
wrote:



+1 on that
Go ahead and re-open it

Sent from my iPod.

On 12.02.2010, at 06:36, Ganesh gan...@j4fry.org wrote:

Leo, can you please read this again? I thought we agreed on this  
being a MyFaces bug. IMHO te spec is clear and I don't agree on  
closing the issue.


From the spec (10.1.2):

A decision was made early in this process to strive for backwards  
compatibility between the latest popular version of Facelets and  
Facelets in JSF 2.0. The sole determinant to backwards  
compatibility lies in the answer to the question, “is there any Ja 
va code in the application, or in libraries used by the applicatio 
n, that extends from or depends on any class in package com.sun.fa 
celets and/or its sub-packages?”
■ If the answer to this question is “yes”, Facelets in JSF 2.0  
is not backwards compatibile with Facelets and such an application 
 must continue to bundle the Facelets jar file along with the appl 
ication, continue to set the Facelets configuration parameters, an 
d also set the javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER
context-param to true. Please see Section 11.1.3 “Application Co 
nfiguration Parameters” for details on this
option. Any code that extends or depends on any class in package  
com.sun.facelets and/or its sub-packages
must be modified to depend on the appropriate classes in package  
javax.faces.webapp.vdl and/or its subpackages.
■ If the answer to this question is “no”, Facelets in JSF 2.0  
is backwards compatible with pre-JSF 2.0 Facelets and such an appl 
ication must not continue to bundle the Facelets jar file along wi 
th the application, and must not continue to set the Facelets conf 
iguration parameters.
Thankfully, most applications that use Facelets fall into the  
latter category, or, if they fall in the former, their dependence  
will easily be migrated to the new public classes.

Can we please reopen the issue and fix it?

Best regards,
Ganesh

Leonardo Uribe (JIRA) schrieb:
   [ https://issues.apache.org/jira/browse/MYFACES-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel 
 ]

Leonardo Uribe resolved MYFACES-2543.
-
 Resolution: Won't Fix
  Fix Version/s: 2.0.0-beta-2
   Assignee: Leonardo Uribe
This issue is closed as won't fix, because no advance can be done  
from this point. To solve it we have to change the package  
convention to com.sun.facelets, and that is a bad idea. Note a  
workaround could be done to allow previous jsf 1.2 libs to work  
with jsf 2.0 as described on jsf 2.0 spec chapter 10

Facelets Taglib jars are not recognized
---

  Key: MYFACES-2543
  URL: https://issues.apache.org/jira/browse/MYFACES-2543
  Project: MyFaces Core
   Issue Type: Bug
   Components: JSR-314
 Affects Versions: 2.0.0-beta
  Environment: Facelets
 Reporter: Ganesh Jung
 Assignee: Leonardo Uribe
  Fix For: 2.0.0-beta-2

  Attachments: MyFaces_Test.jar


Facelets taglibs defined according to the spec 10.3.2 are not  
recognized.

This page uses a test taglib (see attachment):
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
  http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:test=http://j4fry.org/test;
  body
  test:button /
  /body
/html
but test:button is not resolved...

Re: [jira] Resolved: (MYFACES-2543) Facelets Taglib jars are not recognized

On Fri, Feb 12, 2010 at 7:28 AM, Ganesh gan...@j4fry.org wrote:
 Actually I've asked on jsr-314-open whether people
 agree on this being a bug and so I want to wait until the weekend before
 opening an issue. I'll do it on
 sunday, if that's fine with you.

sure :-) My problem is that otherwise things are easily forgotten, over there.
Bugs is a well-understood language ;-)

I mean, this is obvious, right?
Restricting it to 2.0 would mean MyFaces is _technically_ correct.
But the prose section (that what you posted) clearly says your JAR
(MYFACES-2543)
should work.

-M


 Best regards,
 Ganesh

 Matthias Wessendorf schrieb:

 What's up with this part of the spec:
 …

  xsd:restriction base=xsd:token
    xsd:enumeration value=2.0/
  /xsd:restriction

 …

 did you file a bug? Or do you want me to file it??

 Sent from my iPod.

 On 12.02.2010, at 07:15, Matthias Wessendorf mwessend...@gmail.com
 mailto:mwessend...@gmail.com wrote:

 +1 on that
 Go ahead and re-open it

 Sent from my iPod.

 On 12.02.2010, at 06:36, Ganesh gan...@j4fry.org
 mailto:gan...@j4fry.org wrote:

 Leo, can you please read this again? I thought we agreed on this being a
 MyFaces bug. IMHO te spec is clear and I don't agree on closing the issue.

 From the spec (10.1.2):

 A decision was made early in this process to strive for backwards
 compatibility between the latest popular version of Facelets and Facelets 
 in
 JSF 2.0. The sole determinant to backwards compatibility lies in the answer
 to the question, “is there any Java code in the application, or in 
 libraries
 used by the application, that extends from or depends on any class in
 package com.sun.facelets and/or its sub-packages?”
 ■ If the answer to this question is “yes”, Facelets in JSF 2.0 is not
 backwards compatibile with Facelets and such an application must continue 
 to
 bundle the Facelets jar file along with the application, continue to set 
 the
 Facelets configuration parameters, and also set the
 javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER
 context-param to true. Please see Section 11.1.3 “Application
 Configuration Parameters” for details on this
 option. Any code that extends or depends on any class in package
 com.sun.facelets and/or its sub-packages
 must be modified to depend on the appropriate classes in package
 javax.faces.webapp.vdl and/or its subpackages.
 ■ If the answer to this question is “no”, Facelets in JSF 2.0 is
 backwards compatible with pre-JSF 2.0 Facelets and such an application must
 not continue to bundle the Facelets jar file along with the application, 
 and
 must not continue to set the Facelets configuration parameters.
 Thankfully, most applications that use Facelets fall into the latter
 category, or, if they fall in the former, their dependence will easily be
 migrated to the new public classes.
 Can we please reopen the issue and fix it?

 Best regards,
 Ganesh

 Leonardo Uribe (JIRA) schrieb:

   [
 https://issues.apache.org/jira/browse/MYFACES-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]
 Leonardo Uribe resolved MYFACES-2543.
 -
     Resolution: Won't Fix
  Fix Version/s: 2.0.0-beta-2
       Assignee: Leonardo Uribe
 This issue is closed as won't fix, because no advance can be done from
 this point. To solve it we have to change the package convention to
 com.sun.facelets, and that is a bad idea. Note a workaround could be done 
 to
 allow previous jsf 1.2 libs to work with jsf 2.0 as described on jsf 2.0
 spec chapter 10

 Facelets Taglib jars are not recognized
 ---

              Key: MYFACES-2543
              URL:
 https://issues.apache.org/jira/browse/MYFACES-2543https://issues.apache.org/jira/browse/MYFACES-2543
          Project: MyFaces Core
       Issue Type: Bug
       Components: JSR-314
  Affects Versions: 2.0.0-beta
      Environment: Facelets
         Reporter: Ganesh Jung
         Assignee: Leonardo Uribe
          Fix For: 2.0.0-beta-2

      Attachments: MyFaces_Test.jar


 Facelets taglibs defined according to the spec 10.3.2 are not
 recognized.
 This page uses a test taglib (see attachment):
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
      http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html xmlns=http://www.w3.org/1999/xhtml;
    xmlns:f=http://java.sun.com/jsf/core;
    xmlns:h=http://java.sun.com/jsf/html;
    xmlns:ui=http://java.sun.com/jsf/facelets;
    xmlns:test=http://j4fry.org/test;
  body
      test:button /
  /body
 /html
 but test:button is not resolved...




-- 
Matthias Wessendorf

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

Re: [REVOTE] Ext-Scripting Alpha1

+1

On Tue, Feb 9, 2010 at 11:46 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
 +1
 regards,
 gerhard

 http://www.irian.at

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

 Professional Support for Apache MyFaces


 2010/2/9 Werner Punz werner.p...@gmail.com

 Hello, as some may remember I had to pull the vote of ext-scripting Alpha
 1 due to a missing parent pom in the projects main pom. Nevertheless I have
 done all the changes and used the opportunity for some pre alpha code
 cleanup.
 I would like to restart the vote, to get the Alpha finally out.


 Werner






-- 
Matthias Wessendorf

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

Re: [core] Backwards compatibility (e.g. MYFACES-2543)

On Wed, Feb 10, 2010 at 10:44 AM, Ganesh gan...@j4fry.org wrote:
 IMHO the spec is very clear about this and the stuff in the appendix is a
 spec bug. From the spec (10.1.2):

 A decision was made early in this process to strive for backwards
 compatibility between the latest popular version of Facelets and Facelets in
 JSF 2.0. The sole determinant to backwards compatibility lies in the answer
 to the question, “is there any Java code in the application, or in libraries
 used by the application, that extends from or depends on any class in
 package com.sun.facelets and/or its sub-packages?”
 ■ If the answer to this question is “yes”, Facelets in JSF 2.0 is not
 backwards compatibile with Facelets and such an application must continue to
 bundle the Facelets jar file along with the application, continue to set the
 Facelets configuration parameters, and also set the
 javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER
 context-param to true. Please see Section 11.1.3 “Application
 Configuration Parameters” for details on this
 option. Any code that extends or depends on any class in package
 com.sun.facelets and/or its sub-packages
 must be modified to depend on the appropriate classes in package
 javax.faces.webapp.vdl and/or its subpackages.

yes (see previous email(s))


 ■ If the answer to this question is “no”, Facelets in JSF 2.0 is backwards
 compatible with pre-JSF 2.0 Facelets and such an application must not
 continue to bundle the Facelets jar file along with the application, and
 must not continue to set the Facelets configuration parameters.
 Thankfully, most applications that use Facelets fall into the latter
 category, or, if they fall in the former, their dependence will easily be
 migrated to the new public classes.

ok. please; file a bug on that appendix thing.

thjx
-m


 Best regards,
 Ganesh

 Matthias Wessendorf schrieb:

 On Wed, Feb 10, 2010 at 6:26 AM, Ganesh gan...@j4fry.org wrote:

 Many Facelets taglibs don't use Facelets tag handlers,
 but simply wrap some xhtml templates. Nothing will stop these libraries
 to
 work with MyFaces if we allow old version taglibs.
 If we insist on refusing them people will simply switch to Mojarra to get
 their application to run.

 I know; that's what I meant with my comment before

 The argument of a xsd:restriction in the spec will
 help little. Just
 taking old Facelets is *not* a solution, because the
 rest of the application may want to use the new features.
 Please try filing this as a bug to Mojarra as Matthias
 proposed - if they fix it, MyFaces may insist on version=2.0, but if they
 don't I think we shouldn't
 either.

 I agree

 I've carried the question whether a JSF 2.0 compatible implementation is
 required to refuse old version facelets taglibs into the EG - let's see,
 what they have to say

 technically, I think now we are correct.

 @Jakob: Did you create such a bug against the RI ?
 (that they allow old Facelets) maybe another on
 not being (too) clear in the spec about it...
 -Matthias

 on this ...

 Best regards,
 Ganesh

 I see both ways; I think I don't like the fact that the RI has this
 bug
 :)
 So, end of the story is, almost everybody will blame this to us ;-)
 Oh, crappy MyFaces doesn't work etc :) All the FUD! :)







-- 
Matthias Wessendorf

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

Fwd: [1539-ProjectStageSystemProperty] PROPOSAL

FYI

-- Forwarded message --
From: Ed Burns ed.bu...@sun.com
Date: Mon, Feb 8, 2010 at 5:55 PM
Subject: [1539-ProjectStageSystemProperty] PROPOSAL
To: d...@javaserverfaces.dev.java.net

PROPOSAL

This will *not* go in the spec, but I propose that existing JSF
implementation coordinate and implement the following behavior.

We introduce a System Property

faces.PROJECT_STAGE

 Rationale for using this name: the context-param for this property is
 javax.faces.PROJECT_STAGE.  I chose not to use the javax. prefix
 because doing so would be in poor taste.  The javax.  prefix is
 intended for things in the specification proper.

 The valid values of this property are exactly as specified in section
 11.1.3.  If the System Property is not one of the valid values, the
 other sources for a value for this property are consulted.

 The implementation will interpret this property as an override for all
 other ways of setting the Application.getProjectStage() property.

In addition to the preceding proposal, the implementation will print out
a very prominent log message such as:

*** WARNING: JavaServer Faces is running in DEVELOPMENT mode.    ***
***                                         ^^^          ***
*** Do NOT deploy to your live server(s) without changing this.  ***
*** See Application#getProjectStage() for more information.      ***

Matthias Wessendorf, can you ensure that MyFaces implements it this way?

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: Fwd: [1539-ProjectStageSystemProperty] PROPOSAL

cool!

On Wed, Feb 10, 2010 at 1:15 PM, Mark Struberg strub...@yahoo.de wrote:
 txs also fixed in CODI [1]

 LieGrue,
 strub

 [1] http://github.com/struberg/myfaces-ext-cdi/

 --- Matthias Wessendorf mat...@apache.org schrieb am Mi, 10.2.2010:

 Von: Matthias Wessendorf mat...@apache.org
 Betreff: Fwd: [1539-ProjectStageSystemProperty] PROPOSAL
 An: MyFaces Development dev@myfaces.apache.org
 Datum: Mittwoch, 10. Februar 2010, 11:59
 FYI


 -- Forwarded message --
 From: Ed Burns ed.bu...@sun.com
 Date: Mon, Feb 8, 2010 at 5:55 PM
 Subject: [1539-ProjectStageSystemProperty] PROPOSAL
 To: d...@javaserverfaces.dev.java.net


 PROPOSAL

 This will *not* go in the spec, but I propose that existing
 JSF
 implementation coordinate and implement the following
 behavior.

 We introduce a System Property

 faces.PROJECT_STAGE

  Rationale for using this name: the context-param for this
 property is
  javax.faces.PROJECT_STAGE.  I chose not to use the
 javax. prefix
  because doing so would be in poor taste.  The javax.
  prefix is
  intended for things in the specification proper.

  The valid values of this property are exactly as
 specified in section
  11.1.3.  If the System Property is not one of the valid
 values, the
  other sources for a value for this property are
 consulted.

  The implementation will interpret this property as an
 override for all
  other ways of setting the Application.getProjectStage()
 property.

 In addition to the preceding proposal, the implementation
 will print out
 a very prominent log message such as:

 
 *** WARNING: JavaServer Faces is running in DEVELOPMENT
 mode.    ***
 ***
     ^^^          ***
 *** Do NOT deploy to your live server(s) without changing
 this.  ***
 *** See Application#getProjectStage() for more information.
      ***
 

 Matthias Wessendorf, can you ensure that MyFaces implements
 it this way?

 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


 __
 Do You Yahoo!?
 Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz 
 gegen Massenmails.
 http://mail.yahoo.com




-- 
Matthias Wessendorf

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

[Trinidad] Version 2.x becoming trunk ?

Hey,

as the most work recently goes into the JSF2 version for Trinidad, I'd
like to make that trunk.
The current trunk (1.2.x) will become a branch; Sure releases for that
(and fixes) are coming in.
Of course :-)

IMO this makes sense; Not only Trinidad has the current focus on jsf2,
so does MyFaces Core as well

-Matthias

-- 
Matthias Wessendorf

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

[Trinidad2] new branch...

Hello,

there is a new branch:
https://svn.apache.org/repos/asf/myfaces/trinidad/branches/matzewTrinidad2002/
yes... it will be renamed ... / relocated; soon
(see my other email)

Also, I am about to generate a new (alpha/beta) release for the 2.0.x offerings
(will contain changes BEFORE this new branch has been created)

-Matthias

-- 
Matthias Wessendorf

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

Re: [Trinidad2] new branch...

On Wed, Feb 10, 2010 at 6:39 PM, Gabrielle Crawford
gabrielle.crawf...@oracle.com wrote:
 Hi Matthias,

 What is the new branch for?

contains stuff that has been fixed on trunk.

 Are you saying that will be trunk?

maybe soon; see the other email

 Why not just make the 2.0.x branch trunk?

see other email; I want to give a heads-up instead of swapping out
trunk...

-Matthias

PS: this will be renamed... (after that is done, another email is around ehre)


 Thanks,

 Gab

 Matthias Wessendorf wrote:

 Hello,

 there is a new branch:

 https://svn.apache.org/repos/asf/myfaces/trinidad/branches/matzewTrinidad2002/
 yes... it will be renamed ... / relocated; soon
 (see my other email)

 Also, I am about to generate a new (alpha/beta) release for the 2.0.x
 offerings
 (will contain changes BEFORE this new branch has been created)

 -Matthias






-- 
Matthias Wessendorf

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

[Trinidad] version 2.0 branches,...... Please read :-)

Hello

the OLD trindiad2 branch has been reloacted, to:

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

the NEW branch (which contains the latest greatest work from trunk) is
now named 2.0.x:
https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x/

If you have questions, let me know!

-Matthias

On Wed, Feb 10, 2010 at 6:54 PM, Matthias Wessendorf mat...@apache.org wrote:
 On Wed, Feb 10, 2010 at 6:39 PM, Gabrielle Crawford
 gabrielle.crawf...@oracle.com wrote:
 Hi Matthias,

 What is the new branch for?

 contains stuff that has been fixed on trunk.

 Are you saying that will be trunk?

 maybe soon; see the other email

 Why not just make the 2.0.x branch trunk?

 see other email; I want to give a heads-up instead of swapping out
 trunk...

 -Matthias

 PS: this will be renamed... (after that is done, another email is around ehre)


 Thanks,

 Gab

 Matthias Wessendorf wrote:

 Hello,

 there is a new branch:

 https://svn.apache.org/repos/asf/myfaces/trinidad/branches/matzewTrinidad2002/
 yes... it will be renamed ... / relocated; soon
 (see my other email)

 Also, I am about to generate a new (alpha/beta) release for the 2.0.x
 offerings
 (will contain changes BEFORE this new branch has been created)

 -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

SVN issue ?

Hello,

I can't commit to /myfaces/trinidad/*** SVN folder...

anything going on? I don't see much here:
http://monitoring.apache.org/status/

-Matthias

-- 
Matthias Wessendorf

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

Re: SVN issue ?

getting:

svn: Commit failed (details follow):
svn: The specified baseline is not the latest baseline, so it may not
be checked out.

I even combine svn up and svn ci

== svn up  svn ci 

-Matthias

On Wed, Feb 10, 2010 at 9:28 PM, Matthias Wessendorf mat...@apache.org wrote:
 Hello,

 I can't commit to /myfaces/trinidad/*** SVN folder...

 anything going on? I don't see much here:
 http://monitoring.apache.org/status/

 -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: SVN issue ?

ok...

svn: Commit failed (details follow):
svn: Commit blocked by start-commit hook (exit code 1) with output:
Write access is currently disabled. The ASF SVN repository is
currently undergoing maintenance.


On Wed, Feb 10, 2010 at 9:31 PM, Matthias Wessendorf mat...@apache.org wrote:
 getting:

 svn: Commit failed (details follow):
 svn: The specified baseline is not the latest baseline, so it may not
 be checked out.

 I even combine svn up and svn ci

 == svn up  svn ci 

 -Matthias

 On Wed, Feb 10, 2010 at 9:28 PM, Matthias Wessendorf mat...@apache.org 
 wrote:
 Hello,

 I can't commit to /myfaces/trinidad/*** SVN folder...

 anything going on? I don't see much here:
 http://monitoring.apache.org/status/

 -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: [jira] Commented: (TRINIDAD-1677) Tag Documentation to list default value for attributes

On Wed, Feb 10, 2010 at 9:45 PM, Maria Kaval maria.ka...@oracle.com wrote:
 Thanks for the clarification. Yes, we are currently picking up Trinidad-maven 
 1.2.11 for our RCF trunk.  One option would be to do a new release of the 
 plugins now that JIRA 1677 and JIRA 1679 have been checked in.  Is there a 
 plan to make a Trinidad 1.2.12 release of the plugins?

Matthias: I want to run Trinidad 2 maven plugins release 2morrow;
doing that for trunk is fine as well; Almost all automated ;-)

-Matthias


 Maria

 -Original Message-
 From: Matthias Weßendorf (JIRA) [mailto:d...@myfaces.apache.org]
 Sent: Wednesday, February 10, 2010 12:39 PM
 To: Maria Kaval
 Subject: [jira] Commented: (TRINIDAD-1677) Tag Documentation to list default 
 value for attributes


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

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

 that has been released. We generally don't patch TAGs as these are final.
 Are you on 1.2.11 ? that means you are on an officially released version;
 options are taking one of the existing branches or trunk;

 Tag Documentation to list default value for attributes
 --

                 Key: TRINIDAD-1677
                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1677
             Project: MyFaces Trinidad
          Issue Type: Improvement
          Components: Documentation
    Affects Versions:  1.2.11-plugins
            Reporter: Maria Kaval
            Assignee: Jeanne Waldman
            Priority: Minor
             Fix For:  1.2.12-plugins

         Attachments: JIRA1677_trunk.patch, JIRA1677_trunk2.patch, 
 JIRA1677patch_for_1_2_11.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 The tag documentation today does not list the default value for a given 
 attribute of a component. Listing the default value for an attribute will 
 help clarify how a component works for application developers.

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





-- 
Matthias Wessendorf

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

Re: [Trinidad] Slider component in Trinidad for mobile devices

yes.

you could use facelets. A demo slider (based on jQuery) is here:
http://facesgoodies.googlecode.com/svn/MS/trunk/src/main/webapp/resources/ms/


On Wed, Feb 10, 2010 at 3:13 AM, Seema Richard (UST, IND)
seema.rich...@ust-global.com wrote:
 Hi,



 We need to develop a web application supporting multiple mobile devices
 like Blackberry, iPhone, Android and so on and we were considering
 Apache Trinidad. The client has already supplied the mock up pages which
 seem to have a lot of Ajax functionality and controls like Slider. I
 could not find a slider control in Trinidad. Does this mean that we
 would need to create a custom component instead?



 Thanks,

 Seema





-- 
Matthias Wessendorf

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

Re: Code Conventions

Hi Gurkan,

I think somewhere in Apache is a wiki page which has some good
information on this topic as well

-Matthias

On Wed, Feb 10, 2010 at 6:44 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
 Hello folks;

 While committing code into our code base, it is good idea to have following 
 and obey our formatter rules

 1* Remove unused imports
 2* Try to get rid of generic warnings
 3* Use correct line bracing and tab space
 4* Use SVN properties

 Thanks;

 --Gurkan



      ___
 Yahoo! Türkiye açıldı!  http://yahoo.com.tr
 İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!



-- 
Matthias Wessendorf

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

[core] UIComponentBase.getId() can return null

Hi,

Blake committed an interesting patch to Trinidad:
http://bit.ly/dtghOs

I see that MyFaces can actually return NULL on getId(), however the
MyFaces implementation
goes ahead and creates the ID if getClientId(facesCtx) is called AND!
the getId() returns null.

So, why not directly ensuring that getId() can't return null ?

Checking the JavaDoc of getClientId(FacesCtx), I see that MyFaces is
doing what is required.
But does that really make sense?

-Matthias

-- 
Matthias Wessendorf

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

[core] Backwards compatibility (e.g. MYFACES-2543)

Deplyoing very simple JARs, like:
https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar

should work, out of the box. Doesn't the spec explicitly talk about this
for backward compatibility?
Sure, when you extend the old Facelets classes, you have to have it deployed
as well (and there is some parameter to disable Facelets2)

-Matthias

-- 
Matthias Wessendorf

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

Re: [core] Backwards compatibility (e.g. MYFACES-2543)

maybe I am conservative, but I doubt that it is a bug, to allow old
facelets-based tag JARs.
You are saying it is, right ?

On Tue, Feb 9, 2010 at 7:04 PM, Leonardo Uribe lu4...@gmail.com wrote:
 Hi

 I agree with Jakob.

 Just a small comment, doing some black box tests between myfaces and ri I
 notice long time ago that ri cannot read faces-config.xml without have
 version 2.0 in that file. It seems they fix that but a side effect is what
 we are seeing right now (facelets taglibs 1.1.x read). I think myfaces is
 doing right and really ri is mixing the two config files by some unknown
 reason.

 regards,

 Leonardo Uribe

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

 On my opinion you have to differentiate between 1.x taglibs and 2.0
 taglibs in some way, because MyFaces cannot know if this taglib will or
 won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 you
 simply have to add version=2.0 to your taglib and it will function
 properly.

 This is also specified in the spec (although completely hidden in the
 appendix): take a look at the xsd type definition of
 facelet-taglib-versionType. It says This type contains the recognized
 versions of facelet-taglib supported. and 2.0 is the only allowed value
 for this attribute.

 Regards,
 Jakob

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

 Deplyoing very simple JARs, like:

 https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar

 should work, out of the box. Doesn't the spec explicitly talk about this
 for backward compatibility?
 Sure, when you extend the old Facelets classes, you have to have it
 deployed
 as well (and there is some parameter to disable Facelets2)

 -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: [core] Backwards compatibility (e.g. MYFACES-2543)

... on the other hand, the EG says, that JSF2.0 RT can be used to
deploy a JSF1.2 based application.
Since Facelets was just some random proprietary framework, ignoring
the old Facelets DTD is I
think correct;

Still it is IMO a bit lame.

-Matthias

On Tue, Feb 9, 2010 at 7:20 PM, Matthias Wessendorf mat...@apache.org wrote:
 maybe I am conservative, but I doubt that it is a bug, to allow old
 facelets-based tag JARs.
 You are saying it is, right ?

 On Tue, Feb 9, 2010 at 7:04 PM, Leonardo Uribe lu4...@gmail.com wrote:
 Hi

 I agree with Jakob.

 Just a small comment, doing some black box tests between myfaces and ri I
 notice long time ago that ri cannot read faces-config.xml without have
 version 2.0 in that file. It seems they fix that but a side effect is what
 we are seeing right now (facelets taglibs 1.1.x read). I think myfaces is
 doing right and really ri is mixing the two config files by some unknown
 reason.

 regards,

 Leonardo Uribe

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

 On my opinion you have to differentiate between 1.x taglibs and 2.0
 taglibs in some way, because MyFaces cannot know if this taglib will or
 won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 you
 simply have to add version=2.0 to your taglib and it will function
 properly.

 This is also specified in the spec (although completely hidden in the
 appendix): take a look at the xsd type definition of
 facelet-taglib-versionType. It says This type contains the recognized
 versions of facelet-taglib supported. and 2.0 is the only allowed value
 for this attribute.

 Regards,
 Jakob

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

 Deplyoing very simple JARs, like:

 https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar

 should work, out of the box. Doesn't the spec explicitly talk about this
 for backward compatibility?
 Sure, when you extend the old Facelets classes, you have to have it
 deployed
 as well (and there is some parameter to disable Facelets2)

 -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: [core] Backwards compatibility (e.g. MYFACES-2543)

On Tue, Feb 9, 2010 at 7:23 PM, Jakob Korherr jakob.korh...@gmail.com wrote:
 It is a bug to allow old facelets taglibs which are not marked with
 version=2.0 with the built-in facelets implementation.

do you mind filing one against them :-)
I wonder what they have to say for that...

-Matthias


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

 maybe I am conservative, but I doubt that it is a bug, to allow old
 facelets-based tag JARs.
 You are saying it is, right ?

 On Tue, Feb 9, 2010 at 7:04 PM, Leonardo Uribe lu4...@gmail.com wrote:
  Hi
 
  I agree with Jakob.
 
  Just a small comment, doing some black box tests between myfaces and ri
  I
  notice long time ago that ri cannot read faces-config.xml without have
  version 2.0 in that file. It seems they fix that but a side effect is
  what
  we are seeing right now (facelets taglibs 1.1.x read). I think myfaces
  is
  doing right and really ri is mixing the two config files by some unknown
  reason.
 
  regards,
 
  Leonardo Uribe
 
  2010/2/9 Jakob Korherr jakob.korh...@gmail.com
 
  On my opinion you have to differentiate between 1.x taglibs and 2.0
  taglibs in some way, because MyFaces cannot know if this taglib will or
  won't run. If you can ensure that your 1.x-taglib runs with facelets
  2.0 you
  simply have to add version=2.0 to your taglib and it will function
  properly.
 
  This is also specified in the spec (although completely hidden in the
  appendix): take a look at the xsd type definition of
  facelet-taglib-versionType. It says This type contains the recognized
  versions of facelet-taglib supported. and 2.0 is the only allowed
  value
  for this attribute.
 
  Regards,
  Jakob
 
  2010/2/9 Matthias Wessendorf mat...@apache.org
 
  Deplyoing very simple JARs, like:
 
 
  https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar
 
  should work, out of the box. Doesn't the spec explicitly talk about
  this
  for backward compatibility?
  Sure, when you extend the old Facelets classes, you have to have it
  deployed
  as well (and there is some parameter to disable Facelets2)
 
  -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: [core] Backwards compatibility (e.g. MYFACES-2543)

...and, of course, when you extend old Facelets classes, this is NOT
supported.

However the JSF spec has provided a backdoor:
== javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER

for that you need to ship old Facelets.

-Matthias


On Tue, Feb 9, 2010 at 7:25 PM, Matthias Wessendorf mat...@apache.org wrote:
 ... on the other hand, the EG says, that JSF2.0 RT can be used to
 deploy a JSF1.2 based application.
 Since Facelets was just some random proprietary framework, ignoring
 the old Facelets DTD is I
 think correct;

 Still it is IMO a bit lame.

 -Matthias

 On Tue, Feb 9, 2010 at 7:20 PM, Matthias Wessendorf mat...@apache.org wrote:
 maybe I am conservative, but I doubt that it is a bug, to allow old
 facelets-based tag JARs.
 You are saying it is, right ?

 On Tue, Feb 9, 2010 at 7:04 PM, Leonardo Uribe lu4...@gmail.com wrote:
 Hi

 I agree with Jakob.

 Just a small comment, doing some black box tests between myfaces and ri I
 notice long time ago that ri cannot read faces-config.xml without have
 version 2.0 in that file. It seems they fix that but a side effect is what
 we are seeing right now (facelets taglibs 1.1.x read). I think myfaces is
 doing right and really ri is mixing the two config files by some unknown
 reason.

 regards,

 Leonardo Uribe

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

 On my opinion you have to differentiate between 1.x taglibs and 2.0
 taglibs in some way, because MyFaces cannot know if this taglib will or
 won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 
 you
 simply have to add version=2.0 to your taglib and it will function
 properly.

 This is also specified in the spec (although completely hidden in the
 appendix): take a look at the xsd type definition of
 facelet-taglib-versionType. It says This type contains the recognized
 versions of facelet-taglib supported. and 2.0 is the only allowed value
 for this attribute.

 Regards,
 Jakob

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

 Deplyoing very simple JARs, like:

 https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar

 should work, out of the box. Doesn't the spec explicitly talk about this
 for backward compatibility?
 Sure, when you extend the old Facelets classes, you have to have it
 deployed
 as well (and there is some parameter to disable Facelets2)

 -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




-- 
Matthias Wessendorf

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

Re: [core] Backwards compatibility (e.g. MYFACES-2543)