date:20100211


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

Jakob Korherr resolved MYFACES-2548.


   Resolution: Fixed
Fix Version/s: 2.0.0-beta-2

 META-INF resource lookup in OSGi environment
 

 Key: MYFACES-2548
 URL: https://issues.apache.org/jira/browse/MYFACES-2548
 Project: MyFaces Core
  Issue Type: Improvement
  Components: General
Affects Versions: 2.0.0-beta-2
Reporter: Jarek Gawor
Assignee: Jakob Korherr
 Fix For: 2.0.0-beta-2

 Attachments: MYFACES-2548.patch


 MyFaces uses context class loader to lookup META-INF resources. This works 
 fine in a regular Java environment but breaks in OSGi. One easy solution for 
 this would be to first ask the CCL for the resource and if none is found ask 
 the surrounding class class loader for that resource (assuming the resource 
 we are looking for lives in the same jar as the class loading it), i.e.:
 URL foo = getContextClassLoader().getResource(META-INF/foo);
 if (foo == null) {
   foo = getClass().getClassLoader().getResource(META-INF/foo);
 }
 There are a few places in MyFaces code that would need to be updated to use 
 this fallback approach. For example in IncludeHandler.java and 
 ErrorPageWriter.java.
 I also noticed that for some reason the myfaces-dev-debug.xml and 
 myfaces-dev-error.xml live in the api module. They seem to be only used the 
 impl module so they shouldn't really be needed in the api module. 

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

[jira] Created: (MYFACES-2549) Support for valueChangeListener method without ValueChangeEvent parameter

Support for valueChangeListener method without ValueChangeEvent parameter
-

 Key: MYFACES-2549
 URL: https://issues.apache.org/jira/browse/MYFACES-2549
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-314
Affects Versions: 2.0.0-beta-2
Reporter: Jakob Korherr
Assignee: Jakob Korherr


A ValueChangeListener method can now also take no arguments (see javadoc for 
MethodExpressionValueChangeListener for details)

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

[jira] Created: (EXTSCRIPT-63) NPE at startup if wrong configuration is used

2010-02-11 Thread Werner Punz (JIRA)

NPE at startup if wrong configuration is used
-

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


There is an NPE if a version of myfaces which is too old is used, we have to 
set a proper error message here post alpha 1, to notify the user about his 
setup error!

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

[jira] Updated: (TRINIDAD-1719) ajax xml response is not valid in some cases

2010-02-11 Thread JIRA


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

Xavier Brénuchon updated TRINIDAD-1719:
---

Status: Patch Available  (was: Open)

 ajax xml response is not valid in some cases
 

 Key: TRINIDAD-1719
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1719
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 1.2.13-core 
Reporter: Xavier Brénuchon
 Attachments: TRINIDAD_1719.patch


 Hello,
 There is a probleme with ajax calls in trinidad 1.2.13 (not with 1.2.9).
 For exemple : I want use a table with a sortable colomun. When I click on the 
 column header, there is an ajax call.
 But the xml response is not valid and the page made a repost.
 The xml response is not valid because in my page (not in the table), I have, 
 for exemple, a 'h:outputText' with accented character as value.
 Indeed, this 'h:outputText' has written its value in the ajax xml output. 
 (not in a 'fragment', not in a CDATA section).
 There is 2 problems :
  First, this 'h:outputText' should not write to output, because it is not 
 affected by the partial render (this 'h:outputText' is not in the table). 
 (This first problem was present in trinidad 1.2.9)
  Second, even if this accented value is written is the output stream and not 
 in a cdata section, accented characters must be compatible with xml (#x 
 hexa; for exemple) (This problem is new in trinidad 1.2.13)
 I looked at source code and I found where are bugs.
 First the h:outputText is not ignored because a method must be uncommented  :
 PPRResponseWriter.java, ligne 219 :
   /* Needed in JSF 1.2
   @Override
   public void writeText(Object  text,
 UIComponent component,
 String  propertyName) throws IOException
   {
 if (_isInsideTarget()  (text != null))
   super.writeText(text, component, propertyName);
   }
   */
 This method must be uncomment, because for h:outputText, there is no test 
 _isInsideTarget.
 Second, In DispatchResponseConf.java, ligne 75, the content type is searched 
 in RequestStateMap (a new class from 1.2.13) :
 return (String) 
 RequestStateMap.getInstance(context.getExternalContext()).get(__CONTENT_TYPE_KEY);
 The problem is that the content type is not inserted in RequestStateMap, but 
 always by the old way (1.2.9) ie request.setAttribut.
 So trinidad don't finds content type (here :'text/xml') and uses the default 
 HtmlResponseWriter and not XhtmlResponseWriter (see CoreRenderKit.java line 
 592)
 So we must correct both where the content type is written :
 DispatchRenderResponse.java, ligne 45 :
   
 _request.setAttribute(DispatchResponseConfiguratorImpl.__CONTENT_TYPE_KEY, 
 ct.getContentType());
   
 and DispatchServletResponse.java, ligne 49 :
   
 _request.setAttribute(DispatchResponseConfiguratorImpl.__CONTENT_TYPE_KEY, 
 ct.getContentType());
 Replace these two line with :
   RequestStateMap.getInstance(_request).put(__CONTENT_TYPE_KEY, 
 ct.getContentType());

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

[jira] Commented: (MYFACES-2541) Support for actionlistener method without ActionEvent parameter

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

Jakob Korherr commented on MYFACES-2541:

Martin,

PLEASE try to write the code in a constant style and also really try to follow
the code style guidelines. Your { } brackets are mostly set wrong (especially
in the test case) and you also tend to include lots of unnecessary blanks (e.g.
EasyMock.aryEq( new Object [] {})). Of course, this is not wrong, but it looks
very odd. Furthermore the license information was missing in the test case. I
also noticed two static variables at the bottom of the class. Static variables
and methods should always be at the top of the class.

