date:20110111

Hi,

on tomcat 7 it works (I just had to add MyFaces 1.2.9 and JSTL 1.2 to
the demo WAR file).
I want to try JBoss AS5, but jboss.org is currently down.

I gave Stan silvert a heads up on this issue as well (he thought that
Tomcat 7 may have
the same issue - but it works in beta-5)

-Matthias

On Mon, Jan 10, 2011 at 7:43 PM, Christian Kaltepoth
christ...@kaltepoth.de wrote:
 As far as I know the schemaLocation attribute must always contain the
 namespace and the location of the XSD file. Specifying only the
 location of the XSD is wrong in my option as it is not clear for which
 namespace the XSD is (without downloading it of cause).

 But I might be wrong. I didn't find the correct section in the spec yet! :-)

 Christian

 2011/1/10 Matthias Wessendorf mat...@apache.org:
 meh...

 19:22:49,086 WARN  [SaxJBossXBParser] SchemaLocation: schemaLocation
 value = 'http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd'
 must have even number of URI's. @
 vfs:///home/matzew/JBoss6/jboss-6.0.0.Final/server/default/deploy/trinidad-demo-1.2.14.war/WEB-INF/lib/trinidad-impl-1.2.14.jar/META-INF/tr.tld[1,238]
 19:22:49,102 WARN  [JBossEntityResolver] Trying to resolve systemId as
 a non-file URL: http://java.sun.com/xml/ns/javaee



 this sucks :)

 Question is... should the container resolve it, or is the current behavior 
 OK...

 -Matthias


 On Mon, Jan 10, 2011 at 7:08 PM, Matthias Wessendorf mat...@apache.org 
 wrote:
 looks like we are OK here.

 (currently downloading JBoss to check details early 2morrow)

 -M

 On Mon, Jan 10, 2011 at 7:06 PM, Matthias Wessendorf mat...@apache.org 
 wrote:
 It looks like the TLD starts with the correct namespaces

 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/web-jsptaglibrary_2_1.xsd;
 version=2.1


  display-nameApache Trinidad Core/display-name
 ...
 ...

 -Matthias

 On Mon, Jan 10, 2011 at 7:04 PM, Matthias Wessendorf mat...@apache.org 
 wrote:
 So basically JBoss' JavaEE 6 container is not backwards compatible to EE5.

 Why are the URLs and elements outdated? Aren't say valid for JavaEE 5 ?

 -Matthias

 On Mon, Jan 10, 2011 at 6:09 PM, Christian Kaltepoth
 christ...@kaltepoth.de wrote:
 Hey Matthias,

 Although not being a team member I would like to add a comment on
 this. I recently had major problems deploying some of the MyFaces
 artifacts to the just released JBoss AS 6.0.0.Final. The problems were
 caused by invalid TLD descriptors generated by the MyFaces Builder
 Plugin. As far as I can tell the current trunk of Trinidad for JSF 1.2
 is also affected by this. Perhaps it would be a good idea if somebody
 of the Trinidad team takes a look at this before starting the release.

 Please refer to the following Tomahawk issue for details:

 https://issues.apache.org/jira/browse/TOMAHAWK-1560

 Kind regards

  Christian


 https://issues.apache.org/jira/browse/TOMAHAWK-1560
 2011/1/10, Matthias Wessendorf mat...@apache.org:
 Hi,

 I've created a Trinidad 1.2.14 release candidate, with the following
 artifacts
 up for a vote:

 SVN source tag (r1057250):
 http://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-1.2.14/

 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapachemyfaces-013/

 Source release:
 https://repository.apache.org/content/repositories/orgapachemyfaces-013/org/apache/myfaces/trinidad/trinidad/1.2.14/trinidad-1.2.14-source-release.zip

 Vote will be open for 72 hours.

 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)

 Thanks,
 Matthias

 --
 Matthias Wessendorf

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



 --
 Christian Kaltepoth
 Blog: http://chkal.blogspot.com/
 Twitter: http://twitter.com/chkal




 --
 Matthias Wessendorf

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




 --
 Matthias Wessendorf

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




 --
 Matthias Wessendorf

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




 --
 Matthias Wessendorf

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




 --
 Christian Kaltepoth
 Blog: http://chkal.blogspot.com/
 Twitter: http://twitter.com/chkal




-- 
Matthias Wessendorf

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

[jira] Created: (TOBAGO-965) Setting focus in popup does not work anymore with IE*

2011-01-11 Thread Helmut Swaczinna (JIRA)

Setting focus in popup does not work anymore with IE*
-

 Key: TOBAGO-965
 URL: https://issues.apache.org/jira/browse/TOBAGO-965
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Themes
Affects Versions: 1.0.33
 Environment: IE 6/7/8
Reporter: Helmut Swaczinna
Priority: Minor


Setting the input focus to first element of a popup when the popup is opened 
does not work anymore with IE. This is because the isFunction() test for 
element.focus() in lockPopupPage() return false in IE. Maybe isFunction() does 
not work at all in IE.

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

[jira] Commented: (MYFACES-2920) UISelectOne/UISelectMany validateValue: Before comparing each option, coerce the option value type to the type of component's value

2011-01-11 Thread JIRA


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

Martin Kočí commented on MYFACES-2920:
--

There is a test for enum 
javax.faces.component._SelectItemsUtilTest.testMatchValueWithEnums(), but it is 
currently @Ignored because requires myfaces-test 1.0.1-SNAPSHOT.

Leonardo, can you please add there a test for problems MYFACES-3010 and 
MYFACES-3011? I don't fully understand the problem yet.

And also please note that myfaces-test has own coercion implementation in 
MockExpressionFactory.coerceToType(Object, Class) and that can limit 
capabilities of testing in cases which heavily depend on EL implementation.


 UISelectOne/UISelectMany validateValue: Before comparing each option, coerce 
 the option value type to the type of component's value
 ---

 Key: MYFACES-2920
 URL: https://issues.apache.org/jira/browse/MYFACES-2920
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.2-SNAPSHOT
 Environment: myfaces trunk
Reporter: Martin Kočí
Assignee: Leonardo Uribe
 Fix For: 2.0.3

 Attachments: MYFACES-2920-v2.patch, MYFACES-2920.patch

   Original Estimate: 0h
  Remaining Estimate: 0h

 From JavaDoc UISelectOne/UISelectMany validateValue:
  ... Before comparing each option, coerce the option value type to the type 
 of this component's value following the Expression Language coercion rules 
 ...
 More here:
 http://markmail.org/message/mfhyyiogaz73yfr4

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

Re: [core] Improve error reporting and logging

2011-01-11 Thread Martin Marinschek

I am always for better error reporting!

best regards,

Martin

On 1/10/11, Jakob Korherr jakob.korh...@gmail.com wrote:
 Hi Kocicak,

 1

 Regards,
 Jakob

 2011/1/10 Martin Koci martin.kocicak.k...@gmail.com:

 Hi,

 the most wanted feature which our coders want is more consistent and
 human-readable error reporting and logging. Here is a example:

 If user specifies f:ajax without eventName for a component without
 defaultEventName, myfaces throw a execption:

 Now (myfaces 2.0.3):
 eventName could not be defined for f:ajax tag with no wrap mode.



 Improved (example only; from my copy of myfaces):

 MF0345: Your ajax tag does not specify eventName and component
 com.foo.Bazz does not provide the default one. Please use one from
 available: [change, blur, focus ...];

 Tag location: XYZ.xhtml line 56 column 23, f:ajax  . /

 Component: id: componentId,  class: com.foo.BazzInput, component type:
 org.renderkit.Input

 ViewId: YYZ.xhml, located in file system
 as: /tmp/deploy/weabpp/XYZ.xhtml

 PhaseId: RENDER_RESPONSE

 Details: ... a detailed description of this problem + suggestions,
 example of code.

 References:
 #  Click for problem MF0345 in MYFACES knowledge database (hypertext
 link)
 # Contact your technology team : m...@to.me
 # If you think this a bug report it: jira.project.org






 What do you think about this idea?

 (I'll describe our requirements and what I found so far in next emails)


 Regards,

 Kočičák





 --
 Jakob Korherr

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



-- 

http://www.irian.at

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

Professional Support for Apache MyFaces

Re: [VOTE] Apache MyFaces Trinidad 1.2.14

Similar to Tomcat 7, the WAR works fine inside of JBoss 5

-Matthias

On Tue, Jan 11, 2011 at 9:43 AM, Matthias Wessendorf mat...@apache.org wrote:
 Hi,

 on tomcat 7 it works (I just had to add MyFaces 1.2.9 and JSTL 1.2 to
 the demo WAR file).
 I want to try JBoss AS5, but jboss.org is currently down.

 I gave Stan silvert a heads up on this issue as well (he thought that
 Tomcat 7 may have
 the same issue - but it works in beta-5)

 -Matthias

 On Mon, Jan 10, 2011 at 7:43 PM, Christian Kaltepoth
 christ...@kaltepoth.de wrote:
 As far as I know the schemaLocation attribute must always contain the
 namespace and the location of the XSD file. Specifying only the
 location of the XSD is wrong in my option as it is not clear for which
 namespace the XSD is (without downloading it of cause).

 But I might be wrong. I didn't find the correct section in the spec yet! :-)

 Christian

 2011/1/10 Matthias Wessendorf mat...@apache.org:
 meh...

 19:22:49,086 WARN  [SaxJBossXBParser] SchemaLocation: schemaLocation
 value = 'http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd'
 must have even number of URI's. @
 vfs:///home/matzew/JBoss6/jboss-6.0.0.Final/server/default/deploy/trinidad-demo-1.2.14.war/WEB-INF/lib/trinidad-impl-1.2.14.jar/META-INF/tr.tld[1,238]
 19:22:49,102 WARN  [JBossEntityResolver] Trying to resolve systemId as
 a non-file URL: http://java.sun.com/xml/ns/javaee



 this sucks :)

 Question is... should the container resolve it, or is the current behavior 
 OK...

 -Matthias


 On Mon, Jan 10, 2011 at 7:08 PM, Matthias Wessendorf mat...@apache.org 
 wrote:
 looks like we are OK here.

 (currently downloading JBoss to check details early 2morrow)

 -M

 On Mon, Jan 10, 2011 at 7:06 PM, Matthias Wessendorf mat...@apache.org 
 wrote:
 It looks like the TLD starts with the correct namespaces

 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/web-jsptaglibrary_2_1.xsd;
 version=2.1


  display-nameApache Trinidad Core/display-name
 ...
 ...

 -Matthias

 On Mon, Jan 10, 2011 at 7:04 PM, Matthias Wessendorf mat...@apache.org 
 wrote:
 So basically JBoss' JavaEE 6 container is not backwards compatible to 
 EE5.

 Why are the URLs and elements outdated? Aren't say valid for JavaEE 5 ?

 -Matthias

 On Mon, Jan 10, 2011 at 6:09 PM, Christian Kaltepoth
 christ...@kaltepoth.de wrote:
 Hey Matthias,

 Although not being a team member I would like to add a comment on
 this. I recently had major problems deploying some of the MyFaces
 artifacts to the just released JBoss AS 6.0.0.Final. The problems were
 caused by invalid TLD descriptors generated by the MyFaces Builder
 Plugin. As far as I can tell the current trunk of Trinidad for JSF 1.2
 is also affected by this. Perhaps it would be a good idea if somebody
 of the Trinidad team takes a look at this before starting the release.

 Please refer to the following Tomahawk issue for details:

 https://issues.apache.org/jira/browse/TOMAHAWK-1560

 Kind regards

  Christian


 https://issues.apache.org/jira/browse/TOMAHAWK-1560
 2011/1/10, Matthias Wessendorf mat...@apache.org:
 Hi,

 I've created a Trinidad 1.2.14 release candidate, with the following
 artifacts
 up for a vote:

 SVN source tag (r1057250):
 http://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-1.2.14/

 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapachemyfaces-013/

 Source release:
 https://repository.apache.org/content/repositories/orgapachemyfaces-013/org/apache/myfaces/trinidad/trinidad/1.2.14/trinidad-1.2.14-source-release.zip

 Vote will be open for 72 hours.

 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)

 Thanks,
 Matthias

 --
 Matthias Wessendorf

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



 --
 Christian Kaltepoth
 Blog: http://chkal.blogspot.com/
 Twitter: http://twitter.com/chkal




 --
 Matthias Wessendorf

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




 --
 Matthias Wessendorf

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




 --
 Matthias Wessendorf

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




 --
 Matthias Wessendorf

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




 --
 Christian Kaltepoth
 Blog: http://chkal.blogspot.com/
 Twitter: http://twitter.com/chkal




 --
 Matthias Wessendorf

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

Re: [core] Improve error reporting and logging


++1

Werner


Am 10.01.11 20:06, schrieb Martin Koci:


Hi,

the most wanted feature which our coders want is more consistent and
human-readable error reporting and logging. Here is a example:

If user specifies f:ajax without eventName for a component without
defaultEventName, myfaces throw a execption:

Now (myfaces 2.0.3):
eventName could not be defined for f:ajax tag with no wrap mode.



Improved (example only; from my copy of myfaces):

MF0345: Your ajax tag does not specify eventName and component
com.foo.Bazz does not provide the default one. Please use one from
available: [change, blur, focus ...];

Tag location: XYZ.xhtml line 56 column 23,f:ajax  . /

Component: id: componentId,  class: com.foo.BazzInput, component type:
org.renderkit.Input

ViewId: YYZ.xhml, located in file system
as: /tmp/deploy/weabpp/XYZ.xhtml

PhaseId: RENDER_RESPONSE

Details: ... a detailed description of this problem + suggestions,
example of code.

References:
#  Click for problem MF0345 in MYFACES knowledge database (hypertext
link)
# Contact your technology team : m...@to.me
# If you think this a bug report it: jira.project.org






What do you think about this idea?

(I'll describe our requirements and what I found so far in next emails)


Regards,

Kočičák

timtable for myfaces 2.1

I am just asking because the spec is finalized and it is more or less a 
small extension to 2.0.

We should try not to fall too much behind mojarra here.

Werner

Re: timtable for myfaces 2.1

+1

(asked the question already on our TCK list :-) )

-M

On Tue, Jan 11, 2011 at 3:14 PM, Werner Punz werner.p...@gmail.com wrote:
 I am just asking because the spec is finalized and it is more or less a
 small extension to 2.0.
 We should try not to fall too much behind mojarra here.

 Werner





-- 
Matthias Wessendorf

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

Re: [core] Improve error reporting and logging

Btw. I did some work in this area for the client. We now have localized 
ajax error messages, for now only english and german, anyone willing to 
step in for other languages?


Werner


Am 11.01.11 14:00, schrieb Martin Marinschek:

I am always for better error reporting!

best regards,

Martin

On 1/10/11, Jakob Korherrjakob.korh...@gmail.com  wrote:

Hi Kocicak,

1

Regards,
Jakob

2011/1/10 Martin Kocimartin.kocicak.k...@gmail.com:


Hi,

the most wanted feature which our coders want is more consistent and
human-readable error reporting and logging. Here is a example:

If user specifies f:ajax without eventName for a component without
defaultEventName, myfaces throw a execption:

Now (myfaces 2.0.3):
eventName could not be defined for f:ajax tag with no wrap mode.



Improved (example only; from my copy of myfaces):

MF0345: Your ajax tag does not specify eventName and component
com.foo.Bazz does not provide the default one. Please use one from
available: [change, blur, focus ...];

Tag location: XYZ.xhtml line 56 column 23,f:ajax  . /

Component: id: componentId,  class: com.foo.BazzInput, component type:
org.renderkit.Input

ViewId: YYZ.xhml, located in file system
as: /tmp/deploy/weabpp/XYZ.xhtml

PhaseId: RENDER_RESPONSE

Details: ... a detailed description of this problem + suggestions,
example of code.

References:
#  Click for problem MF0345 in MYFACES knowledge database (hypertext
link)
# Contact your technology team : m...@to.me
# If you think this a bug report it: jira.project.org






What do you think about this idea?

(I'll describe our requirements and what I found so far in next emails)


Regards,

Kočičák






--
Jakob Korherr

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

[jira] Created: (TOBAGO-967) Remove the TobagoResourceBundle from the faces-config.xml

2011-01-11 Thread Udo Schnurpfeil (JIRA)

Remove the TobagoResourceBundle from the faces-config.xml
-

 Key: TOBAGO-967
 URL: https://issues.apache.org/jira/browse/TOBAGO-967
 Project: MyFaces Tobago
  Issue Type: Improvement
Reporter: Udo Schnurpfeil
Assignee: Udo Schnurpfeil


The disadvantage is, that this configuration value may be in conflict with 
other libraries that needs to set this value.
Solution: Search the bundles programatically (in MessageUtils)
1. look into the application bundle (from faces-config.xml)
2. look into the tobago bundle
3. look into the default from the jsf implementation

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

Re: timtable for myfaces 2.1

2011-01-11 Thread Leonardo Uribe

Hi

I would like to do another release of myfaces core 2.0.x (in this case to
2.0.4) before create a branch for 2.1. Most of the code we have on 2.0.x is
well tested, so I hope after that release changes required to share between
2.0.x and 2.1.x will be minimal.

Leonardo

2011/1/11 Matthias Wessendorf mat...@apache.org

 +1

 (asked the question already on our TCK list :-) )

 -M

 On Tue, Jan 11, 2011 at 3:14 PM, Werner Punz werner.p...@gmail.com
 wrote:
  I am just asking because the spec is finalized and it is more or less a
  small extension to 2.0.
  We should try not to fall too much behind mojarra here.
 
  Werner
 
 



 --
 Matthias Wessendorf

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

Re: timtable for myfaces 2.1

sounds good;

any major items we need to wait for 2.0.4 ? :)

On Tue, Jan 11, 2011 at 4:41 PM, Leonardo Uribe lu4...@gmail.com wrote:
 Hi

 I would like to do another release of myfaces core 2.0.x (in this case to
 2.0.4) before create a branch for 2.1. Most of the code we have on 2.0.x is
 well tested, so I hope after that release changes required to share between
 2.0.x and 2.1.x will be minimal.

 Leonardo

 2011/1/11 Matthias Wessendorf mat...@apache.org

 +1

 (asked the question already on our TCK list :-) )

 -M

 On Tue, Jan 11, 2011 at 3:14 PM, Werner Punz werner.p...@gmail.com
 wrote:
  I am just asking because the spec is finalized and it is more or less a
  small extension to 2.0.
  We should try not to fall too much behind mojarra here.
 
  Werner
 
 



 --
 Matthias Wessendorf

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





-- 
Matthias Wessendorf

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

Re: timtable for myfaces 2.1

2011-01-11 Thread Jakob Korherr

+1 on this plan, Leonardo!

There are some pending issues which I'd like to include in 2.0.4 (so
that they're automatically included in 2.1.x too). Most of them are
already in the JIRA, e.g. MYFACES-3003.

Regards,
Jakob

2011/1/11 Matthias Wessendorf mat...@apache.org:
 sounds good;

 any major items we need to wait for 2.0.4 ? :)

 On Tue, Jan 11, 2011 at 4:41 PM, Leonardo Uribe lu4...@gmail.com wrote:
 Hi

 I would like to do another release of myfaces core 2.0.x (in this case to
 2.0.4) before create a branch for 2.1. Most of the code we have on 2.0.x is
 well tested, so I hope after that release changes required to share between
 2.0.x and 2.1.x will be minimal.

 Leonardo

 2011/1/11 Matthias Wessendorf mat...@apache.org

 +1

 (asked the question already on our TCK list :-) )

 -M

 On Tue, Jan 11, 2011 at 3:14 PM, Werner Punz werner.p...@gmail.com
 wrote:
  I am just asking because the spec is finalized and it is more or less a
  small extension to 2.0.
  We should try not to fall too much behind mojarra here.
 
  Werner
 
 



 --
 Matthias Wessendorf

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





 --
 Matthias Wessendorf

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




-- 
Jakob Korherr

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

Re: timtable for myfaces 2.1

2011-01-11 Thread Gerhard

+1

regards,
gerhard

http://www.irian.at

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

Professional Support for Apache MyFaces



2011/1/11 Jakob Korherr jakob.korh...@gmail.com

 +1 on this plan, Leonardo!

 There are some pending issues which I'd like to include in 2.0.4 (so
 that they're automatically included in 2.1.x too). Most of them are
 already in the JIRA, e.g. MYFACES-3003.

 Regards,
 Jakob

 2011/1/11 Matthias Wessendorf mat...@apache.org:
  sounds good;
 
  any major items we need to wait for 2.0.4 ? :)
 
  On Tue, Jan 11, 2011 at 4:41 PM, Leonardo Uribe lu4...@gmail.com
 wrote:
  Hi
 
  I would like to do another release of myfaces core 2.0.x (in this case
 to
  2.0.4) before create a branch for 2.1. Most of the code we have on 2.0.x
 is
  well tested, so I hope after that release changes required to share
 between
  2.0.x and 2.1.x will be minimal.
 
  Leonardo
 
  2011/1/11 Matthias Wessendorf mat...@apache.org
 
  +1
 
  (asked the question already on our TCK list :-) )
 
  -M
 
  On Tue, Jan 11, 2011 at 3:14 PM, Werner Punz werner.p...@gmail.com
  wrote:
   I am just asking because the spec is finalized and it is more or less
 a
   small extension to 2.0.
   We should try not to fall too much behind mojarra here.
  
   Werner
  
  
 
 
 
  --
  Matthias Wessendorf
 
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  twitter: http://twitter.com/mwessendorf
 
 
 
 
 
  --
  Matthias Wessendorf
 
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  twitter: http://twitter.com/mwessendorf
 



 --
 Jakob Korherr

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

Re: [VOTE] Release MyFaces Portlet Bridge 2.0.0

2011-01-11 Thread Michael Freedman


The staging repository has now been closed.  Please vote soon.
 -Mike-

On 1/7/2011 2:40 PM, Jakob Korherr wrote:

Hi,

The related staging repo (orgapachemyfaces-069) is not closed, but it
should be for a vote, because otherwise the contents can still change.
Furthermore when closing the repo it will automatically be checked
against obvious flaws (like wrong checksums).

Please close the repo so that we can do a proper vote. Thanks!

Regards,
Jakob

2011/1/5 Michael Freedmanmichael.freed...@oracle.com:

Please vote on the proposed release of MyFaces Portlet Bridge 2.0.0.  This
is the final version of the JSR 329 RI and corresponds to  Portlet 2.0
Bridge for JavaServer Faces 1.2 specification which was finalized/approved
by the JCP last month.

Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/2.0.0

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-069/


I have verified that the distributable jars run and pass the JSR 329 TCK.
  In addition I have verified that the distributable examples run (on apache
tomcat/pluto).


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

Re: [VOTE] Release MyFaces Portlet Bridge 2.0.0

2011-01-11 Thread Michael Freedman


+1.
   -Mike-

On 1/5/2011 12:53 PM, Michael Freedman wrote:
Please vote on the proposed release of MyFaces Portlet Bridge 2.0.0.  
This is the final version of the JSR 329 RI and corresponds to  
Portlet 2.0 Bridge for JavaServer Faces 1.2 specification which was 
finalized/approved by the JCP last month.


Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/2.0.0

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-069/


I have verified that the distributable jars run and pass the JSR 329 
TCK.  In addition I have verified that the distributable examples run 
(on apache tomcat/pluto).



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

[jira] Updated: (TRINIDAD-2002) TrinidadFilterImpl FacesContext initialization

2011-01-11 Thread Max Starets (JIRA)

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

Max Starets updated TRINIDAD-2002:
--

Resolution: Fixed
Fix Version/s: 2.0.0.3-core
Status: Resolved (was: Patch Available)

patch committed.

TrinidadFilterImpl FacesContext initialization
--

Key: TRINIDAD-2002
URL: https://issues.apache.org/jira/browse/TRINIDAD-2002
Project: MyFaces Trinidad
Issue Type: Improvement
Affects Versions: 2.0.0-alpha
Reporter: Andy Schwartz
Priority: Minor
Fix For: 2.0.0.3-core