I also noticed that you did not write the tearDown() method as supposed (set
all instances created in setUp() to null) and I also completed the last test
case testRestoreState() by using reflection to verify that the state is
restored correctly.

Support for actionlistener method without ActionEvent parameter
---

Key: MYFACES-2541
URL: https://issues.apache.org/jira/browse/MYFACES-2541
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces trunk
Reporter: Martin Koci
Assignee: Jakob Korherr
Attachments: MYFACES-2541.patch

With JSF 2.0 is possible to have actionListener method without ActionEvent
param:
https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/event/MethodExpressionActionListener.html#MethodExpressionActionListener

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

[jira] Created: (EXTSCRIPT-64) NPE in JSR199Compiler in certain situations

2010-02-11 Thread Werner Punz (JIRA)

NPE in JSR199Compiler in certain situations
---

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


Seems like the JDK does not have consistent behavior over all platforms 
diagnostics.getSource can return null values, hence we have to add a null check 
for everything in createErrorMessage

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

[jira] Commented: (MYFACES-2541) Support for actionlistener method without ActionEvent parameter

2010-02-11 Thread Martin Koci (JIRA)


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

Martin Koci commented on MYFACES-2541:
--

Yes, this patch was done before you directed me to 
http://wiki.apache.org/myfaces/MyFaces_Developer_Notes. Next patch will be 
better, I promise. Can you please write those rules on wiki in a form of 
checklist like class must conform: 1) no unused imports 2) static (even 
private) variables at the top of class 3)  It's very difficult to remember 
those rules over projects, trinidad for example wants all private members at 
the bottom of the class and with _ in name, other rules in EclipseLink, 
Spring etc...



 Support for actionlistener method without ActionEvent parameter
 ---

 Key: MYFACES-2541
 URL: https://issues.apache.org/jira/browse/MYFACES-2541
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-beta-2
 Environment: myfaces trunk
Reporter: Martin Koci
Assignee: Jakob Korherr
 Attachments: MYFACES-2541.patch


 With JSF 2.0 is possible to have actionListener method without ActionEvent 
 param: 
 https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/event/MethodExpressionActionListener.html#MethodExpressionActionListener

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

[jira] Commented: (MYFACES-2541) Support for actionlistener method without ActionEvent parameter


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

Jakob Korherr commented on MYFACES-2541:


I also don't see the problem with the VariableMapper. Maybe you could explain 
that to me, please.

For now I'll commit an altered version of your patch without the changes in 
ActionSourceRule.

 Support for actionlistener method without ActionEvent parameter
 ---

 Key: MYFACES-2541
 URL: https://issues.apache.org/jira/browse/MYFACES-2541
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-beta-2
 Environment: myfaces trunk
Reporter: Martin Koci
Assignee: Jakob Korherr
 Attachments: MYFACES-2541.patch


 With JSF 2.0 is possible to have actionListener method without ActionEvent 
 param: 
 https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/event/MethodExpressionActionListener.html#MethodExpressionActionListener

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

[jira] Commented: (MYFACES-2541) Support for actionlistener method without ActionEvent parameter


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

Jakob Korherr commented on MYFACES-2541:


Just take a look at some other classes on MyFaces core for the style infos. And 
sorry, I did not know that from trinidad...

 Support for actionlistener method without ActionEvent parameter
 ---

 Key: MYFACES-2541
 URL: https://issues.apache.org/jira/browse/MYFACES-2541
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-beta-2
 Environment: myfaces trunk
Reporter: Martin Koci
Assignee: Jakob Korherr
 Attachments: MYFACES-2541.patch


 With JSF 2.0 is possible to have actionListener method without ActionEvent 
 param: 
 https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/event/MethodExpressionActionListener.html#MethodExpressionActionListener

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

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

[jira] Commented: (MYFACES-2541) Support for actionlistener method without ActionEvent parameter

2010-02-11 Thread Martin Koci (JIRA)


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

Martin Koci commented on MYFACES-2541:
--

Problem with variableMapper:
1) template client:
h:body 
ui:decorate template=template.xhtml
  ui:param name=bean value=#{beanA} /
/ui:decorate
/h:body

2) Template:
f:subview xmlns:f=http://java.sun.com/jsf/core; 
xmlns:h=http://java.sun.com/jsf/html;
h:form 
  h:commandButton value=Click actionListener=#{bean.processAction} /
/h:form
/f:subview

a) if bean.processAction is method with actionEvent there is no problem and 
method is called

b) id bean.processAction is method without actionEvent param - 
javax.el.PropertyNotFoundException: Target Unreachable, identifier 'bean' 
resolved to null
at org.apache.el.parser.AstValue.getTarget(AstValue.java:67)
at org.apache.el.parser.AstValue.invoke