Attachments: TRINIDAD-2002.patch

ADF Faces hooks into Trinidad's TrinidadFilterImpl sub-filter service and
uses this to perform early configuration/initialization work. In particular,
we use the ApplicationFactory to get at the Application instance and then
create/add converters to the Application.
This works fine on Mojarra 2.0.x releases.
However, this fails in both:
- MyFaces 2.0.x
- Mojarra 2.1.x
In both cases, the reason for the failure is that access to the FacesContext
is required but is not yet available. In MyFaces 2.0.x, the
FacesContext/ExternalContext is required by
Application.createConverter()/setConverterProperties() in order to determine
the value of the
javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE context
parameter. In Mojarra 2.1.x, the ApplicationFactory requires access to the
FacesContext in order to create the Application instance.
While we can work around this issue at the ADF Faces level,
TrinidadFilterImpl is already well positioned to address this - ie.
TrinidadFilterImpl has access to the PseudoFacesContext and already sets
this up for other cases (eg. for Configurator.beginRequest()).
I am logging this issue to request that we take advantage of the existing
support that TrinidadFilterImpl/PseudoFacesContext provides for early
FacesContext access and extend this to TrinidadFilterImpl.init().

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

[jira] Commented: (MYFACES-3011) conversion of enum fails


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

Leonardo Uribe commented on MYFACES-3011:
-

I have checked the provided file and the syntax is invalid. The converterId for 
javax.faces.convert.EnumConverter is javax.faces.Enum, but in this case we need 
to set converter targetClass property.

One alternative is use a binding like this:

h:selectOneMenu value=#{enumBean.selection} 
converter=#{enumBean.categoryConverter}
   f:selectItems value=#{enumBean.categories}/
/h:selectOneMenu

and on the bean (Category is the enum):

public enum Category {
  ..
}

public Converter getCategoryConverter()
{
if (categoryConverter == null)
{
categoryConverter = new EnumConverter(Category.class);
}
return categoryConverter;
}

the #{enumBean.categories} expression is bound using this code in the bean:

public Category[] getCategories()
{
return Category.class.getEnumConstants();
}

There is an error on MYFACES-2920 to be solved soon related, but this report is 
not valid, so I have to close it as invalid.

 conversion of enum fails
 

 Key: MYFACES-3011
 URL: https://issues.apache.org/jira/browse/MYFACES-3011
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.0.3
 Environment: Google AppEngine, el-impl-1.1.jar
Reporter: Axel Krebs
 Attachments: sa_detail.xhtml


 SEVERE: An exception occurred
 javax.faces.FacesException: java.lang.IllegalArgumentException: Cannot 
 convert javax.faces.component.html.htmlselectonem...@84b8f9 of type class 
 javax.faces.component.html.HtmlSelectOneMenu to class 
 de.akrebs.shop.domain.Category
   at 
 org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241)
   at 
 org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156)
   at 
 org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:258)
   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 
 com.google.appengine.api.blobstore.dev.ServeBlobFilter.doFilter(ServeBlobFilter.java:58)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
   at 
 com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
   at 
 com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:122)
   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 
 com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:70)
   at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
   at 
 com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.handle(JettyContainerService.java:349)
   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:542)
   at 
 org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:938)
   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:755)
   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
   at 
 org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
   at 
 org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
 Caused by: java.lang.IllegalArgumentException: Cannot convert 
 javax.faces.component.html.htmlselectonem...@84b8f9 of type class 
 javax.faces.component.html.HtmlSelectOneMenu to class 
 de.akrebs.shop.domain.Category
   at com.sun.el.lang.ELSupport.coerceToEnum(ELSupport.java:196)
   at com.sun.el.lang.ELSupport.coerceToType(ELSupport.java:363)
   at

Re: [VOTE] Release MyFaces Portlet Bridge 2.0.0


+1

Werner

Am 11.01.11 17:44, schrieb Michael Freedman:

+1.
-Mike-

On 1/5/2011 12:53 PM, Michael Freedman wrote:

Please vote on the proposed release of MyFaces Portlet Bridge 2.0.0.
This is the final version of the JSR 329 RI and corresponds to Portlet
2.0 Bridge for JavaServer Faces 1.2 specification which was
finalized/approved by the JCP last month.

Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/2.0.0

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-069/


I have verified that the distributable jars run and pass the JSR 329
TCK. In addition I have verified that the distributable examples run
(on apache tomcat/pluto).


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

[jira] Created: (MYFACES-3014) Czech and Slovak localization

2011-01-11 Thread JIRA

Czech and Slovak localization
-

 Key: MYFACES-3014
 URL: https://issues.apache.org/jira/browse/MYFACES-3014
 Project: MyFaces Core
  Issue Type: Improvement
  Components: General
Reporter: Martin Kočí
Priority: Minor


Provide Czech and Slovak localization for MyFaces.

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

[jira] Commented: (MYFACES-3010) 2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType


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

Leonardo Uribe commented on MYFACES-3010:
-

I checked the source code of the example and after some tests here is the 
problem:

public enum ContactType {
PERSONAL {
 
   @Override
   public String toString() {
 
 return Personal;
   }
},
 
BUSINESS {
 
   @Override
   public String toString() {
 
 return Business;
   }
}
}

that syntax is correct, but it has a side effect. In this case the base class 
of PERSONAL and BUSINESS is not ContactType, is ContactType$1 or ContactType$2. 

If the enumeration is written like this:

public enum ContactType {
PERSONAL, BUSINESS
}

the base class for PERSONAL and BUSINESS is ContactType, and when it is called 
class.isEnum(), it returns true, but with ContactType$1 that is not true, 
because the class marked as enumeration is ContactType.

I tried a variant of the example with Mojarra 2.0.3 and it does not show the 
error message (supporting the argumentation about swallow the exception), but 
it says later that the value is not valid, because it cannot coerce the string 
and the comparison fails (the value does not belongs to the valid list values).

I'll commit a solution on MYFACES-2920 soon

 2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType
 -

 Key: MYFACES-3010
 URL: https://issues.apache.org/jira/browse/MYFACES-3010
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.0.3
Reporter: Kennard Consulting
Priority: Critical
 Attachments: addressbook-faces2.zip


 Hi guys,
 Thanks again for the great work you do on MyFaces and your fantastic JIRA 
 response times!
 I attach a small app that comes from the Metawidget (http://metawidget.org) 
 distribution. I had you do MYFACES-2935 for me for MyFaces 2.0.3, and my app 
 was working great with the 2.0.3-impl-SNAPSHOT.jar and the 2.0.2-api.jar. 
 However now that 2.0.3 is out for real I have tried to upgrade my app, and it 
 fails. To reproduce, please:
 1. Unzip the attached app and deploy as an exploded WAR into Tomcat
 2. Run Tomcat and hit http://localhost:8080/addressbook-faces2
 3. In the Type dropdown, choose 'Business' and click Search
 You will see an IllegalArgumentException. Now:
 4. Stop Tomcat
 5. Inside the exploded WAR, rename myfaces-api-2.0.2.rename.me to 
 myfaces-api-2.0.2.jar (and delete/rename myfaces-api-2.0.3.jar)
 6. Restart Tomcat and repeat steps 1-3
 This time you will see no such error.
 So something appears to have broken between myfaces-api-2.0.2.jar and 
 myfaces-api-2.0.3.jar? Hopefully you can reproduce this and it is enough for 
 you to debug the issue. The source code for the small app can be viewed here:
 http://metawidget.svn.sourceforge.net/viewvc/metawidget/trunk/examples/src/java/org/metawidget/example/faces/addressbook/
 http://metawidget.svn.sourceforge.net/viewvc/metawidget/trunk/examples/src/java/org/metawidget/example/shared/addressbook/
 Of course, this could well be a case of 2.0.3 being stricter about something 
 and therefore exposing a bug in my code. But my code worked in 2.0.2, JSF 1.2 
 and JSF 1.1, so hopefully not!
 Regards,
 Richard

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

[jira] Resolved: (MYFACES-2920) UISelectOne/UISelectMany validateValue: Before comparing each option, coerce the option value type to the type of component's value


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

Leonardo Uribe resolved MYFACES-2920.
-

Resolution: Fixed

I did some changes on the tests provided and set myfaces-test version to 
1.0.1-SNAPSHOT. I did other tests using the test-webapp, to check if everything 
is correct. An explanation for this issue is on MYFACES-3010, but I commit the 
changes here to allow follow them easily using subversion commits tab.

 UISelectOne/UISelectMany validateValue: Before comparing each option, coerce 
 the option value type to the type of component's value
 ---

 Key: MYFACES-2920
 URL: https://issues.apache.org/jira/browse/MYFACES-2920
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.2-SNAPSHOT
 Environment: myfaces trunk
Reporter: Martin Kočí
Assignee: Leonardo Uribe
 Fix For: 2.0.3

 Attachments: MYFACES-2920-v2.patch, MYFACES-2920.patch

   Original Estimate: 0h
  Remaining Estimate: 0h

 From JavaDoc UISelectOne/UISelectMany validateValue:
  ... Before comparing each option, coerce the option value type to the type 
 of this component's value following the Expression Language coercion rules 
 ...
 More here:
 http://markmail.org/message/mfhyyiogaz73yfr4

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

[jira] Resolved: (MYFACES-3010) 2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType

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

Leonardo Uribe resolved MYFACES-3010.
-

Resolution: Fixed
Assignee: Leonardo Uribe

Thanks to Imre Osswald for your consideration with convertToType method.

2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType
-

Key: MYFACES-3010
URL: https://issues.apache.org/jira/browse/MYFACES-3010
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.3
Reporter: Kennard Consulting
Assignee: Leonardo Uribe
Priority: Critical
Attachments: addressbook-faces2.zip

Hi guys,
Thanks again for the great work you do on MyFaces and your fantastic JIRA
response times!
I attach a small app that comes from the Metawidget (http://metawidget.org)
distribution. I had you do MYFACES-2935 for me for MyFaces 2.0.3, and my app
was working great with the 2.0.3-impl-SNAPSHOT.jar and the 2.0.2-api.jar.
However now that 2.0.3 is out for real I have tried to upgrade my app, and it
fails. To reproduce, please:
1. Unzip the attached app and deploy as an exploded WAR into Tomcat
2. Run Tomcat and hit http://localhost:8080/addressbook-faces2
3. In the Type dropdown, choose 'Business' and click Search
You will see an IllegalArgumentException. Now:
4. Stop Tomcat
5. Inside the exploded WAR, rename myfaces-api-2.0.2.rename.me to
myfaces-api-2.0.2.jar (and delete/rename myfaces-api-2.0.3.jar)
6. Restart Tomcat and repeat steps 1-3
This time you will see no such error.
So something appears to have broken between myfaces-api-2.0.2.jar and
myfaces-api-2.0.3.jar? Hopefully you can reproduce this and it is enough for
you to debug the issue. The source code for the small app can be viewed here:
http://metawidget.svn.sourceforge.net/viewvc/metawidget/trunk/examples/src/java/org/metawidget/example/faces/addressbook/
http://metawidget.svn.sourceforge.net/viewvc/metawidget/trunk/examples/src/java/org/metawidget/example/shared/addressbook/
Of course, this could well be a case of 2.0.3 being stricter about something
and therefore exposing a bug in my code. But my code worked in 2.0.2, JSF 1.2
and JSF 1.1, so hopefully not!
Regards,
Richard

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

Re: [core] Improve error reporting and logging

2011-01-11 Thread Martin Koci

Hi, 

I will do it for Czech and Slovak: MYFACES-3014. Not very frequent
languages, though - but 10 491 492 (CZ) + approx 5 mil (SK) inhabitants
(samt Kindern und Rentnern) of Czech + Slovak Republic will appreciate
it :)  


Werner Punz píše v Út 11. 01. 2011 v 15:13 +0100:
 Btw. I did some work in this area for the client. We now have localized 
 ajax error messages, for now only english and german, anyone willing to 
 step in for other languages?
 
 Werner
 
 
 Am 11.01.11 14:00, schrieb Martin Marinschek:
  I am always for better error reporting!
 
  best regards,
 
  Martin
 
  On 1/10/11, Jakob Korherrjakob.korh...@gmail.com  wrote:
  Hi Kocicak,
 
  1
 
  Regards,
  Jakob
 
  2011/1/10 Martin Kocimartin.kocicak.k...@gmail.com:
 
  Hi,
 
  the most wanted feature which our coders want is more consistent and
  human-readable error reporting and logging. Here is a example:
 
  If user specifies f:ajax without eventName for a component without
  defaultEventName, myfaces throw a execption:
 
  Now (myfaces 2.0.3):
  eventName could not be defined for f:ajax tag with no wrap mode.
 
 
 
  Improved (example only; from my copy of myfaces):
 
  MF0345: Your ajax tag does not specify eventName and component
  com.foo.Bazz does not provide the default one. Please use one from
  available: [change, blur, focus ...];
 
  Tag location: XYZ.xhtml line 56 column 23,f:ajax  . /
 
  Component: id: componentId,  class: com.foo.BazzInput, component type:
  org.renderkit.Input
 
  ViewId: YYZ.xhml, located in file system
  as: /tmp/deploy/weabpp/XYZ.xhtml
 
  PhaseId: RENDER_RESPONSE
 
  Details: ... a detailed description of this problem + suggestions,
  example of code.
 
  References:
  #  Click for problem MF0345 in MYFACES knowledge database (hypertext
  link)
  # Contact your technology team : m...@to.me
  # If you think this a bug report it: jira.project.org
 
 
 
 
 
 
  What do you think about this idea?
 
  (I'll describe our requirements and what I found so far in next emails)
 
 
  Regards,
 
  Kočičák
 
 
 
 
 
  --
  Jakob Korherr
 
  blog: http://www.jakobk.com
  twitter: http://twitter.com/jakobkorherr
  work: http://www.irian.at

[jira] Resolved: (MYFACES-3013) ExternalContext: setRequest(...) method does not reset cached request maps


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

Leonardo Uribe resolved MYFACES-3013.
-

   Resolution: Fixed
Fix Version/s: 2.0.4-SNAPSHOT
 Assignee: Leonardo Uribe

Yes, if someone call setRequest, the new object should be used and all wrappers 
should be recreated (coincidentially assign null will do the trick). Thanks to 
Nick Belaevski for note this issue.

 ExternalContext: setRequest(...) method does not reset cached request maps 
 ---

 Key: MYFACES-3013
 URL: https://issues.apache.org/jira/browse/MYFACES-3013
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.0.3
Reporter: Nick Belaevski
Assignee: Leonardo Uribe
 Fix For: 2.0.4-SNAPSHOT


 When 
 org.apache.myfaces.context.servlet.ServletExternalContextImpl.setRequest(Object)
  is called, cached request maps (e.g. _requestHeaderMap) are not reset, so 
 data from new request is not used.
 Here is what Mojarra does: 
 public void setRequest(Object request) {
 if (request instanceof ServletRequest) {
 this.request = (ServletRequest) request;
 requestHeaderMap = null;
 requestHeaderValuesMap = null;
 requestHeaderValuesMap = null;
 requestMap = null;
 requestParameterMap = null;
 requestParameterValuesMap = null;
 }
 }

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

[jira] Created: (MYFACES-3015) CLONE -ExternalContext: setRequest(...) method does not reset cached request maps (1.2 branch)

CLONE -ExternalContext: setRequest(...) method does not reset cached request 
maps (1.2 branch)
--

 Key: MYFACES-3015
 URL: https://issues.apache.org/jira/browse/MYFACES-3015
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.0.3
Reporter: Nick Belaevski
Assignee: Leonardo Uribe
 Fix For: 2.0.4-SNAPSHOT


When 
org.apache.myfaces.context.servlet.ServletExternalContextImpl.setRequest(Object)
 is called, cached request maps (e.g. _requestHeaderMap) are not reset, so data 
from new request is not used.

Here is what Mojarra does: 


public void setRequest(Object request) {
if (request instanceof ServletRequest) {
this.request = (ServletRequest) request;
requestHeaderMap = null;
requestHeaderValuesMap = null;
requestHeaderValuesMap = null;
requestMap = null;
requestParameterMap = null;
requestParameterValuesMap = null;
}
}


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

[jira] Resolved: (MYFACES-3015) CLONE -ExternalContext: setRequest(...) method does not reset cached request maps (1.2 branch)


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

Leonardo Uribe resolved MYFACES-3015.
-

Resolution: Fixed

 CLONE -ExternalContext: setRequest(...) method does not reset cached request 
 maps (1.2 branch)
 --

 Key: MYFACES-3015
 URL: https://issues.apache.org/jira/browse/MYFACES-3015
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.2.9
Reporter: Nick Belaevski
Assignee: Leonardo Uribe
 Fix For: 1.2.10


 When 
 org.apache.myfaces.context.servlet.ServletExternalContextImpl.setRequest(Object)
  is called, cached request maps (e.g. _requestHeaderMap) are not reset, so 
 data from new request is not used.
 Here is what Mojarra does: 
 public void setRequest(Object request) {
 if (request instanceof ServletRequest) {
 this.request = (ServletRequest) request;
 requestHeaderMap = null;
 requestHeaderValuesMap = null;
 requestHeaderValuesMap = null;
 requestMap = null;
 requestParameterMap = null;
 requestParameterValuesMap = null;
 }
 }

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

Re: [core] Improve error reporting and logging

Hi Martin thanks a lot it is not too much work we don´t have too many 
entries for now, the current language files are bundled in

.. /core/api/src/main/javascript/META-INF/resources/myfaces/_impl/i18n
You will get the idea on how to enable everything as soon as you have a 
look at the code, but however:
the i18n is implemented as a javascript class which overrides the 
default english settings (that way i have an easy fallback in case of a 
missing key). Here is the example for german


myfaces._impl.core._Runtime.extendClass(myfaces._impl.i18n.Messages_de, myfaces._impl.i18n.Messages, 
{

//_Lang.js
ERR_MUST_STRING:{0}: {1} namespace muss vom Typ String sein,
ERR_REF_OR_ID:  {0}: {1} Ein Referenzknoten oder id muss 
übergeben werden,

ERR_PARAM_GENERIC:  {0}: Paramter {1} muss vom Typ {2} sein,
ERR_PARAM_STR:  {0}: Parameter {1} muss vom Typ String sein
});


So the entries simply are a javascript map and the inheritance is used 
for easy fallback. Simple but effective.


For the naming you can use the standard iso codes for language and variants:
For instance

myfaces._impl.i18n.Messages_de for standard german
and
myfaces._impl.i18n.Messages_de_AT for german austrian variant.
The javascript system tries to detect the correct language and then 
picks up the correctly registered class for the language and variant.
But for the variant derive the class from the core language file and 
override only the entries you want to set new


so it makes sense to derive myfaces._impl.i18n.Messages_de from english 
for uncovered key entries and
then myfaces._impl.i18n.Messages_de_AT from the core german 
myfaces._impl.i18n.Messages_de


Sounds more complicated than in reality it is.

Feel free to ask questions if you have them.


Werner




Am 11.01.11 20:27, schrieb Martin Koci:

Hi,

I will do it for Czech and Slovak: MYFACES-3014. Not very frequent
languages, though - but 10 491 492 (CZ) + approx 5 mil (SK) inhabitants
(samt Kindern und Rentnern) of Czech + Slovak Republic will appreciate
it :)


Werner Punz píše v Út 11. 01. 2011 v 15:13 +0100:

Btw. I did some work in this area for the client. We now have localized
ajax error messages, for now only english and german, anyone willing to
step in for other languages?

Werner


Am 11.01.11 14:00, schrieb Martin Marinschek:

I am always for better error reporting!

best regards,

Martin

On 1/10/11, Jakob Korherrjakob.korh...@gmail.com   wrote:

Hi Kocicak,

1

Regards,
Jakob

2011/1/10 Martin Kocimartin.kocicak.k...@gmail.com:


Hi,

the most wanted feature which our coders want is more consistent and
human-readable error reporting and logging. Here is a example:

If user specifies f:ajax without eventName for a component without
defaultEventName, myfaces throw a execption:

Now (myfaces 2.0.3):
eventName could not be defined for f:ajax tag with no wrap mode.



Improved (example only; from my copy of myfaces):

MF0345: Your ajax tag does not specify eventName and component
com.foo.Bazz does not provide the default one. Please use one from
available: [change, blur, focus ...];

Tag location: XYZ.xhtml line 56 column 23,f:ajax  . /

Component: id: componentId,  class: com.foo.BazzInput, component type:
org.renderkit.Input

ViewId: YYZ.xhml, located in file system
as: /tmp/deploy/weabpp/XYZ.xhtml

PhaseId: RENDER_RESPONSE

Details: ... a detailed description of this problem + suggestions,
example of code.

References:
#  Click for problem MF0345 in MYFACES knowledge database (hypertext
link)
# Contact your technology team : m...@to.me
# If you think this a bug report it: jira.project.org






What do you think about this idea?

(I'll describe our requirements and what I found so far in next emails)


Regards,

Kočičák






--
Jakob Korherr

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

[jira] Commented: (MYFACES-3010) 2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType

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

Kennard Consulting commented on MYFACES-3010:
-

Leronardo,

Thanks for all your time on this.

I am a little concerned because the alternate syntax you propose is not
functionally equivalent to the original syntax. Overriding the toString of an
enum is legitimate, as is adding new methods to the enum if the developer
chooses. I agree this has the effect of creating an anonymous inner class that
is not .isEnum(), but previous versions of MyFaces have always supported this
use case?

For example, the test webapp works fine with 2.0.2-api.jar?

Richard.

2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType
-

Attachments: addressbook-faces2.zip

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

[jira] Issue Comment Edited: (MYFACES-3010) 2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType

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

Kennard Consulting edited comment on MYFACES-3010 at 1/11/11 2:51 PM:
--

Leronardo,

Thanks for all your time on this.

I am a little concerned because the alternate syntax you propose is *not*
functionally equivalent to the original syntax. Overriding the toString of an
enum is legitimate, as is adding new methods to the enum if the developer
chooses. I agree this has the effect of creating an anonymous inner class that
is not .isEnum(), but previous versions of MyFaces have always supported this?

For example, the test webapp works fine with 2.0.2-api.jar? And MyFaces 1.x and
Mojarra have always worked fine too.

Richard.

was (Author: kennardconsulting):
Leronardo,

Thanks for all your time on this.

For example, the test webapp works fine with 2.0.2-api.jar?

Richard.

2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType
-

Attachments: addressbook-faces2.zip

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

[jira] Commented: (MYFACES-3010) 2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType

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

Leonardo Uribe commented on MYFACES-3010:
-

Hi Richard

Yes, I know. The committed code takes into account both syntax, so the latest
code in trunk should work like with 2.0.2

Leonardo

2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType
-

Attachments: addressbook-faces2.zip

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

[jira] Issue Comment Edited: (MYFACES-3010) 2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType

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

Kennard Consulting edited comment on MYFACES-3010 at 1/11/11 2:59 PM:
--

Leronardo,

Thanks for all your time on this.

I am a little concerned because the alternate syntax you propose...

public enum ContactType {
PERSONAL, BUSINESS
}

...is *not* functionally equivalent to the original syntax. Overriding the
toString of an enum is legitimate, as is adding new methods to the enum if the
developer chooses. I agree this has the effect of creating an anonymous inner
class that is not .isEnum(), but previous versions of MyFaces have always
supported this?

For example, the test webapp works fine with 2.0.2-api.jar? And MyFaces 1.x and
Mojarra have always worked fine too.

Richard.

was (Author: kennardconsulting):
Leronardo,

Thanks for all your time on this.

For example, the test webapp works fine with 2.0.2-api.jar? And MyFaces 1.x and
Mojarra have always worked fine too.

Richard.

2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType
-

Attachments: addressbook-faces2.zip

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

[jira] Commented: (MYFACES-3002) FaceletComponsitionContextImpl drops viewParams

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

Leonardo Uribe commented on MYFACES-3002:
-

Ok, so we can close this issue. f:metadata should be on the topmost layer as
says the facelets tld javadoc of f:metadata :

Declare the metadata facet for this view. This must be a child of the
f:view. This tag must reside within the top level XHTML file for the given
viewId, or in a template client, but not in a template

Right now if the component parent passed to f:metadata is not UIViewRoot, an
exception is thrown, but this condition is only checked when viewMetadata is
being built. I think we just check that condition always is enough. I'll close
this issue as fixed.

FaceletComponsitionContextImpl drops viewParams
---

Key: MYFACES-3002
URL: https://issues.apache.org/jira/browse/MYFACES-3002
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.2, 2.0.3
Reporter: Mark Struberg
Assignee: Jakob Korherr
Priority: Critical

This is related to MYFACES-2774
FaceletComponsitionContextImpl#finalizeForDeletion drops the
'javax_faces_metadata' from the UIViewRoot s _facetMap. Thus all 'old'
viewParams are not available for propagation to the next view anymore.
This situation happens if an action returns something like
return nextPage.xhtml??faces-redirect=trueincludeViewParams=true;

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

[jira] Resolved: (MYFACES-3002) FaceletComponsitionContextImpl drops viewParams


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

Leonardo Uribe resolved MYFACES-3002.
-

   Resolution: Fixed
Fix Version/s: 2.0.4-SNAPSHOT
 Assignee: Leonardo Uribe  (was: Jakob Korherr)

 FaceletComponsitionContextImpl drops viewParams
 ---

 Key: MYFACES-3002
 URL: https://issues.apache.org/jira/browse/MYFACES-3002
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.2, 2.0.3
Reporter: Mark Struberg
Assignee: Leonardo Uribe
Priority: Critical
 Fix For: 2.0.4-SNAPSHOT


 This is related to MYFACES-2774
 FaceletComponsitionContextImpl#finalizeForDeletion drops the 
 'javax_faces_metadata' from the UIViewRoot s _facetMap. Thus all 'old' 
 viewParams are not available for propagation to the next view anymore.
 This situation happens if an action returns something like
  return nextPage.xhtml??faces-redirect=trueincludeViewParams=true;

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

Re: [core] Improve error reporting and logging

2011-01-11 Thread Martin Koci

Here are some requirements and additional description:

-- identify every error with unique code:

If error begins with unique prefix like MF or MYFACES, coder can at
first sight recognize framework which is the source of that
error/exception. For example Oracle DB throws ORA- or our company stuff
throws AR- prefixed codes.
Number after that prefix is unique identification of problem. Whole
construct can serve as key for query (for bugzilla, WIKi, ...) or as
simple abbreviation of the problem. Our programmers often say 999
happens instead of Unexpected failure of data happens :)