Explanation: TagAttribute.getMethodExpression creates a MethodExpression with 
variableMapper (because it is aware of facelets context, but 
ExpressionFactory.createMethodExpression() used in 
MethodExpressionActionListener cannot reach to facelets mapping. It can be easy 
seen while debugging: first MethodExpression has a orig.varMapper attribute 
with bean = beanA, but second MethodExpression created in 
MethodExpressionActionListener has this attribute null.


 Support for actionlistener method without ActionEvent parameter
 ---

 Key: MYFACES-2541
 URL: https://issues.apache.org/jira/browse/MYFACES-2541
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-beta-2
 Environment: myfaces trunk
Reporter: Martin Koci
Assignee: Jakob Korherr
 Attachments: MYFACES-2541.patch


 With JSF 2.0 is possible to have actionListener method without ActionEvent 
 param: 
 https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/event/MethodExpressionActionListener.html#MethodExpressionActionListener

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

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

2010-02-11 Thread Jakob Korherr

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

[jira] Commented: (MYFACES-2541) Support for actionlistener method without ActionEvent parameter


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

Jakob Korherr commented on MYFACES-2541:


OK cool, I was not aware of that. Thanks!

 Support for actionlistener method without ActionEvent parameter
 ---

 Key: MYFACES-2541
 URL: https://issues.apache.org/jira/browse/MYFACES-2541
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-beta-2
 Environment: myfaces trunk
Reporter: Martin Koci
Assignee: Jakob Korherr
 Attachments: MYFACES-2541.patch


 With JSF 2.0 is possible to have actionListener method without ActionEvent 
 param: 
 https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/event/MethodExpressionActionListener.html#MethodExpressionActionListener

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

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

[jira] Updated: (MYFACES-2541) Support for actionlistener method without ActionEvent parameter


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

Jakob Korherr updated MYFACES-2541:
---

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

 Support for actionlistener method without ActionEvent parameter
 ---

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

 Attachments: MYFACES-2541.patch


 With JSF 2.0 is possible to have actionListener method without ActionEvent 
 param: 
 https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/event/MethodExpressionActionListener.html#MethodExpressionActionListener

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

[jira] Resolved: (MYFACES-2549) Support for valueChangeListener method without ValueChangeEvent parameter


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

Jakob Korherr resolved MYFACES-2549.


   Resolution: Fixed
Fix Version/s: 2.0.0-beta-2

 Support for valueChangeListener method without ValueChangeEvent parameter
 -

 Key: MYFACES-2549
 URL: https://issues.apache.org/jira/browse/MYFACES-2549
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-314
Affects Versions: 2.0.0-beta-2
Reporter: Jakob Korherr
Assignee: Jakob Korherr
 Fix For: 2.0.0-beta-2


 A ValueChangeListener method can now also take no arguments (see javadoc for 
 MethodExpressionValueChangeListener for details)

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

[jira] Updated: (MYFACES-2540) Facelets server state saving does not work


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

Leonardo Uribe updated MYFACES-2540:


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

Thanks to Martin Koci for provide this patch

 Facelets server state saving does not work
 --

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

 Attachments: MYFACES-2540-2.patch, MYFACES-2540.patch


 Facelets server state saving does not work:  StateManager.saveView in not 
 called during ViewDeclarationLanguage.renderView in case of server state 
 saving. Please  see attached patch for details.

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

[jira] Resolved: (MYFACES-2544) UIViewRoot skips uncorrectly encodeBegin


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

Leonardo Uribe resolved MYFACES-2544.
-

Resolution: Fixed
  Assignee: Leonardo Uribe  (was: Jakob Korherr)

Thanks to Martin Koci for provide this patch

 UIViewRoot skips uncorrectly encodeBegin
 

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

 Attachments: MYFACES-2544-2.patch, MYFACES-2544-3.patch, 
 MYFACES-2544-4.patch, MYFACES-2544.patch


 javax.faces.component.UIViewRoot.encodeBegin(FacesContext) contains:
 if (!skipPhase) {
super.encodeBegin(context);
 }
 but skipPhase = context.getRenderResponse() || context.getResponseComplete() 
 - it
 makes sense for all phases except render response phase itself. That condition
 probably should be:
 if (!context.getResponseComplete()) {
 super.encodeBegin(context);
 }

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

[jira] Resolved: (MYFACES-2520) UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty


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

Leonardo Uribe resolved MYFACES-2520.
-

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

The proposed solution works, so we can close this issue

 UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty
 

 Key: MYFACES-2520
 URL: https://issues.apache.org/jira/browse/MYFACES-2520
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-beta-2
Reporter: Matthias Weßendorf
Assignee: Leonardo Uribe
 Fix For: 2.0.0-beta-2


 SEVERE: 
 java.lang.UnsupportedOperationException: This request class is an empty 
 placeholder
   at 
 org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:56)
   at $Proxy0.getContentType(Unknown Source)
   at 
 javax.servlet.ServletRequestWrapper.getContentType(ServletRequestWrapper.java:145)
   at 
 org.apache.myfaces.context.servlet.ServletExternalContextImpl.getRequestContentType(ServletExternalContextImpl.java:322)
   at 
 org.apache.myfaces.trinidad.util.ExternalContextUtils.getContentType(ExternalContextUtils.java:341)
   at 
 org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.isMultipartRequest(MultipartFormHandler.java:57)
   at 
 org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:109)
   at 
 org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:532)
   at 
 org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211)
   at 
 org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:327)
   at 
 org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.init(FacesContextFactoryImpl.java:90)
   at 
 org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:68)
   at 
 org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140)
   at 
 org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109)
   at 
 org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155)
   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:1250)
   at 
 org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
   at 
 org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
   at 
 org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115)
   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

[jira] Resolved: (MYFACES-2539) setPropertyActionListener cannot be nested within facelets tag


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

Leonardo Uribe resolved MYFACES-2539.
-

Resolution: Duplicate
  Assignee: Leonardo Uribe

Duplicate of MYFACES-2543

 setPropertyActionListener cannot be nested within facelets tag
 --

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

 nesting setPropertyActionListener like this:
 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:test=http://j4fry.org/test;
   xmlns:ui=http://java.sun.com/jsf/facelets;   
   body
   h:form
   test:button value=test
   f:setPropertyActionListener value=test 
 target=#{myBean.test} /
   /test:button
   #{myBean.test}
   /h:form
   /body
 /html
 produces this error:
 f:setPropertyActionListener Parent is not composite component or of type 
 ActionSource, type is: javax.faces.component.html.htmlf...@366ef7ba
 When using this taglib.xml and tag from doc-root/META-INF:
 !DOCTYPE facelet-taglib PUBLIC
   -//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN
   http://java.sun.com/dtd/facelet-taglib_1_0.dtd;
 facelet-taglib
   namespacehttp://j4fry.org/test/namespace
   tag
   tag-namebutton/tag-name
   sourcebutton.xhtml/source
   /tag
 /facelet-taglib
 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;
   ui:composition   
   h:commandButton value=test
   ui:insert /
   /h:commandButton
   /ui:composition 
 /html

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

[jira] Resolved: (MYFACES-2521) Parent not composite component or an instance of ClientBehaviorHolder: javax.faces.component.uiviewr...@19f5e3f


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

Leonardo Uribe resolved MYFACES-2521.
-

Resolution: Duplicate
  Assignee: Leonardo Uribe

Duplicate of MYFACES-2543

 Parent not composite component or an instance of ClientBehaviorHolder: 
 javax.faces.component.uiviewr...@19f5e3f
 ---

 Key: MYFACES-2521
 URL: https://issues.apache.org/jira/browse/MYFACES-2521
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-alpha
Reporter: Matthias Weßendorf
Assignee: Leonardo Uribe

 running the Trinidad demo (clientBehavior demo), I see this exception:
 javax.faces.view.facelets.TagException: /demos/clientBehaviorHolder.xhtmlat 
 line 59 and column 82 trd:invokeFunctionBehavior Parent not composite 
 component or an instance of ClientBehaviorHolder: 
 javax.faces.component.uiviewr...@19f5e3f
   at 
 org.apache.myfaces.view.facelets.tag.jsf.BehaviorTagHandlerDelegate.apply(BehaviorTagHandlerDelegate.java:85)
   at 
 javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:54)
   at 
 javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:51)
   at 
 org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:150)
   at 
 org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57)
   at 
 org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:45)
   at 
 org.apache.myfaces.view.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:103)
   at 
 org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.buildView(FaceletViewDeclarationLanguage.java:271)
   at 
 org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:88)
   at 
 org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:201)
   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
   at 
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
   at 
 org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247)
   at 
 org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157)
   at 
 org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
   at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
   at 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
   at 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
   at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
   at 
 org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
   at 
 org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
   at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
   at org.mortbay.jetty.Server.handle(Server.java:326)
   at 
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536)
   at 
 org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:915)
   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:539)
   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
   at 
 org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
   at 
 org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)

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

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


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

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