-- text after error code:

Should not only describe what is wrong but also how to solve it.


-- details section:

This section can contain detailed description of problem. It can have
example of f:ajax eventName= /, hyperlink to javaDoc or VDL docs, or
a notice that IDEs mostly don't auto-complete this attribute.
In can look like overkill but those informations are required over and
over again. Especially if I hear the same question like what is
eventName and give me an example again  (grrr)
Of course all information can be found elsewhere but to ease
development, every framework should be self-explanatory
This section can by also collapsable as is the part for component tree
already.

-- localization:

all human-readable text should be localizable because coders always read
and think faster in their mother language.


-- references section:

links to bugzilla, mail etc. Should be configurable, for example I want
provide link from error page to our internal bugzilla, not to myfaces
JIRA. Similar case for email address.


-- information about location of problem:

If Facelets VDL is used it is obvious to provide tag, column and line.
But we cannot limit it for facelets only. For example we have one
project that uses pure Java API for View creation and very complex
logic. Then if UIComponent.setId() throws new
IllegalArgumentException(component identifier must not be a zero-length
String), is very hard to find the cause, if debugging is not available.
Here we can provide information about parent and path to component,
phase id etc. 


Kočičák

Werner Punz píše v Út 11. 01. 2011 v 15:12 +0100:
 ++1
 
 Werner
 
 
 Am 10.01.11 20:06, schrieb Martin Koci:
 
  Hi,
 
  the most wanted feature which our coders want is more consistent and
  human-readable error reporting and logging. Here is a example:
 
  If user specifies f:ajax without eventName for a component without
  defaultEventName, myfaces throw a execption:
 
  Now (myfaces 2.0.3):
  eventName could not be defined for f:ajax tag with no wrap mode.
 
 
 
  Improved (example only; from my copy of myfaces):
 
  MF0345: Your ajax tag does not specify eventName and component
  com.foo.Bazz does not provide the default one. Please use one from
  available: [change, blur, focus ...];
 
  Tag location: XYZ.xhtml line 56 column 23,f:ajax  . /
 
  Component: id: componentId,  class: com.foo.BazzInput, component type:
  org.renderkit.Input
 
  ViewId: YYZ.xhml, located in file system
  as: /tmp/deploy/weabpp/XYZ.xhtml
 
  PhaseId: RENDER_RESPONSE
 
  Details: ... a detailed description of this problem + suggestions,
  example of code.
 
  References:
  #  Click for problem MF0345 in MYFACES knowledge database (hypertext
  link)
  # Contact your technology team : m...@to.me
  # If you think this a bug report it: jira.project.org
 
 
 
 
 
 
  What do you think about this idea?
 
  (I'll describe our requirements and what I found so far in next emails)
 
 
  Regards,
 
  Kočičák

[jira] Resolved: (MYFACES-3004) prerenderView system event callback only triggered in certain cases


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

Leonardo Uribe resolved MYFACES-3004.
-

   Resolution: Fixed
Fix Version/s: 2.0.4-SNAPSHOT
 Assignee: Leonardo Uribe

 prerenderView system event callback only triggered in certain cases
 ---

 Key: MYFACES-3004
 URL: https://issues.apache.org/jira/browse/MYFACES-3004
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 2.0.2, 2.0.3
 Environment: all, server
Reporter: Werner Punz
Assignee: Leonardo Uribe
 Fix For: 2.0.4-SNAPSHOT


 Following scenario, two pages with implicit navigation. A prerender view 
 system event handler set over 
   h:head
 titleFacelet Title/title
 f:metadata
 f:event listener=#{pageHandler.prerender} type=preRenderView 
 /
 /f:metadata
 /h:head
 Now the prerender event is called:
 a) if I go via http get into the page
 b) If I execute actions which stay on the page
 The event handler however is not called
 if I navigate into the page via an implicit (maybe also explicit) navigation 
 case.
 A quick test revealed that the event handler is called in three cases in 
 mojarra and I assume our behavior is faulty
 and the behavior from mojarra is the one compliant to the spec.
 I am setting the priority to major because the prerenderview event is very 
 important in certain app classes which use callbacks to this event
 to deal with auto display mechanisms and with data loading in certain app 
 states.
 Here is the complete example:
 page1:
 ?xml version='1.0' encoding='UTF-8' ?
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN 
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html xmlns=http://www.w3.org/1999/xhtml;
   xmlns:h=http://java.sun.com/jsf/html;
   xmlns:f=http://java.sun.com/jsf/core;
 h:head
 titleFacelet Title/title
 f:metadata
 f:event listener=#{pageHandler.prerender} type=preRenderView 
 /
 /f:metadata
 /h:head
 h:body
 h:form
 Hello from Facelets
 h:commandLink action=page2 value=page2/
 /h:form
 /h:body
 /html
 page2:
 ?xml version='1.0' encoding='UTF-8' ?
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN 
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html xmlns=http://www.w3.org/1999/xhtml;
   xmlns:h=http://java.sun.com/jsf/html;
 h:head
 titleFacelet Title/title
 /h:head
 h:body
 h:form
 Hello from Facelets
 h:commandLink action=page1 value=go to page 1 /
 /h:form
 /h:body
 /html
 and the corresponding bean:
 @ManagedBean
 @RequestScoped
 public class PageHandler {
 public void prerender() {
 System.out.println(Prerender View);
 }
 }

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

[jira] Updated: (TRINIDAD-1993) Setting tr:validateByteLength maximum property as an EL expression results in an error

2011-01-11 Thread Gabrielle Crawford (JIRA)


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

Gabrielle Crawford updated TRINIDAD-1993:
-

   Resolution: Fixed
Fix Version/s: 2.0.0.4-core 
   Status: Resolved  (was: Patch Available)

 Setting tr:validateByteLength maximum property as an EL expression results in 
 an error
 --

 Key: TRINIDAD-1993
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1993
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0.3-core
 Environment: Linux x86
Reporter: Kentaro Kinebuchi
 Fix For: 2.0.0.4-core 

 Attachments: bug10432287.patch


 The stack trace is given below. The error is happening because the maximum 
 property in org.apache.myfaces.trinidad.validator.ByteLengthValidator does 
 not follow convention and is called maximumBytes instead of maximum. This 
 is also causing issues with af:validateByteLength.
 java.lang.IllegalArgumentException: Invalid attribute name maximum
   at 
 org.apache.myfaces.trinidad.validator.ValidatorUtils._getPropertyKey(ValidatorUtils.java:116)
   at 
 org.apache.myfaces.trinidad.validator.ValidatorUtils.setValueExpression(ValidatorUtils.java:80)
   at 
 org.apache.myfaces.trinidad.validator.ByteLengthValidator.setValueExpression(ByteLengthValidator.java:288)
   at 
 org.apache.myfaces.trinidadinternal.taglib.validator.ValidateByteLengthTag._setProperties(ValidateByteLengthTag.java:82)
   at 
 org.apache.myfaces.trinidadinternal.taglib.validator.ValidateByteLengthTag.createValidator(ValidateByteLengthTag.java:71)
   at 
 org.apache.myfaces.trinidad.webapp.TrinidadValidatorELTag.doStartTag(TrinidadValidatorELTag.java:54)
   at jsp_servlet.__test1_jspx._jspx___tag4(__test1_jspx.java:293)
   at jsp_servlet.__test1_jspx._jspx___tag3(__test1_jspx.java:256)
   at jsp_servlet.__test1_jspx._jspx___tag2(__test1_jspx.java:205)
   at jsp_servlet.__test1_jspx._jspx___tag1(__test1_jspx.java:155)
   at jsp_servlet.__test1_jspx._jspx___tag0(__test1_jspx.java:104)
   at jsp_servlet.__test1_jspx._jspService(__test1_jspx.java:65)
   at weblogic.servlet.jsp.JspBase.service(JspBase.java:34)
   at 
 weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
   at 
 weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:12

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

[VOTE] Release MyFaces Portlet Bridge 2.0.0 TCK

2011-01-11 Thread Michael Freedman

Please vote on the proposed release of MyFaces Portlet Bridge 2.0.0 
TCK.  This is the final version of the JSR 329 TCK and corresponds to  
Portlet 2.0 Bridge for JavaServer Faces 1.2 specification which was 
finalized/approved by the JCP last month.


Note:  The TCK is designed to be built and run directly from the maven 
project.  Because of this users are pointed directly to the subversion 
tag associated with version of the TCK:

https://svn.apache.org/repos/asf/myfaces/portlet-bridge/tck/tags/jsr329-1.0.0

Hence there are no repository artifacts built or hosted.  However, for 
convenience we do provide a downloadable version of this project


These components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge-tck/jsr329-1.0.0/

I have verified that the distributables can be expanded and the TCK can 
be built/run from this.  In addition I have verified the contents in the 
subversion tag.


Please review these materials 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,
  -Mike-

Re: Classloaders and component boundaries

2011-01-11 Thread David Jencks

Hi,

It's a month later, holidays are over, I'd like to ask again that this be 
considered.

thanks
david jencks