[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

2010-02-11 Thread Max Starets


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

Re: [Vote] Trinidad plugins 1.2.12 release

2010-02-11 Thread Leonardo Uribe

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/http://people.apache.org/%7Ematzew/staging_repo/
 /url
 layoutdefault/layout
 /pluginRepository
 /pluginRepositories
 ...

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

 Thanks,
 Matthias

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

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

[jira] Created: (PORTLETBRIDGE-113) Remove AFTER_VIEW_CONTENT request attribute after renderering from it

Remove AFTER_VIEW_CONTENT request attribute after renderering from it
-

 Key: PORTLETBRIDGE-113
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-113
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha, 1.0.0-beta
Reporter: Michael Freedman
Assignee: Michael Freedman


This will avoid it being reused in local portals where portlets in the same web 
app run in the same underlying portal/servlet request.

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

[jira] Created: (PORTLETBRIDGE-114) FacesContext.release should release the request attributes added during bridge/faces lifecycle

FacesContext.release should release the request attributes added during 
bridge/faces lifecycle
--

 Key: PORTLETBRIDGE-114
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-114
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha, 1.0.0-beta
Reporter: Michael Freedman
Assignee: Michael Freedman


to avoid them getting in the way of other portlets running in the same request 
(this occurs in local portals that run multiple portlets all in the portals 
servlet request.

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

[jira] Created: (PORTLETBRIDGE-115) Reacquire preexistingRequestAttributes in renderRedirect after FacesContext.release

Reacquire preexistingRequestAttributes in renderRedirect after 
FacesContext.release
---

 Key: PORTLETBRIDGE-115
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-115
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha, 1.0.0-beta
Reporter: Michael Freedman
Assignee: Michael Freedman


As FacesContext.release now releases all request attributes that didn't exist 
prior to the bridge being called we need to reconstruct the 
PreExistingRequestAttributes list after calling facesContext.release() in the 
renderRedirect (BridgeImpl) as this attribute is among those relese() removes.

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

[jira] Created: (PORTLETBRIDGE-116) Bridge (BridgeImpl) Lifecycle listener should only process if this instance (thread) is the active in the lifecycle

Bridge (BridgeImpl) Lifecycle listener should only process if this instance 
(thread) is the active in the lifecycle
---

 Key: PORTLETBRIDGE-116
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-116
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha, 1.0.0-beta
Reporter: Michael Freedman
Assignee: Michael Freedman


A Faces Lifecycle is shared among instances in the web app.  This means a 
LifecyleListener must take care and only run/process if it determines that it 
has been called from its particular usage/run of the Lifecycle.  It determines 
this by ensuring that the FacesContext in the passed event is the same as the 
current FacesContext (FacesContext.getCurrentInstance) i.e. the one in our 
thread.

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

Re: [Vote] Trinidad plugins 1.2.12 release

2010-02-11 Thread Leonardo Uribe

Hi Matthias

Ok, in that case my vote is +1.

@fix: Ok, now I remember this plugin uses a xslt transformation to merge.
Thanks for the tip.

regards,

Leonardo Uribe

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

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/http://people.apache.org/%7Ematzew/staging_repo/
/url
layoutdefault/layout
/pluginRepository
/pluginRepositories
...

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

Thanks,
Matthias

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

--
Matthias Wessendorf

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

[jira] Created: (PORTLETBRIDGE-117) Portlet 2.0 Bridge ExternalContext.redirect during render must encode PublicRenderParameters into url prior to encoding as an action

Portlet 2.0 Bridge ExternalContext.redirect during render must encode 
PublicRenderParameters into url prior to encoding as an action


 Key: PORTLETBRIDGE-117
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-117
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman


Redirect during render is supposed to simulate a real redirect (since portlets 
don't allow real redirects during render).  In doing so any public render 
parameters sent in the original request need to be preserved in the render 
redirect.  The bridge needs to encode these values as part of the URL being 
carried forward during its processign of ExternalContext.redirect

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

[jira] Created: (PORTLETBRIDGE-118) BridgeRenderRequestWrapper needs to individually manage public and private parameters

BridgeRenderRequestWrapper needs to individually manage public and private 
parameters
-

 Key: PORTLETBRIDGE-118
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-118
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman


BridgeRenderRequestWrapper is used (in part) to handle render redirect.  The 
bridge wraps the original request with this one and overrides what appears to 
be the request parameters with the one's in the redirect url.  As Portlet 2.0 
distinguishes between public and private parameters, this wrapper needs to 
properly manage the parameters so that the APIs for getting the parameters, 
private params, and public params, all do the right thing.

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

[jira] Created: (PORTLETBRIDGE-119) Portlet 2.0 Bridge redisplay after redirect needs to update redirects PublicRenderParameter Map if redisplay sends new/different PRPs

Portlet 2.0 Bridge redisplay after redirect needs to update redirects 
PublicRenderParameter Map if redisplay sends new/different PRPs
-

 Key: PORTLETBRIDGE-119
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-119
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman


Normally in a redisplay following a render redirect the bridge will receive the 
same public render parameters it received in the request that triggered the 
redirect.  However if the value of one or more PRPs has changed since redirect 
(and before the redisplay) the bridge needs to detect the changes and apply 
them to the one's being managed for the redirect (cache).  I.e. the bridge 
needs to cache the existing PRPs when the render redirect occurs.  If we get a 
redisplay it compares the incoming PRPs to the cached PRPs.  If there are 
differences it applies them to the cached redirect URL.

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

[jira] Created: (PORTLETBRIDGE-120) Portlet 2.0 Bridge -- not all AddPhaseListeners in bridge lifecycle are followed by a RemovePhaseListener

Portlet 2.0 Bridge -- not all AddPhaseListeners in bridge lifecycle are 
followed by a RemovePhaseListener
-

 Key: PORTLETBRIDGE-120
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-120
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman


Clean up BridgeImpl so that all the Bridge's lifecycle methods (doFacesRequest) 
properly call RemovePhaseListener in all methods that it adds itself as a phase 
listener before running the lifecycle.

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

[jira] Resolved: (PORTLETBRIDGE-119) Portlet 2.0 Bridge redisplay after redirect needs to update redirects PublicRenderParameter Map if redisplay sends new/different PRPs


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

Michael Freedman resolved PORTLETBRIDGE-119.


   Resolution: Fixed
Fix Version/s: 2.0.0

Does what the bug indicated.

 Portlet 2.0 Bridge redisplay after redirect needs to update redirects 
 PublicRenderParameter Map if redisplay sends new/different PRPs
 -

 Key: PORTLETBRIDGE-119
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-119
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 2.0.0


 Normally in a redisplay following a render redirect the bridge will receive 
 the same public render parameters it received in the request that triggered 
 the redirect.  However if the value of one or more PRPs has changed since 
 redirect (and before the redisplay) the bridge needs to detect the changes 
 and apply them to the one's being managed for the redirect (cache).  I.e. the 
 bridge needs to cache the existing PRPs when the render redirect occurs.  If 
 we get a redisplay it compares the incoming PRPs to the cached PRPs.  If 
 there are differences it applies them to the cached redirect URL.

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

[jira] Resolved: (PORTLETBRIDGE-120) Portlet 2.0 Bridge -- not all AddPhaseListeners in bridge lifecycle are followed by a RemovePhaseListener


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

Michael Freedman resolved PORTLETBRIDGE-120.


   Resolution: Fixed
Fix Version/s: 2.0.0

Added the necessary RemovePhaseListeners in finally statements

 Portlet 2.0 Bridge -- not all AddPhaseListeners in bridge lifecycle are 
 followed by a RemovePhaseListener
 -

 Key: PORTLETBRIDGE-120
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-120
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 2.0.0


 Clean up BridgeImpl so that all the Bridge's lifecycle methods 
 (doFacesRequest) properly call RemovePhaseListener in all methods that it 
 adds itself as a phase listener before running the lifecycle.

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

[jira] Resolved: (PORTLETBRIDGE-118) BridgeRenderRequestWrapper needs to individually manage public and private parameters


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

Michael Freedman resolved PORTLETBRIDGE-118.


   Resolution: Fixed
Fix Version/s: 2.0.0

Now manages each Map individually.

 BridgeRenderRequestWrapper needs to individually manage public and private 
 parameters
 -

 Key: PORTLETBRIDGE-118
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-118
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 2.0.0


 BridgeRenderRequestWrapper is used (in part) to handle render redirect.  The 
 bridge wraps the original request with this one and overrides what appears to 
 be the request parameters with the one's in the redirect url.  As Portlet 2.0 
 distinguishes between public and private parameters, this wrapper needs to 
 properly manage the parameters so that the APIs for getting the parameters, 
 private params, and public params, all do the right thing.

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

[jira] Resolved: (PORTLETBRIDGE-117) Portlet 2.0 Bridge ExternalContext.redirect during render must encode PublicRenderParameters into url prior to encoding as an action


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

Michael Freedman resolved PORTLETBRIDGE-117.


   Resolution: Fixed
Fix Version/s: 2.0.0

Added encoding the PRPs

 Portlet 2.0 Bridge ExternalContext.redirect during render must encode 
 PublicRenderParameters into url prior to encoding as an action
 

 Key: PORTLETBRIDGE-117
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-117
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 2.0.0


 Redirect during render is supposed to simulate a real redirect (since 
 portlets don't allow real redirects during render).  In doing so any public 
 render parameters sent in the original request need to be preserved in the 
 render redirect.  The bridge needs to encode these values as part of the URL 
 being carried forward during its processign of ExternalContext.redirect

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

[jira] Resolved: (PORTLETBRIDGE-116) Bridge (BridgeImpl) Lifecycle listener should only process if this instance (thread) is the active in the lifecycle


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

Michael Freedman resolved PORTLETBRIDGE-116.


   Resolution: Fixed
Fix Version/s: 2.0.0
   1.0.0

Tests to see if the FacesContext in teh event is the same as the 
CurrentInstance.

 Bridge (BridgeImpl) Lifecycle listener should only process if this instance 
 (thread) is the active in the lifecycle
 ---

 Key: PORTLETBRIDGE-116
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-116
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-beta, 2.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 1.0.0, 2.0.0


 A Faces Lifecycle is shared among instances in the web app.  This means a 
 LifecyleListener must take care and only run/process if it determines that it 
 has been called from its particular usage/run of the Lifecycle.  It 
 determines this by ensuring that the FacesContext in the passed event is the 
 same as the current FacesContext (FacesContext.getCurrentInstance) i.e. the 
 one in our thread.

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

[jira] Resolved: (PORTLETBRIDGE-115) Reacquire preexistingRequestAttributes in renderRedirect after FacesContext.release


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

Michael Freedman resolved PORTLETBRIDGE-115.


   Resolution: Fixed
Fix Version/s: 2.0.0
   1.0.0

 Reacquire preexistingRequestAttributes in renderRedirect after 
 FacesContext.release
 ---

 Key: PORTLETBRIDGE-115
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-115
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-beta, 2.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 1.0.0, 2.0.0


 As FacesContext.release now releases all request attributes that didn't exist 
 prior to the bridge being called we need to reconstruct the 
 PreExistingRequestAttributes list after calling facesContext.release() in the 
 renderRedirect (BridgeImpl) as this attribute is among those relese() removes.

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

[jira] Resolved: (PORTLETBRIDGE-114) FacesContext.release should release the request attributes added during bridge/faces lifecycle


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

Michael Freedman resolved PORTLETBRIDGE-114.


   Resolution: Fixed
Fix Version/s: 2.0.0
   1.0.0

 FacesContext.release should release the request attributes added during 
 bridge/faces lifecycle
 --

 Key: PORTLETBRIDGE-114
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-114
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-beta, 2.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 1.0.0, 2.0.0


 to avoid them getting in the way of other portlets running in the same 
 request (this occurs in local portals that run multiple portlets all in the 
 portals servlet request.

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

[jira] Resolved: (PORTLETBRIDGE-113) Remove AFTER_VIEW_CONTENT request attribute after renderering from it


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

Michael Freedman resolved PORTLETBRIDGE-113.


   Resolution: Fixed
Fix Version/s: 2.0.0
   1.0.0

 Remove AFTER_VIEW_CONTENT request attribute after renderering from it
 -

 Key: PORTLETBRIDGE-113
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-113
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-beta, 2.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 1.0.0, 2.0.0


 This will avoid it being reused in local portals where portlets in the same 
 web app run in the same underlying portal/servlet request.

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

[jira] Resolved: (MYFACES-2503) f:event should support no arg method on listener attribute


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

Jakob Korherr resolved MYFACES-2503.


   Resolution: Fixed
Fix Version/s: 2.0.0-beta-2

 f:event should support no arg method on listener attribute
 --

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


 It seems ri is able to use no arg method as a listener attribute for f:event 
 tag, according to a discussion on jsr-314-open mailing list. (TOPIC: 
 [jsr-314-open] Method signatures for event handlers). See this issue:
 https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=731
  If that is true, myfaces should do the same.

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

[jira] Created: (MYFACES-2550) AnnotationConfigurator and scanning of myfaces impl jar

2010-02-11 Thread Jarek Gawor (JIRA)

AnnotationConfigurator and scanning of myfaces impl jar
---

 Key: MYFACES-2550
 URL: https://issues.apache.org/jira/browse/MYFACES-2550
 Project: MyFaces Core
  Issue Type: Improvement
  Components: General
Affects Versions: 2.0.0-beta-2
Reporter: Jarek Gawor


The AnnotationConfigurator.configure() code attempts to obtain the myfaces impl 
jar (by looking up META-INF/standard-faces-config.xml resource) and scans it 
for certain annotations.

This does not work in OSGi environment because of two issues: 1) the 
getMyfacesImplJarFile() uses context class loader to lookup the resource which 
most likely will return null, and 2) even if that method successfully looked up 
that resource, it won't be able to get a JarFile out it. That's because the url 
returned from resource lookup in OSGi environment can't be considered as a url 
to a jar file.

However, now I'm wondering if the annotation scanning of myfaces impl jar is 
needed at all. None of the classes within the jar have any of the annotations 
that the code is looking for... 


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

Re: MyFaces in OSGi

2010-02-11 Thread Jarek Gawor

Thanks for fixing MYFACES-2548! I just opened MYFACES-2550 for the
AnnotationConfigurator.getMyfacesImplJarFile() issue.

Thanks again,
Jarek

On Thu, Feb 11, 2010 at 12:19 AM, Jarek Gawor jga...@gmail.com wrote:
 Ok, sure. For now I created MYFACES-2548 with a proposed patch. I
 might open one more bug for the
 AnnotationConfigurator.getMyfacesImplJarFile() issue once I do little
 more testing.

 Jarek

 On Wed, Feb 10, 2010 at 5:51 PM, Jakob Korherr jakob.korh...@gmail.com 
 wrote:
 Hi Jarek,

 It would be great if you could file your problems as issues in the jira.
 Then I will take a look at them!

 Thanks,
 Jakob

 2010/2/10 Jarek Gawor jga...@gmail.com

 Hi all,

 I'm trying to make latest MyFaces core run in OSGi environment (in
 Geronimo 3.0) and I'm running into a few problems. I'm hoping to get
 your input on some of these problems. Here's our setup: we deploy
 myfaces-api and myfaces-impl as separate bundles and we also have a
 separate bundle that is the application (effectively a war file) that
 uses jsf. When running the application, Geronimo sets the context
 class loader to the application classloader which delegates the calls
 to the application bundle.

 Now, most of the problems we are running into are due to use of the
 context class loader in myfaces code to lookup resources within the
 META-INF directory.

 For example, IncludeHandler.java looks up
 META-INF/rsc/myfaces-dev-error-include.xhtml resource or
 FacesConfigurator.java looks up META-INF/standard-faces-config.xml
 resource via CCL. This works great in a regular Java environment but
 breaks in OSGi. One easy solution for this would be to first ask the
 CCL for the resource and if none is found ask the surrounding class
 class loader for that resource (assuming the resource we are looking
 for lives in the same jar as the class loading it), i.e.:

 URL foo = getContextClassLoader().getResource(META-INF/foo);
 if (foo == null) {
   foo = getClass().getClassLoader().getResource(META-INF/foo);
 }

 There are other more advanced work-arounds (e.g. ContextFinder in
 Equinox) but I'm wondering what people think about updating the
 MyFaces code to use this simple solution. Just to be clear, this only
 needs to be done for a few known resources that live within the impl
 or api jars and not for all resource lookups.

 The ErrorPageWriter.java also looks up some resources via CCL and can
 fall back to looking for META-INF/rsc/myfaces-dev-error.xml and
 META-INF/rsc/myfaces-dev-debug.xml. But these resources live in the
 api module for some reason. I'm not sure why but I'm hoping they can
 be moved to the impl module. That way the simple solution mentioned
 above would still work.

 My final problem is with
 AnnotationConfigurator.getMyfacesImplJarFile(). Besides the problem
 with META-INF lookup using CCL and even if that method successfully
 looked up that resource, it won't be able to get a JarFile out it.
 Because the url returned from resource lookup in OSGi environment
 can't be considered as a url to a jar file. So I think we will need a
 way to override that piece of code from Geronimo somehow. Maybe even
 making the getMyfacesImplJarFile() method protected would work for us
 (we can return a fake JarFile that deletes calls to a bundle object).

 Thanks,
 Jarek

[jira] Updated: (TRINIDAD-1681) Generated Facelets taglib.xml files contain the OLD DTD

2010-02-11 Thread Max Starets (JIRA)


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

Max Starets updated TRINIDAD-1681:
--

Status: Patch Available  (was: Open)

 Generated Facelets taglib.xml files contain the OLD DTD
 ---

 Key: TRINIDAD-1681
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1681
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.0-plugins
Reporter: Matthias Weßendorf
 Attachments: declaration.diff


 The currently generated artifacts use the old DTD:
 ?xml version=1.0 encoding=utf-8?
 !DOCTYPE facelet-taglib
   PUBLIC -//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN 
 http://java.sun.com/dtd/facelet-taglib_1_0.dtd;
 facelet-taglib xmlns=http://java.sun.com/JSF/Facelet;
 However, as of JSF 2.0 it has to be:
 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

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

[jira] Commented: (TRINIDAD-1681) Generated Facelets taglib.xml files contain the OLD DTD

2010-02-11 Thread Max Starets (JIRA)


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

Max Starets commented on TRINIDAD-1681:
---

See the provided patch. Note that the tr-base.taglib.xml will need to be 
modified to have the correct namespace/XSD declaration as well. These two 
changes have to be made at the same time, otherwise the merge of the statically 
defined tags with the ones generated by the plugin will fail.

 Generated Facelets taglib.xml files contain the OLD DTD
 ---

 Key: TRINIDAD-1681
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1681
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.0-plugins
Reporter: Matthias Weßendorf
 Attachments: declaration.diff


 The currently generated artifacts use the old DTD:
 ?xml version=1.0 encoding=utf-8?
 !DOCTYPE facelet-taglib
   PUBLIC -//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN 
 http://java.sun.com/dtd/facelet-taglib_1_0.dtd;
 facelet-taglib xmlns=http://java.sun.com/JSF/Facelet;
 However, as of JSF 2.0 it has to be:
 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

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

[Trinidad 2] PPR and AJAX

2010-02-11 Thread Andrew Robinson

Looking for feedback on the following requirements of the Trinidad+JSF2 AJAX
implementation:

   1. Client validation will only occur on requests made through Trinidad
   APIs
   2. Calls made to jsf.ajax.request will not perform client-side validation
   3. Trinidad will use jsf.ajax.request for its requests (after blocking ad
   client validation has been performed)
   4. Trinidad will leverage JSF2 server side classes to handle AJAX
   requests
   5. Blocking will only be used for requests through the Trinidad APIs
   6. Calls made to jsf.ajax.request will not block the UI

The code that is not working is multi-part form data (input file) submission
and the code that we have for mobile browsers. We will need to determine
what we want to do there since the AJAX layer in Mojarra and, I think,
MyFaces, is not as robust as what we have in Trinidad 1.2.

-Andrew

[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: [Trinidad 2] PPR and AJAX

2010-02-11 Thread Gabrielle Crawford


Hi Andrew,

Andrew Robinson wrote:
Looking for feedback on the following requirements of the 
Trinidad+JSF2 AJAX implementation:


   1. Client validation will only occur on requests made through
  Trinidad APIs
   2. Calls made to jsf.ajax.request will not perform client-side
  validation

I have this vague recollection that the inputDate is relying on client 
side conversion in trinidad, I think it sends milliseconds to the server 
rather than the string entered by the user, or maybe this is only 
happening when you open the date picker. I'm not totally sure about all 
this, but you may want to try out an inputDate for the case where you 
don't run client side validation.


Thanks,

Gabrielle

Re: [Vote] Trinidad plugins 1.2.12 release

2010-02-11 Thread Gabrielle Crawford


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

[jira] Updated: (TRINIDAD-1678) TrNumberFormat.prototype.numberToString doesn't account for numbers represented via scientific notation

2010-02-11 Thread Gabrielle Crawford (JIRA)

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

Gabrielle Crawford updated TRINIDAD-1678:
-

Resolution: Fixed
Status: Resolved (was: Patch Available)

TrNumberFormat.prototype.numberToString doesn't account for numbers
represented via scientific notation
---

Key: TRINIDAD-1678
URL: https://issues.apache.org/jira/browse/TRINIDAD-1678
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.12-core
Reporter: Cale Scholl
Priority: Minor
Attachments: scientificNotation_1.2.12.2.patch,
scientificNotation_trunk.patch

ISSUE:
--
Say we have a 22-digit number string 77. When this is
converted to object it becomes 7.777e+21. This confuses
TrNumberFormat.prototype.numberToString, as the poor guy thinks he's dealing
with a fractional number, when really it's a big ass integer.
FIX:
-
The solution is, when converting from object to string, we first convert the
string from scientific notation to standard expanded notation before applying
any other formatting. See TrNumberFormat.scientificToExpanded.
Note that I also added a utility method TrNumberFormat.trimLeadingZeroes.
This is preferable to the previous hack -- parseInt(parseFloat(numberString))
-- because parseInt fails to correctly parse numbers represented via
scientific notation (e.g. 7.777e+21 becomes 7).
TESTS:
--
Tested using the following:
af:inputText label=default id=it1
af:convertNumber maxFractionDigits=40/
/af:inputText
Results:
(1) 77 - 7.777e+21 -
7,777,777,777,777,777,000,000
(2) 0.123456 - 1.23456e-21 -
0.123456
(3) 1234.567890123456789012 - 1234.567890123457 - 1,234.567890123457
When would this fix possibly be useful? See case (2) above. That's the only
case where scientific notation is used AND we don't lose any precision.

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

[jira] Created: (MYFACES-2551) Set charset=iso-8859-1 using f:view in facelets page makes current page not being rendered

Set charset=iso-8859-1 using f:view in facelets page makes current page not 
being rendered


 Key: MYFACES-2551
 URL: https://issues.apache.org/jira/browse/MYFACES-2551
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-beta, 2.0.0-alpha
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Pages starting like this:

!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
  xmlns:h=http://java.sun.com/jsf/html;
  xmlns:f=http://java.sun.com/jsf/core;
  xmlns:ui=http://java.sun.com/jsf/facelets;
f:view contentType=text/html; charset=iso-8859-1/

are not rendered. If we remove charset=iso-8859-1, it works again.

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

[jira] Commented: (MYFACES-2551) Set charset=iso-8859-1 using f:view in facelets page makes current page not being rendered


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

Leonardo Uribe commented on MYFACES-2551:
-

There are no references in spec or javadoc related to that one, but it is a 
common form to set charset in html tags, so I asked to jsr-314-open list if 
this is valid or not.

 Set charset=iso-8859-1 using f:view in facelets page makes current page not 
 being rendered
 

 Key: MYFACES-2551
 URL: https://issues.apache.org/jira/browse/MYFACES-2551
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.0-alpha, 2.0.0-beta
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe

 Pages starting like this:
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html xmlns=http://www.w3.org/1999/xhtml;
   xmlns:h=http://java.sun.com/jsf/html;
   xmlns:f=http://java.sun.com/jsf/core;
   xmlns:ui=http://java.sun.com/jsf/facelets;
 f:view contentType=text/html; charset=iso-8859-1/
 are not rendered. If we remove charset=iso-8859-1, it works again.

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

Re: [Trinidad 2] PPR and AJAX

2010-02-11 Thread mamallan . uthaman


Hi Andrew,

Mobile browsers provide very limited support for JavaScript, and the 
level of support varies widely. Hence, unless jsf.ajax.request specially 
handles limitations of a mobile browser, using jsf.ajax.request probably 
won't work in mobile browsers. So to preserve PPR support, for mobile 
browsers, we can continue to use Trinidad APIs instead of jsf.ajax.request.


Thanks
Mamallan

On 2/11/2010 1:10 PM, Andrew Robinson wrote:
Looking for feedback on the following requirements of the 
Trinidad+JSF2 AJAX implementation:


   1. Client validation will only occur on requests made through
  Trinidad APIs
   2. Calls made to jsf.ajax.request will not perform client-side
  validation
   3. Trinidad will use jsf.ajax.request for its requests (after
  blocking ad client validation has been performed)
   4. Trinidad will leverage JSF2 server side classes to handle AJAX
  requests
   5. Blocking will only be used for requests through the Trinidad APIs
   6. Calls made to jsf.ajax.request will not block the UI

The code that is not working is multi-part form data (input file) 
submission and the code that we have for mobile browsers. We will need 
to determine what we want to do there since the AJAX layer in Mojarra 
and, I think, MyFaces, is not as robust as what we have in Trinidad 1.2.


-Andrew

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

2010-02-11 Thread Ganesh

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


+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

2010-02-11 Thread Ganesh


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.

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

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

2010-02-11 Thread Ganesh Jung (JIRA)


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

Ganesh Jung reopened MYFACES-2543:
--


reasons for reopning this where discussed on the dev list:

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

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

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

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