On Dec 6, 2010, at 6:09 PM, Leonardo Uribe wrote:

 Hi
 
 I don't think we can include it for 2.0.3 release. This change should be 
 discussed carefully, and that requires some time to analyze and identify the 
 implications if this patch is included.
 
 regards,
 
 Leonardo Uribe
 
 2010/12/6 David Jencks david_jen...@yahoo.com
 In geronimo we've been studying the ee platform spec section 8.3 and think 
 that it's allowable to have a single classloader per ear, and we're currently 
 implementing this (in geronimo 3).  However the jsf spec requires that 
 different web apps in an ear be distinguishable in the 
 javax.faces.FactoryFinder.  Currently myfaces' FactoryFinder distinguishes 
 web apps by context classloader.
 
 While there might be other possible solutions, I'd like to make the way 
 FactoryFinder figures out what context it's in pluggable.  The default 
 implementation would continue to use the TCCL, and geronimo can install a 
 system that relies on explicit notification from the container when component 
 boundaries are crossed.
 
 I've refactored the myfaces bit of this and it seems to work fine, but I'm 
 still working on the geronimo part.  However since a myfaces release seems 
 imminent I'd like to  get this proposal out for consideration and review 
 ASAP.  I've opened MYFACES-2995 and am attaching an initial patch for 
 consideration.
 
 thanks
 david jencks

Re: Classloaders and component boundaries

2011-01-11 Thread David Jencks


On Dec 7, 2010, at 4:42 AM, Mark Struberg wrote:

 Hi!
 
 Isn't the single EAR classloader the parentClassLoader of the WebApp 
 ClassLoaders? I do not really undrestand the problem here... Using only 1 
 classloader for the whole EAR (including webapps therein) would make the 
 re-deployment of single webapps impossible. But this is needed as far as I 
 remember the spec...

Could you quote something?  I've never seen any requirements even vaguely 
resembling this, geronimo has never implemented anything like this, and we've 
certified a lot of versions.  Recently several of us have looked carefully at 
the ee spec and think that 1 classloader per ear is definitely allowed.

thanks
david jencks

 
 So imo this sounds like a no-go
 
 LieGrue,
 strub
 
 --- On Tue, 12/7/10, David Jencks david_jen...@yahoo.com wrote:
 
 From: David Jencks david_jen...@yahoo.com
 Subject: Classloaders and component boundaries
 To: MyFaces Development dev@myfaces.apache.org
 Date: Tuesday, December 7, 2010, 12:44 AM
 In geronimo we've been studying the
 ee platform spec section 8.3 and think that it's allowable
 to have a single classloader per ear, and we're currently
 implementing this (in geronimo 3).  However the jsf
 spec requires that different web apps in an ear be
 distinguishable in the javax.faces.FactoryFinder. 
 Currently myfaces' FactoryFinder distinguishes web apps by
 context classloader.
 
 While there might be other possible solutions, I'd like to
 make the way FactoryFinder figures out what context it's in
 pluggable.  The default implementation would continue
 to use the TCCL, and geronimo can install a system that
 relies on explicit notification from the container when
 component boundaries are crossed.
 
 I've refactored the myfaces bit of this and it seems to
 work fine, but I'm still working on the geronimo part. 
 However since a myfaces release seems imminent I'd like
 to  get this proposal out for consideration and review
 ASAP.  I've opened MYFACES-2995 and am attaching an
 initial patch for consideration.
 
 thanks
 david jencks

[jira] Commented: (TOMAHAWK-1560) Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD errors

2011-01-11 Thread Stan Silvert (JIRA)


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

Stan Silvert commented on TOMAHAWK-1560:


I'd be interested to know if this workaround fixes the problem.  Go to 
server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml.
  Set one or both of the validation properties to false:

bean name=TldParsingDeployer class=org.jboss.deployment.TldParsingDeployer
  property name=relativeOrder2002/property
  property name=useSchemaValidationfalse/property
  property name=useValidationfalse/property
/bean 

 Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD 
 errors
 ---

 Key: TOMAHAWK-1560
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1560
 Project: MyFaces Tomahawk
  Issue Type: Bug
Affects Versions: 1.1.10
Reporter: Kennard Consulting
Priority: Critical
 Attachments: TOMAHAWK-1560.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 Tomahawk 1.1.10 for JSF 1.2 fails to deploy on the recently released JBoss AS 
 6. This appears to be because of errors in tomahawk.tld. I managed to resolve 
 it by taking the following steps (any of which may be sub-optimal):
 1. Changed 
 xsi:schemaLocation=http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd;
  to xsi:schemaLocation=http://java.sun.com/xml/ns/javaee 
 http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; (i.e. the first 
 half of the schemaLocation was missing)
 2. Removed display-name tag (is a bad element name?)
 3. Removed all description tags (they contain invalid markup?)
 Regards,
 Richard.

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

Re: [VOTE] Apache MyFaces Trinidad 1.2.14

Here we go:
https://issues.jboss.org/browse/JBAS-8800

On Tuesday, January 11, 2011, Matthias Wessendorf mat...@apache.org wrote:
 Similar to Tomcat 7, the WAR works fine inside of JBoss 5

 -Matthias

 On Tue, Jan 11, 2011 at 9:43 AM, Matthias Wessendorf mat...@apache.org 
 wrote:
 Hi,

 on tomcat 7 it works (I just had to add MyFaces 1.2.9 and JSTL 1.2 to
 the demo WAR file).
 I want to try JBoss AS5, but jboss.org is currently down.

 I gave Stan silvert a heads up on this issue as well (he thought that
 Tomcat 7 may have
 the same issue - but it works in beta-5)

 -Matthias

 On Mon, Jan 10, 2011 at 7:43 PM, Christian Kaltepoth
 christ...@kaltepoth.de wrote:
 As far as I know the schemaLocation attribute must always contain the
 namespace and the location of the XSD file. Specifying only the
 location of the XSD is wrong in my option as it is not clear for which
 namespace the XSD is (without downloading it of cause).

 But I might be wrong. I didn't find the correct section in the spec yet! :-)

 Christian

 2011/1/10 Matthias Wessendorf mat...@apache.org:
 meh...

 19:22:49,086 WARN  [SaxJBossXBParser] SchemaLocation: schemaLocation
 value = 'http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd'
 must have even number of URI's. @
 vfs:///home/matzew/JBoss6/jboss-6.0.0.Final/server/default/deploy/trinidad-demo-1.2.14.war/WEB-INF/lib/trinidad-impl-1.2.14.jar/META-INF/tr.tld[1,238]
 19:22:49,102 WARN  [JBossEntityResolver] Trying to resolve systemId as
 a non-file URL: http://java.sun.com/xml/ns/javaee



 this sucks :)

 Question is... should the container resolve it, or is the current behavior 
 OK...

 -Matthias


 On Mon, Jan 10, 2011 at 7:08 PM, Matthias Wessendorf mat...@apache.org 
 wrote:
 looks like we are OK here.

 (currently downloading JBoss to check details early 2morrow)

 -M

 On Mon, Jan 10, 2011 at 7:06 PM, Matthias Wessendorf mat...@apache.org 
 wrote:
 It looks like the TLD starts with the correct namespaces

 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/web-jsptaglibrary_2_1.xsd;
 version=2.1


  display-nameApache Trinidad Core/display-name
 ...
 ...

 -Matthias

 On Mon, Jan 10, 2011 at 7:04 PM, Matthias Wessendorf mat...@apache.org 
 wrote:
 So basically JBoss' JavaEE 6 container is not backwards compatible to 
 EE5.

 Why are the URLs and elements outdated? Aren't say valid for JavaEE 5 ?

 -Matthias

 On Mon, Jan 10, 2011 at 6:09 PM, Christian Kaltepoth
 christ...@kaltepoth.de wrote:
 Hey Matthias,

--
 Matthias Wessendorf

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


-- 
Matthias Wessendorf

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

[jira] Commented: (TRINIDAD-1985) High live memory usage from SkinStyleProvider

2011-01-11 Thread Jeanne Waldman (JIRA)


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

Jeanne Waldman commented on TRINIDAD-1985:
--

When we get a new browser/locale/etc., we get the StyleSheetNodes that match 
the StyleContext (this is browser,locale,etc).
Then we merge these together to get the final list of StyleNodes, and from this 
we generate the css file.
This is the code that needs to be re-run when we get a new browser/locale/etc., 
where the resulting StyleSheetNodes are unique.
In the adf faces skin files, we have many rules that are particular to a 
browser, even a browser version
@agent gecko and (version: 1.7)
@agent gecko and (max-version: 1.9.0)
@agent gecko and (version: 1.8) {

So for gecko 1.7, we'll generate a css file. For gecko 1.8, we'll generate a 
different css file, and so on.

Stevan and I think we can try a LRU cache of size 8, and make it configurable 
so we can run some tests.
(also, consider optimizing the css generation code as mentioned in 
https://issues.apache.org/jira/browse/TRINIDAD-1675, because if we improve 
memory with this jira fix, then we'll need to generate the css files more often 
and we'll want to speed up that code.)


 High live memory usage from SkinStyleProvider
 -

 Key: TRINIDAD-1985
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1985
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Archetype
Affects Versions:  1.2.12-core
Reporter: Stevan Malesevic

 We were checking a live memory usage in one app and noticed that some 83MB of 
 heap is pinned under SkinStyleProvider. This is under 14 instances of 
 FileSystemStyleCache$Entry each with about 6MB of memory
 Heap shows these keys for styles
 LocaleVersion
 enMozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
 koMozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11) 
 Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11) 
 Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729)
 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 
 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 
 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) 
 Gecko/20090824 Firefox/3.5.3
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) 
 Gecko/20090824 Firefox/3.5.3
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18) 
 Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729)
 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18) 
 Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) 
 Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729)
 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) 
 Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729)
 enMozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; .NET 
 CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) 
 Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.15) 
 Gecko/20101026 Firefox/3.5.15 ( .NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) 
 Gecko/20100914 Firefox/3.6.10 (.NET CLR 3.5.30729)
 koMozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; 
 .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
 enMozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; 
 .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) 
 Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) 
 Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729)
 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) 
 Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) 
 Gecko/20101203 Firefox/3.6.13
 Now beside the amount of memory pinned by single FileSystemStyleCache$Entry 
 the issue is that we apparently create too many different versions and there 
 is no restriction to the size of cache leaving open door for memory leak
 Two questions
 1. Do we really have different styles for FF on 3.5 or 3.6 or so?  If not why 
 do we key by it?
 2. Given different browsers and locales having cache as plain concurrent hash 
 map is actually a source of leak as over time it can accumulate

[jira] Updated: (MYFACES-3009) Flash scope looses values on redirect


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

Leonardo Uribe updated MYFACES-3009:


Status: Patch Available  (was: Open)

 Flash scope looses values on redirect
 -

 Key: MYFACES-3009
 URL: https://issues.apache.org/jira/browse/MYFACES-3009
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.3
Reporter: Jakob Korherr
Assignee: Jakob Korherr
 Attachments: MYFACES-3009-1.patch


 Example as follows:
 1) A facelet called Entry.xhtml
 h:form
 table
  tr
tdFirst Name:/td
td
  h:inputText id=fname value=#{flash.firstName}required=true/
/td
  /tr
  tr
tdLast Name:/td
td
  h:inputText id=lname value=#{flash.lastName}   required=true/
/td
  /tr
 /table
  ph:commandButton value=Submit action=confirmation?faces-redirect=true
 //p
  /h:form
 and the confirmation.xhtml:
 table
  tr
tdFirst Name:/td
td
  h:outputText value=#{flash.keep.firstName} /
/td
  /tr
  tr
tdLast Name:/td
td
  h:outputText value=#{flash.keep.lastName}/
/td
   /tr
 /table
 h:form
 ph:commandButton value=Confirm action=finished?faces-redirect=true 
 //p
 /h:form
 But when the confirmation page is loaded, the firstName and lastName I 
 submitted
 is missing. Why? I am using flash.keep. According to what I read it should
 keep the values more than a PRG cycle.
 It works if I use Mojarra.

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

[jira] Commented: (MYFACES-3009) Flash scope looses values on redirect


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

Leonardo Uribe commented on MYFACES-3009:
-

Attached to this mail there is a patch for this issue. After doing some 
step-by-step on the example, I notice we are not calling 
elContext.setPropertyResolved(true) when flash.keep is used, and in this 
specific case, the value to be promoted is not on request map, so we are not 
returning it correctly. 

It is weird that flash.keep() method does not return the value. I would like to 
have a simple method for this one instead do a workaround through request map, 
but I think it is the most simple solution we have without introduce some 
coupling between FlashELResolver and FlashImpl.

If no objections, I'll commit this patch soon.

 Flash scope looses values on redirect
 -

 Key: MYFACES-3009
 URL: https://issues.apache.org/jira/browse/MYFACES-3009
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.3
Reporter: Jakob Korherr
Assignee: Jakob Korherr
 Attachments: MYFACES-3009-1.patch


 Example as follows:
 1) A facelet called Entry.xhtml
 h:form
 table
  tr
tdFirst Name:/td
td
  h:inputText id=fname value=#{flash.firstName}required=true/
/td
  /tr
  tr
tdLast Name:/td
td
  h:inputText id=lname value=#{flash.lastName}   required=true/
/td
  /tr
 /table
  ph:commandButton value=Submit action=confirmation?faces-redirect=true
 //p
  /h:form
 and the confirmation.xhtml:
 table
  tr
tdFirst Name:/td
td
  h:outputText value=#{flash.keep.firstName} /
/td
  /tr
  tr
tdLast Name:/td
td
  h:outputText value=#{flash.keep.lastName}/
/td
   /tr
 /table
 h:form
 ph:commandButton value=Confirm action=finished?faces-redirect=true 
 //p
 /h:form
 But when the confirmation page is loaded, the firstName and lastName I 
 submitted
 is missing. Why? I am using flash.keep. According to what I read it should
 keep the values more than a PRG cycle.
 It works if I use Mojarra.

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

[jira] Commented: (TOMAHAWK-1560) Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD errors


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

Kennard Consulting commented on TOMAHAWK-1560:
--

Stan,

Thanks for your time in looking at this.

Your suggestion does not appear to have any effect. Even with both 
'useSchemaValidation' and 'useValidation' set to false, the error is the same...

Caused by: org.jboss.xb.binding.JBossXBRuntimeException: -1:-1 -1:-1 
schema_reference.4: Failed to read schema document 'null', because 1) could not 
find the document; 2) the document could not be read; 3) the root element of 
the document is not xsd:schema.
at 
org.jboss.xb.binding.sunday.unmarshalling.XsdBinderTerminatingErrorHandler.handleError(XsdBinderTerminatingErrorHandler.java:40)
 [jbossxb.jar:2.0.3.GA]
at 
org.apache.xerces.impl.xs.XMLSchemaLoader.reportDOMFatalError(Unknown Source) 
[xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.impl.xs.XSLoaderImpl.load(Unknown Source) 
[xercesImpl.jar:6.0.0.Final]
at org.jboss.xb.binding.Util.loadSchema(Util.java:394) 
[jbossxb.jar:2.0.3.GA]
at 
org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:178) 
[jbossxb.jar:2.0.3.GA]
at 
org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:149) 
[jbossxb.jar:2.0.3.GA]
at 
org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:342)
 [jbossxb.jar:2.0.3.GA]
... 72 more

...this is perhaps a little surprising, but maybe JBoss is trying to load the 
schema even though it has been told not to use it? If I remove the 
TldParsingDeployer bean altogether from war-deployers-jboss-beans.xml then 
there is no error (but presumably things will fail at a later stage).

Regards,

Richard.

 Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD 
 errors
 ---

 Key: TOMAHAWK-1560
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1560
 Project: MyFaces Tomahawk
  Issue Type: Bug
Affects Versions: 1.1.10
Reporter: Kennard Consulting
Priority: Critical
 Attachments: TOMAHAWK-1560.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 Tomahawk 1.1.10 for JSF 1.2 fails to deploy on the recently released JBoss AS 
 6. This appears to be because of errors in tomahawk.tld. I managed to resolve 
 it by taking the following steps (any of which may be sub-optimal):
 1. Changed 
 xsi:schemaLocation=http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd;
  to xsi:schemaLocation=http://java.sun.com/xml/ns/javaee 
 http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; (i.e. the first 
 half of the schemaLocation was missing)
 2. Removed display-name tag (is a bad element name?)
 3. Removed all description tags (they contain invalid markup?)
 Regards,
 Richard.

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

[jira] Issue Comment Edited: (TOMAHAWK-1560) Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD errors


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

Kennard Consulting edited comment on TOMAHAWK-1560 at 1/11/11 6:49 PM:
---

Stan,

Thanks for your time in looking at this.

Your suggestion does not appear to have any effect. Even with both 
'useSchemaValidation' and 'useValidation' set to false, the error is the same...

Caused by: org.jboss.xb.binding.JBossXBRuntimeException: -1:-1 -1:-1 
schema_reference.4: Failed to read schema document 'null', because 1) could not 
find the document; 2) the document could not be read; 3) the root element of 
the document is not xsd:schema.
at 
org.jboss.xb.binding.sunday.unmarshalling.XsdBinderTerminatingErrorHandler.handleError(XsdBinderTerminatingErrorHandler.java:40)
 [jbossxb.jar:2.0.3.GA]
at 
org.apache.xerces.impl.xs.XMLSchemaLoader.reportDOMFatalError(Unknown Source) 
[xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.impl.xs.XSLoaderImpl.load(Unknown Source) 
[xercesImpl.jar:6.0.0.Final]
at org.jboss.xb.binding.Util.loadSchema(Util.java:394) 
[jbossxb.jar:2.0.3.GA]
at 
org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:178) 
[jbossxb.jar:2.0.3.GA]
at 
org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:149) 
[jbossxb.jar:2.0.3.GA]
at 
org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:342)
 [jbossxb.jar:2.0.3.GA]
... 72 more

...this is perhaps a little surprising, but maybe JBoss is trying to load the 
schema even though it doesn't intend to use it? If I remove the 
TldParsingDeployer bean altogether from war-deployers-jboss-beans.xml then 
there is no error (but presumably things will fail at a later stage).

Regards,

Richard.

  was (Author: kennardconsulting):
Stan,

Thanks for your time in looking at this.

Your suggestion does not appear to have any effect. Even with both 
'useSchemaValidation' and 'useValidation' set to false, the error is the same...

Caused by: org.jboss.xb.binding.JBossXBRuntimeException: -1:-1 -1:-1 
schema_reference.4: Failed to read schema document 'null', because 1) could not 
find the document; 2) the document could not be read; 3) the root element of 
the document is not xsd:schema.
at 
org.jboss.xb.binding.sunday.unmarshalling.XsdBinderTerminatingErrorHandler.handleError(XsdBinderTerminatingErrorHandler.java:40)
 [jbossxb.jar:2.0.3.GA]
at 
org.apache.xerces.impl.xs.XMLSchemaLoader.reportDOMFatalError(Unknown Source) 
[xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.impl.xs.XSLoaderImpl.load(Unknown Source) 
[xercesImpl.jar:6.0.0.Final]
at org.jboss.xb.binding.Util.loadSchema(Util.java:394) 
[jbossxb.jar:2.0.3.GA]
at 
org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:178) 
[jbossxb.jar:2.0.3.GA]
at 
org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:149) 
[jbossxb.jar:2.0.3.GA]
at 
org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:342)
 [jbossxb.jar:2.0.3.GA]
... 72 more

...this is perhaps a little surprising, but maybe JBoss is trying to load the 
schema even though it has been told not to use it? If I remove the 
TldParsingDeployer bean altogether from war-deployers-jboss-beans.xml then 
there is no error (but presumably things will fail at a later stage).

Regards,

Richard.
  
 Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD 
 errors
 ---

 Key: TOMAHAWK-1560
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1560
 Project: MyFaces Tomahawk
  Issue Type: Bug
Affects Versions: 1.1.10
Reporter: Kennard Consulting
Priority: Critical
 Attachments: TOMAHAWK-1560.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 Tomahawk 1.1.10 for JSF 1.2 fails to deploy on the recently released JBoss AS 
 6. This appears to be because of errors in tomahawk.tld. I managed to resolve 
 it by taking the following steps (any of which may be sub-optimal):
 1. Changed 
 xsi:schemaLocation=http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd;
  to xsi:schemaLocation=http://java.sun.com/xml/ns/javaee 
 http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; (i.e. the first 
 half of the schemaLocation was missing)
 2. Removed display-name tag (is a bad element name?)
 3. Removed all description tags (they contain invalid markup?)
 Regards,
 Richard.

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

[jira] Commented: (MYFACES-3010) 2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType

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

Kennard Consulting commented on MYFACES-3010:
-

Terrific. Could I trouble you to send a JAR to rich...@kennardconsulting.com
and I'll try it in Metawidget proper (which does a number of further tests)?

2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType
-

Attachments: addressbook-faces2.zip

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

[jira] Issue Comment Edited: (MYFACES-3010) 2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType

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

Kennard Consulting edited comment on MYFACES-3010 at 1/11/11 7:09 PM:
--

Terrific. Could I trouble you to send a JAR to richard at kennardconsulting dot
com and I'll try it in Metawidget proper (which does a number of further tests)?

was (Author: kennardconsulting):
Terrific. Could I trouble you to send a JAR to
rich...@kennardconsulting.com and I'll try it in Metawidget proper (which does
a number of further tests)?

2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType
-

Attachments: addressbook-faces2.zip

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

[jira] Updated: (TRINIDAD-1979) Issue with client side DateRestrictionValidator

2011-01-11 Thread Gabrielle Crawford (JIRA)


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

Gabrielle Crawford updated TRINIDAD-1979:
-

   Resolution: Fixed
Fix Version/s: 2.0.0.4-core 
   Status: Resolved  (was: Patch Available)

 Issue with client side DateRestrictionValidator 
 

 Key: TRINIDAD-1979
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1979
 Project: MyFaces Trinidad
  Issue Type: Bug
 Environment: environment independent
Reporter: Jing Wu
Priority: Minor
 Fix For: 2.0.0.4-core 

 Attachments: hint.patch


 Client side date restriction validator (TrDateRestrictionValidator) has an 
 issue getting the hint. The hint is produced by function 
 TrDateRestrictionValidator.prototype.getHints(), which 
 (1) remove the disabled weekday values from the full weekday list
 (2) remove the disabled month values from the full month list
 (3) generate the final hint message
 (1) and (2) is achieved by calling 
 TrCollections.removeValuesFromArray(Object, Object), but 
 TrCollections.removeValuesFromArray(Object, Object) assumes that both 
 arguments are of type Array, while the disabled weekday values and disabled 
 month values are maps, so (1) and (2) are not performed correctly, thus the 
 final hint message is wrong. 
 We need to add a method in TrCollections to remove values in a map from the 
 array and calls that method in 
 TrDateRestrictionValidator.prototype.getHints().

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

[jira] Issue Comment Edited: (MYFACES-3010) 2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType

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

Kennard Consulting edited comment on MYFACES-3010 at 1/11/11 7:33 PM:
--

Terrific. Could I trouble you to send a JAR to richard at kennardconsulting dot
com (the nightly builds don't seem to be working anymore?) and I'll try it in
Metawidget proper, which does a number of further tests?

was (Author: kennardconsulting):
Terrific. Could I trouble you to send a JAR to richard at kennardconsulting
dot com and I'll try it in Metawidget proper (which does a number of further
tests)?

2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType
-

Attachments: addressbook-faces2.zip

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

[jira] Commented: (MYFACES-3010) 2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType

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

Leonardo Uribe commented on MYFACES-3010:
-

Looking on hudson:

https://hudson.apache.org/hudson/view/M-R/view/MyFaces/

Everything looks good. You can find the latest build here:

2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType
-

Attachments: addressbook-faces2.zip

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

[jira] Issue Comment Edited: (MYFACES-3010) 2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType

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

Leonardo Uribe edited comment on MYFACES-3010 at 1/11/11 8:03 PM:
--

Looking on hudson:

https://hudson.apache.org/hudson/view/M-R/view/MyFaces/

Everything looks good. You can find the latest build here:

https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/core/

was (Author: lu4242):
Looking on hudson:

https://hudson.apache.org/hudson/view/M-R/view/MyFaces/

Everything looks good. You can find the latest build here:

2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType
-

Attachments: addressbook-faces2.zip

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

[jira] Commented: (MYFACES-3010) 2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType

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

Kennard Consulting commented on MYFACES-3010:
-

Yep. I can confirm myfaces-api-2.0.4-20110111.213242-15.jar passes all my
Metawidget tests. Please consider this issue closed. Thank you so much for your
quick turnaround!

BTW: you may want to change the link on http://myfaces.apache.org/download.html
to 'nightly build', it currently goes to
http://people.apache.org/builds/myfaces/nightly/, which is why I couldn't find
the nightly.

2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType
-

Attachments: addressbook-faces2.zip

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

[jira] Commented: (TRINIDAD-1985) High live memory usage from SkinStyleProvider

2011-01-11 Thread Jeanne Waldman (JIRA)


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

Jeanne Waldman commented on TRINIDAD-1985:
--

Something to think about --
In the FileSystemStyleCache code, the _cache and _entryCache are 
ConcurrentMaps. If we use an LRU implementation 
org.apache.myfaces.trinidadinternal.util.LRUCache extends LinkedHashMap, and 
wrap this in Collections.synchronizedMap, then we will lose the features of 
ConcurrentMap. We'll need to synchronize on remove, and from what I've read, we 
will lose scalability since only one thread can access the Map at once with 
synchronizedMap.

 High live memory usage from SkinStyleProvider
 -

 Key: TRINIDAD-1985
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1985
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Archetype
Affects Versions:  1.2.12-core
Reporter: Stevan Malesevic

 We were checking a live memory usage in one app and noticed that some 83MB of 
 heap is pinned under SkinStyleProvider. This is under 14 instances of 
 FileSystemStyleCache$Entry each with about 6MB of memory
 Heap shows these keys for styles
 LocaleVersion
 enMozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
 koMozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11) 
 Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11) 
 Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729)
 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 
 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 
 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) 
 Gecko/20090824 Firefox/3.5.3
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) 
 Gecko/20090824 Firefox/3.5.3
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18) 
 Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729)
 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18) 
 Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) 
 Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729)
 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) 
 Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729)
 enMozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; .NET 
 CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) 
 Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.15) 
 Gecko/20101026 Firefox/3.5.15 ( .NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) 
 Gecko/20100914 Firefox/3.6.10 (.NET CLR 3.5.30729)
 koMozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; 
 .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
 enMozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; 
 .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) 
 Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) 
 Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729)
 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) 
 Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) 
 Gecko/20101203 Firefox/3.6.13
 Now beside the amount of memory pinned by single FileSystemStyleCache$Entry 
 the issue is that we apparently create too many different versions and there 
 is no restriction to the size of cache leaving open door for memory leak
 Two questions
 1. Do we really have different styles for FF on 3.5 or 3.6 or so?  If not why 
 do we key by it?
 2. Given different browsers and locales having cache as plain concurrent hash 
 map is actually a source of leak as over time it can accumulate more and 
 more. Do we have any restriction there? Should  the entries by LRU or have 
 exparation

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

[jira] Issue Comment Edited: (TRINIDAD-1985) High live memory usage from SkinStyleProvider

2011-01-11 Thread Jeanne Waldman (JIRA)


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

Jeanne Waldman edited comment on TRINIDAD-1985 at 1/11/11 11:08 PM:


Something to think about --
In the FileSystemStyleCache code, the _cache and _entryCache are 
ConcurrentMaps. If we use an LRU implementation 
org.apache.myfaces.trinidadinternal.util.LRUCache extends LinkedHashMap, and 
wrap this in Collections.synchronizedMap, then we will lose the features of 
ConcurrentMap; we will lose scalability since only one thread can access the 
Map at once with synchronizedMap.

  was (Author: jeanne.wald...@oracle.com):
Something to think about --
In the FileSystemStyleCache code, the _cache and _entryCache are 
ConcurrentMaps. If we use an LRU implementation 
org.apache.myfaces.trinidadinternal.util.LRUCache extends LinkedHashMap, and 
wrap this in Collections.synchronizedMap, then we will lose the features of 
ConcurrentMap. We'll need to synchronize on remove, and from what I've read, we 
will lose scalability since only one thread can access the Map at once with 
synchronizedMap.
  
 High live memory usage from SkinStyleProvider
 -

 Key: TRINIDAD-1985
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1985
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Archetype
Affects Versions:  1.2.12-core
Reporter: Stevan Malesevic

 We were checking a live memory usage in one app and noticed that some 83MB of 
 heap is pinned under SkinStyleProvider. This is under 14 instances of 
 FileSystemStyleCache$Entry each with about 6MB of memory
 Heap shows these keys for styles
 LocaleVersion
 enMozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
 koMozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11) 
 Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11) 
 Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729)
 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 
 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 
 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) 
 Gecko/20090824 Firefox/3.5.3
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) 
 Gecko/20090824 Firefox/3.5.3
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18) 
 Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729)
 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18) 
 Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) 
 Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729)
 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) 
 Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729)
 enMozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; .NET 
 CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) 
 Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.15) 
 Gecko/20101026 Firefox/3.5.15 ( .NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) 
 Gecko/20100914 Firefox/3.6.10 (.NET CLR 3.5.30729)
 koMozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; 
 .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
 enMozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; 
 .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) 
 Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) 
 Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729)
 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) 
 Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729)
 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) 
 Gecko/20101203 Firefox/3.6.13
 Now beside the amount of memory pinned by single FileSystemStyleCache$Entry 
 the issue is that we apparently create too many different versions and there 
 is no restriction to the size of cache leaving open door for memory leak
 Two questions
 1. Do we really have different styles for FF on 3.5 or 3.6 or so?  If not why 
 do we key by it?
 2. Given different browsers and locales having cache as plain concurrent hash 
 map is actually a source of leak as over time it can accumulate more and 
 more. Do we have any restriction there? Should  the

[jira] Commented: (TOMAHAWK-1560) Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD errors

2011-01-11 Thread Christian Kaltepoth (JIRA)

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

Christian Kaltepoth commented on TOMAHAWK-1560:
---

Here is a link to the JBoss issue that Stan created regarding this:

https://issues.jboss.org/browse/JBAS-8800

However, I think that this issue should also be fixed in the
Trinidad/Tomahawk/Commons TLDs. It is undeniable that the current TLDs are not
readable by a validating parser because they do not validate against the
schema. And that is something that should be fixed for future versions.

Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD
errors
---

Key: TOMAHAWK-1560
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1560
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.10
Reporter: Kennard Consulting
Priority: Critical
Attachments: TOMAHAWK-1560.patch

Original Estimate: 1h
Remaining Estimate: 1h

Tomahawk 1.1.10 for JSF 1.2 fails to deploy on the recently released JBoss AS
6. This appears to be because of errors in tomahawk.tld. I managed to resolve
it by taking the following steps (any of which may be sub-optimal):
1. Changed
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd;
to xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; (i.e. the first
half of the schemaLocation was missing)
2. Removed display-name tag (is a bad element name?)
3. Removed all description tags (they contain invalid markup?)
Regards,
Richard.

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

[jira] Reopened: (MYFACES-3006) FacesContext current instance is null in managed bean action method for Tomcat 7

2011-01-11 Thread Gurkan Erdogdu (JIRA)


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

Gurkan Erdogdu reopened MYFACES-3006:
-


Indicated above.

 FacesContext current instance is null in managed bean action method for 
 Tomcat 7
 

 Key: MYFACES-3006
 URL: https://issues.apache.org/jira/browse/MYFACES-3006
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 2.0.2
Reporter: Gurkan Erdogdu
Assignee: Leonardo Uribe

 Hello, 
 Actually I am not sure that this is an error related with MyFaces.
 In a managed bean action method, I have stopped an application Tomcat 
 Context(not same with the current JSF application).
 public String stopContext(){
  
  FacesContext.getCurrentInsatnce() -- It is ok, faces context is not null
  Context context = get Tomcat application context;
  //Stop tomcat context
  context.stop();   -- This is any application on Tomcat, not same with 
 current JSF application
  FacesContext.getCurrentInstance() -- Problem, it is NULL
 }
 I think that Tomcat clear current JSF application thread locals. But I ask to 
 stop other application context, therefore it must not destroy current 
 application thread locals.
 What do you think?

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

[jira] Commented: (MYFACES-3006) FacesContext current instance is null in managed bean action method for Tomcat 7

2011-01-11 Thread Gurkan Erdogdu (JIRA)


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

Gurkan Erdogdu commented on MYFACES-3006:
-

As I indicated in the code, I am closing another non-JSF application context, 
not current running JSF application context. Therefore, your observation is not 
correct

 FacesContext current instance is null in managed bean action method for 
 Tomcat 7
 

 Key: MYFACES-3006
 URL: https://issues.apache.org/jira/browse/MYFACES-3006
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 2.0.2
Reporter: Gurkan Erdogdu
Assignee: Leonardo Uribe

 Hello, 
 Actually I am not sure that this is an error related with MyFaces.
 In a managed bean action method, I have stopped an application Tomcat 
 Context(not same with the current JSF application).
 public String stopContext(){
  
  FacesContext.getCurrentInsatnce() -- It is ok, faces context is not null
  Context context = get Tomcat application context;
  //Stop tomcat context
  context.stop();   -- This is any application on Tomcat, not same with 
 current JSF application
  FacesContext.getCurrentInstance() -- Problem, it is NULL
 }
 I think that Tomcat clear current JSF application thread locals. But I ask to 
 stop other application context, therefore it must not destroy current 
 application thread locals.
 What do you think?

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

[jira] Commented: (MYFACES-3006) FacesContext current instance is null in managed bean action method for Tomcat 7

2011-01-11 Thread Gurkan Erdogdu (JIRA)

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

Gurkan Erdogdu commented on MYFACES-3006:
-

Another observation is that, when I execute context.stop() in another thread,
there is no problem. Therefore, problem lies on ThreadLocal clearing within
Myfaces or probably on Tomcat side.

FacesContext current instance is null in managed bean action method for
Tomcat 7

Key: MYFACES-3006
URL: https://issues.apache.org/jira/browse/MYFACES-3006
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.2
Reporter: Gurkan Erdogdu
Assignee: Leonardo Uribe

Hello,
Actually I am not sure that this is an error related with MyFaces.
In a managed bean action method, I have stopped an application Tomcat
Context(not same with the current JSF application).
public String stopContext(){

FacesContext.getCurrentInsatnce() -- It is ok, faces context is not null
Context context = get Tomcat application context;
//Stop tomcat context
context.stop(); -- This is any application on Tomcat, not same with
current JSF application
FacesContext.getCurrentInstance() -- Problem, it is NULL
}
I think that Tomcat clear current JSF application thread locals. But I ask to
stop other application context, therefore it must not destroy current
application thread locals.
What do you think?

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

Re: [VOTE] Release MyFaces Portlet Bridge 2.0.0 TCK

was there any reason why you didn't use Nexus for the release procedure?
MyFaces (sub)projects agreed to use this..

On Tue, Jan 11, 2011 at 10:45 PM, Michael Freedman
michael.freed...@oracle.com wrote:
 Please vote on the proposed release of MyFaces Portlet Bridge 2.0.0 TCK.
  This is the final version of the JSR 329 TCK and corresponds to  Portlet
 2.0 Bridge for JavaServer Faces 1.2 specification which was
 finalized/approved by the JCP last month.

 Note:  The TCK is designed to be built and run directly from the maven
 project.  Because of this users are pointed directly to the subversion tag
 associated with version of the TCK:
 https://svn.apache.org/repos/asf/myfaces/portlet-bridge/tck/tags/jsr329-1.0.0

 Hence there are no repository artifacts built or hosted.  However, for
 convenience we do provide a downloadable version of this project

 These components can be inspected in
 http://people.apache.org/~mfreedman/portlet-bridge-tck/jsr329-1.0.0/

 I have verified that the distributables can be expanded and the TCK can be
 built/run from this.  In addition I have verified the contents in the
 subversion tag.

 Please review these materials 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,
  -Mike-




-- 
Matthias Wessendorf

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

Re: [VOTE] Release MyFaces Portlet Bridge 2.0.0