[jira] Created: (MYFACES-2933) Our archetype poms are not entirely correctly understood by Netbeans

2010-09-30 Thread Werner Punz (JIRA) 
Our archetype poms are not entirely correctly understood by Netbeans


 Key: MYFACES-2933
 URL: https://issues.apache.org/jira/browse/MYFACES-2933
 Project: MyFaces Core
  Issue Type: Bug
  Components: Archetype
Affects Versions: 2.0.2
 Environment: all
Reporter: Werner Punz


We have a small structural problem in the myfaces archetypes. This is not a bug 
in our code, but nevertheless easily fixable. The problem is the way we handle 
the profiles which is not correctly understood by Netbeans 6.9.

We have following code:
profiles
profile
idmyfaces/id
activation
property
name!jsf/name
/property
/activation

and

 profile
!-- Activate by adding -Djsf=mojarra --
idmojarra/id
activation
property
namejsf/name
valuemojarra/value
/property
/activation

No this structure just should ensure that if no jsf=... is set myfaces is 
chosen automatically. This makes netbeans go haiwire if you chosse mojarra as 
profile because suddenly we have the mojarra and myfaces dependencies parallely 
in the project.

Since this structure is mostly a hack we should replace it with the correct way 
to do things here:

activation
activeByDefaulttrue/activeByDefault
property
namejsf/name
valuemyfaces/value
/property
/activation

instead of !jsf so if no value is given we activate the myfaces profile by 
default

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

[jira] Commented: (MYFACES-2933) Our archetype poms are not entirely correctly understood by Netbeans

2010-09-30 Thread Werner Punz (JIRA) 

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

Werner Punz commented on MYFACES-2933:
--

Ok addendum if we do it the activeByDefault way, the jetty startup fails.. 
because we then disable it


 Our archetype poms are not entirely correctly understood by Netbeans
 

 Key: MYFACES-2933
 URL: https://issues.apache.org/jira/browse/MYFACES-2933
 Project: MyFaces Core
  Issue Type: Bug
  Components: Archetype
Affects Versions: 2.0.2
 Environment: all
Reporter: Werner Punz

 We have a small structural problem in the myfaces archetypes. This is not a 
 bug in our code, but nevertheless easily fixable. The problem is the way we 
 handle the profiles which is not correctly understood by Netbeans 6.9.
 We have following code:
 profiles
 profile
 idmyfaces/id
 activation
 property
 name!jsf/name
 /property
 /activation
 and
  profile
 !-- Activate by adding -Djsf=mojarra --
 idmojarra/id
 activation
 property
 namejsf/name
 valuemojarra/value
 /property
 /activation
 No this structure just should ensure that if no jsf=... is set myfaces is 
 chosen automatically. This makes netbeans go haiwire if you chosse mojarra as 
 profile because suddenly we have the mojarra and myfaces dependencies 
 parallely in the project.
 Since this structure is mostly a hack we should replace it with the correct 
 way to do things here:
 activation
 activeByDefaulttrue/activeByDefault
 property
 namejsf/name
 valuemyfaces/value
 /property
 /activation
 instead of !jsf so if no value is given we activate the myfaces profile by 
 default

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

[jira] Commented: (MYFACES-2933) Our archetype poms are not entirely correctly understood by Netbeans

2010-09-30 Thread Werner Punz (JIRA) 

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

Werner Punz commented on MYFACES-2933:
--

Ok netbeans does following at context switching mvn clean install -Pmojarra
the result with out structure in this case is that we pack both impls in 
because there is no -D parameter set

I tried it from the command line and I am getting following result:

werner-punzs-macbook-air-3:helloworld werpu2$ ls target/helloworld/WEB-INF/lib/
commons-beanutils-1.7.0.jar commons-logging-1.0.4.jar
commons-codec-1.3.jar   jsf-api-2.0.3.jar
commons-collections-3.2.jar jsf-impl-2.0.3.jar
commons-digester-1.8.jarmyfaces-api-2.0.1.jar
commons-discovery-0.4.jar   myfaces-impl-2.0.1.jar



 Our archetype poms are not entirely correctly understood by Netbeans
 

 Key: MYFACES-2933
 URL: https://issues.apache.org/jira/browse/MYFACES-2933
 Project: MyFaces Core
  Issue Type: Bug
  Components: Archetype
Affects Versions: 2.0.2
 Environment: all
Reporter: Werner Punz

 We have a small structural problem in the myfaces archetypes. This is not a 
 bug in our code, but nevertheless easily fixable. The problem is the way we 
 handle the profiles which is not correctly understood by Netbeans 6.9.
 We have following code:
 profiles
 profile
 idmyfaces/id
 activation
 property
 name!jsf/name
 /property
 /activation
 and
  profile
 !-- Activate by adding -Djsf=mojarra --
 idmojarra/id
 activation
 property
 namejsf/name
 valuemojarra/value
 /property
 /activation
 No this structure just should ensure that if no jsf=... is set myfaces is 
 chosen automatically. This makes netbeans go haiwire if you chosse mojarra as 
 profile because suddenly we have the mojarra and myfaces dependencies 
 parallely in the project.
 Since this structure is mostly a hack we should replace it with the correct 
 way to do things here:
 activation
 activeByDefaulttrue/activeByDefault
 property
 namejsf/name
 valuemyfaces/value
 /property
 /activation
 instead of !jsf so if no value is given we activate the myfaces profile by 
 default

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

[jira] Commented: (MYFACES-2933) Our archetype poms are not entirely correctly understood by Netbeans

2010-09-30 Thread Werner Punz (JIRA) 

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

Werner Punz commented on MYFACES-2933:
--

Ok I think the best solution would be just to have two profiles myfaces and 
mojarra and to push the entire jetty part into the main build area. Is there 
any reason why the jetty plugin was in a profile in the first place?

With this solution both impls can be started via mvn clean jetty:run -Pmojarra 
respectively -Pmyfaces and it works also as expected in Netbeans.

I need a comment from someone regarding this. Leonardo?


 Our archetype poms are not entirely correctly understood by Netbeans
 

 Key: MYFACES-2933
 URL: https://issues.apache.org/jira/browse/MYFACES-2933
 Project: MyFaces Core
  Issue Type: Bug
  Components: Archetype
Affects Versions: 2.0.2
 Environment: all
Reporter: Werner Punz

 We have a small structural problem in the myfaces archetypes. This is not a 
 bug in our code, but nevertheless easily fixable. The problem is the way we 
 handle the profiles which is not correctly understood by Netbeans 6.9.
 We have following code:
 profiles
 profile
 idmyfaces/id
 activation
 property
 name!jsf/name
 /property
 /activation
 and
  profile
 !-- Activate by adding -Djsf=mojarra --
 idmojarra/id
 activation
 property
 namejsf/name
 valuemojarra/value
 /property
 /activation
 No this structure just should ensure that if no jsf=... is set myfaces is 
 chosen automatically. This makes netbeans go haiwire if you chosse mojarra as 
 profile because suddenly we have the mojarra and myfaces dependencies 
 parallely in the project.
 Since this structure is mostly a hack we should replace it with the correct 
 way to do things here:
 activation
 activeByDefaulttrue/activeByDefault
 property
 namejsf/name
 valuemyfaces/value
 /property
 /activation
 instead of !jsf so if no value is given we activate the myfaces profile by 
 default

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

[jira] Created: (TOBAGO-921) Unsynchronized access to the cache of ThemeConfig

2010-09-30 Thread Udo Schnurpfeil (JIRA) 
Unsynchronized access to the cache of ThemeConfig
-

 Key: TOBAGO-921
 URL: https://issues.apache.org/jira/browse/TOBAGO-921
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.29
 Environment: JVM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01-279, 
mixed mode)
Reporter: Udo Schnurpfeil
Assignee: Udo Schnurpfeil
Priority: Critical


The problem seems to occur rarely.

When writing some code to set the cache under heavy stress I have the 
reproducible result that two threads are hanging in the HasMap.get() method. 


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

[jira] Commented: (TOBAGO-921) Unsynchronized access to the cache of ThemeConfig

2010-09-30 Thread Udo Schnurpfeil (JIRA) 

[ 
https://issues.apache.org/jira/browse/TOBAGO-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12916440#action_12916440
 ] 

Udo Schnurpfeil commented on TOBAGO-921:


Here is the code I call one time in each request in the tobago-example-demo 
application using mvn jetty:run-exploded

  private void stress() {
LOG.info(start test theme config -  + Thread.currentThread().getName());
FacesContext facesContext = FacesContext.getCurrentInstance();
UIComponent component = ComponentUtil.createComponent(
UILabel.COMPONENT_TYPE, TobagoConstants.RENDERER_TYPE_LABEL, dummy);
LayoutUtil.getInnerSpace(facesContext, component, 10, false);
for (int i = 0; i  100 ; i++) {
  try {
ThemeConfig.getValue(facesContext, component, fixedWidth);
ThemeConfig.getValue(facesContext, component, labelWidth);
ThemeConfig.getValue(facesContext, component, not-existing- + 
(int)(Math.random() * 100));
  } catch (Exception e) {
// ignore
  }
}
LOG.info(end   test theme config -  + Thread.currentThread().getName()
+  size= + ((Map) 
facesContext.getExternalContext().getApplicationMap().get(
org.apache.myfaces.tobago.config.ThemeConfig.CACHE)).size());
  }

I call the URL with wget in a loop in 2 command shells.


 Unsynchronized access to the cache of ThemeConfig
 -

 Key: TOBAGO-921
 URL: https://issues.apache.org/jira/browse/TOBAGO-921
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.29
 Environment: JVM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01-279, 
 mixed mode)
Reporter: Udo Schnurpfeil
Assignee: Udo Schnurpfeil
Priority: Critical

 The problem seems to occur rarely.
 When writing some code to set the cache under heavy stress I have the 
 reproducible result that two threads are hanging in the HasMap.get() method. 

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

Re: [VOTE] Release Tobago 1.0.30

2010-09-30 Thread Udo Schnurpfeil 

 Hi, all,

I've found a new critical bug: 
https://issues.apache.org/jira/browse/TOBAGO-921

I've fixed it, but it is not in 1.0.30. So we have two possibilities:

  1. put it in 1.0.30 and rebuild it or
  2. put it in 1.0.31 and release it asap.

Regards

Udo


Am 29.09.10 09:20, schrieb Bernd Bohmann:

Hello Volker,

TOBAGO-920 has the fixed version 1.0.30. I reasign the fixed version
to 1.0.30. Now the release notes includes TOBAGO-920. Maybe a jira
bug?

Regards

Bernd

On Wed, Sep 29, 2010 at 9:08 AM, Volker Weberv.we...@inexso.de  wrote:

Hi Bernd,

the release notes did not include TOBAGO-920 (The layout of the
TabGroup is broken if one Tab is rendered=false).

Wasn't this fixed before you tag this release?


Regards,
Volker

2010/9/28 Bernd Bohmannbernd.bohm...@atanion.com:

Hello,

I would like to release Tobago 1.0.30.

For a detail list please consult the release notes:

http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12315336

The version is available at the nexus staging repository.


Staging repository:

https://repository.apache.org/content/repositories/orgapachemyfaces-021/

The Vote is open for 72h.

[ ] +1
[ ] +0
[ ] -1

Regards

Bernd




--
inexso - information exchange solutions GmbH
Ofener Str. 30  | 26121 Oldenburg
Tel.: +49 441 219 730 56 |
FAX:  +49 441 219 730 66 | eMail: volker.we...@inexso.de

Firmensitz: Hamburg   | Amtsgericht Hamburg, HRB 84273
Geschäftsführer: Stefan Schulte, Michael Terschüren, Dirk Fangohr

[jira] Resolved: (TOBAGO-921) Unsynchronized access to the cache of ThemeConfig

2010-09-30 Thread Udo Schnurpfeil (JIRA) 

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

Udo Schnurpfeil resolved TOBAGO-921.


Resolution: Fixed

 Unsynchronized access to the cache of ThemeConfig
 -

 Key: TOBAGO-921
 URL: https://issues.apache.org/jira/browse/TOBAGO-921
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.29
 Environment: JVM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01-279, 
 mixed mode)
Reporter: Udo Schnurpfeil
Assignee: Udo Schnurpfeil
Priority: Critical

 The problem seems to occur rarely.
 When writing some code to set the cache under heavy stress I have the 
 reproducible result that two threads are hanging in the HasMap.get() method. 

-- 
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: (TOBAGO-921) Unsynchronized access to the cache of ThemeConfig

2010-09-30 Thread Udo Schnurpfeil (JIRA) 

[ 
https://issues.apache.org/jira/browse/TOBAGO-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12916440#action_12916440
 ] 

Udo Schnurpfeil edited comment on TOBAGO-921 at 9/30/10 10:07 AM:
--

Here is the code I call one time in each request in the tobago-example-demo 
application using mvn jetty:run-exploded

  private void stress() {
LOG.info(start test theme config -  + Thread.currentThread().getName());
FacesContext facesContext = FacesContext.getCurrentInstance();
UIComponent component = ComponentUtil.createComponent(
UILabel.COMPONENT_TYPE, TobagoConstants.RENDERER_TYPE_LABEL, dummy);
LayoutUtil.getInnerSpace(facesContext, component, 10, false);
for (int i = 0; i  100 ; i++) {
  try {
ThemeConfig.getValue(facesContext, component, fixedWidth);
ThemeConfig.getValue(facesContext, component, labelWidth);
ThemeConfig.getValue(facesContext, component, not-existing- + 
(int)(Math.random() * 100));
  } catch (Exception e) {
// ignore
  }
}
LOG.info(end   test theme config -  + Thread.currentThread().getName()
+  size= + ((Map) 
facesContext.getExternalContext().getApplicationMap().get(
org.apache.myfaces.tobago.config.ThemeConfig.CACHE)).size());
  }

I call the URL with wget in a loop in 2 command shells.

For this test the JVM needs at least 2 GB heap space.


  was (Author: lofwyr):
Here is the code I call one time in each request in the tobago-example-demo 
application using mvn jetty:run-exploded

  private void stress() {
LOG.info(start test theme config -  + Thread.currentThread().getName());
FacesContext facesContext = FacesContext.getCurrentInstance();
UIComponent component = ComponentUtil.createComponent(
UILabel.COMPONENT_TYPE, TobagoConstants.RENDERER_TYPE_LABEL, dummy);
LayoutUtil.getInnerSpace(facesContext, component, 10, false);
for (int i = 0; i  100 ; i++) {
  try {
ThemeConfig.getValue(facesContext, component, fixedWidth);
ThemeConfig.getValue(facesContext, component, labelWidth);
ThemeConfig.getValue(facesContext, component, not-existing- + 
(int)(Math.random() * 100));
  } catch (Exception e) {
// ignore
  }
}
LOG.info(end   test theme config -  + Thread.currentThread().getName()
+  size= + ((Map) 
facesContext.getExternalContext().getApplicationMap().get(
org.apache.myfaces.tobago.config.ThemeConfig.CACHE)).size());
  }

I call the URL with wget in a loop in 2 command shells.

  
 Unsynchronized access to the cache of ThemeConfig
 -

 Key: TOBAGO-921
 URL: https://issues.apache.org/jira/browse/TOBAGO-921
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.29
 Environment: JVM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01-279, 
 mixed mode)
Reporter: Udo Schnurpfeil
Assignee: Udo Schnurpfeil
Priority: Critical

 The problem seems to occur rarely.
 When writing some code to set the cache under heavy stress I have the 
 reproducible result that two threads are hanging in the HasMap.get() method. 

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

[jira] Commented: (MYFACES-2933) Our archetype poms are not entirely correctly understood by Netbeans

2010-09-30 Thread Leonardo Uribe (JIRA) 

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

Leonardo Uribe commented on MYFACES-2933:
-

Hi Werner

There is no problem. Personally I like to have something like this one:

http://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-helloworld/src/main/resources/archetype-resources/pom.xml

In this case we have jetty plugin registered on top:

build
finalName${artifactId}/finalName
plugins
plugin
!--This plugin allows to run the example using mvn jetty:run 
--
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId
version${symbol_dollar}{maven.jetty.plugin.version}/version
configuration
scanIntervalSeconds10/scanIntervalSeconds
/configuration
/plugin
/plugins
/build

And the additional profile jettyConfig:

profile
!-- Debug profile for myfaces and jetty.
It allows to see debug messages using -PjettyConfig --
idjettyConfig/id
build
resources
resource
directorysrc/main/resources/directory
/resource
resource
directorysrc/main/log4j/directory
/resource
/resources
plugins
plugin
!--This plugin allows to run the example using mvn 
jetty:run --
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId

version${symbol_dollar}{maven.jetty.plugin.version}/version
configuration
scanIntervalSeconds10/scanIntervalSeconds
systemProperties
systemProperty
nameorg.apache.commons.logging.Log/name

valueorg.apache.commons.logging.impl.Log4JLogger/value
/systemProperty
/systemProperties
/configuration
/plugin
/plugins
/build
dependencies
dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version${symbol_dollar}{log4j.version}/version
typejar/type
/dependency
/dependencies
/profile

To have jetty with additional information. The important is have a param to 
prevent mojarra and myfaces be on the classpath at the same time.

 Our archetype poms are not entirely correctly understood by Netbeans
 

 Key: MYFACES-2933
 URL: https://issues.apache.org/jira/browse/MYFACES-2933
 Project: MyFaces Core
  Issue Type: Bug
  Components: Archetype
Affects Versions: 2.0.2
 Environment: all
Reporter: Werner Punz

 We have a small structural problem in the myfaces archetypes. This is not a 
 bug in our code, but nevertheless easily fixable. The problem is the way we 
 handle the profiles which is not correctly understood by Netbeans 6.9.
 We have following code:
 profiles
 profile
 idmyfaces/id
 activation
 property
 name!jsf/name
 /property
 /activation
 and
  profile
 !-- Activate by adding -Djsf=mojarra --
 idmojarra/id
 activation
 property
 namejsf/name
 valuemojarra/value
 /property
 /activation
 No this structure just should ensure that if no jsf=... is set myfaces is 
 chosen automatically. This makes netbeans go haiwire if you chosse mojarra as 
 profile because suddenly we have the mojarra and myfaces dependencies 
 parallely in the project.
 Since this structure is mostly a hack we should replace it with the correct 
 way to do things here:
 activation
 activeByDefaulttrue/activeByDefault
 property
 namejsf/name
 valuemyfaces/value
 /property
 /activation
 instead of !jsf so if no value is given we activate the myfaces profile by 
 default

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

[jira] Commented: (MYFACES-2933) Our archetype poms are not entirely correctly understood by Netbeans

2010-09-30 Thread Jakob Korherr (JIRA) 

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

Jakob Korherr commented on MYFACES-2933:


IMO this is a NetBeans bug and we don't really have to fix it. We've used this 
configuration for a long time now and there were never any problems..

 Our archetype poms are not entirely correctly understood by Netbeans
 

 Key: MYFACES-2933
 URL: https://issues.apache.org/jira/browse/MYFACES-2933
 Project: MyFaces Core
  Issue Type: Bug
  Components: Archetype
Affects Versions: 2.0.2
 Environment: all
Reporter: Werner Punz

 We have a small structural problem in the myfaces archetypes. This is not a 
 bug in our code, but nevertheless easily fixable. The problem is the way we 
 handle the profiles which is not correctly understood by Netbeans 6.9.
 We have following code:
 profiles
 profile
 idmyfaces/id
 activation
 property
 name!jsf/name
 /property
 /activation
 and
  profile
 !-- Activate by adding -Djsf=mojarra --
 idmojarra/id
 activation
 property
 namejsf/name
 valuemojarra/value
 /property
 /activation
 No this structure just should ensure that if no jsf=... is set myfaces is 
 chosen automatically. This makes netbeans go haiwire if you chosse mojarra as 
 profile because suddenly we have the mojarra and myfaces dependencies 
 parallely in the project.
 Since this structure is mostly a hack we should replace it with the correct 
 way to do things here:
 activation
 activeByDefaulttrue/activeByDefault
 property
 namejsf/name
 valuemyfaces/value
 /property
 /activation
 instead of !jsf so if no value is given we activate the myfaces profile by 
 default

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

Re: [VOTE] release for myfaces tomahawk v 1.1.10

2010-09-30 Thread Werner Punz 

+1

Am 28.09.10 02:42, schrieb Leonardo Uribe:

Hi,

I was running the needed tasks to get the 1.1.10 release of Apache
MyFaces Tomahawk out.

Release notes can be found at [4].

Please note that this vote concerns all of the following parts:
  1. Maven artifact group org.apache.myfaces.tomahawk v1.1.10 [1]

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

There is also binary and source packages available on [2]

Please take a look at the 1.1.10 artifacts and vote!

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


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


Thanks,
Leonardo Uribe

[1]
http://repository.apache.org/content/repositories/orgapachemyfaces-017/org/apache/myfaces/tomahawk
[2] http://people.apache.org/~lu4242/tomahawk1110binsrc
[3] http://www.apache.org/foundation/voting.html#ReleaseVotes
[4]
http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310272styleName=Htmlversion=12315371
http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310272styleName=Htmlversion=12315371

[jira] Created: (TRINIDAD-1932) Changes to UIXIterator break full visiting

2010-09-30 Thread Andrew Robinson (JIRA) 
Changes to UIXIterator break full visiting
--

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


UIXIterator was changed to check the getSubtreeIdsToVisit, but the code does 
not handle the ALL_IDS use case. As a result, any page with a component of 
UIXIterator or any subclass will throw errors if someone attempts to use a full 
tree visit.

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

[jira] Created: (MYFACES-2934) Side-channel timing attack in StateUtils class may still allow padding oracle attack

2010-09-30 Thread Kevin W. Wall (JIRA) 
Side-channel timing attack in StateUtils class may still allow padding oracle 
attack


 Key: MYFACES-2934
 URL: https://issues.apache.org/jira/browse/MYFACES-2934
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 1.2.9
 Environment: All using MyFaces 1.2.9
Reporter: Kevin W. Wall


[FYI: I'm the person who fixed the padding oracle attack in ESAPI 2.0-rc# 
crypto which is why I spotted this.]

I did a quick code inspection of encrypt() / decrypt() methods in 
org.apache.myfaces.shared_impl.util.StateUtils as it relates to the fix for 
MYFACES-2749.  Most everything is done correct (MAC is over IV+ciphertext and 
checked before decryption), but I noticed a subtle flaw that, at least in 
theory (or enough data gathering and statistical analysis), that opens a 
side-channel timing attack that might be still be used as a oracle in a padded 
oracle attack such as described by Duong and Rizzo.

The problem is in the 'for' loop at lines 471-478 in StateUtils.java. You need 
to compare ALWAYS compare ALL the bytes in the MAC to ensure a timing 
side-channel attack cannot be used to as an oracle in the padding oracle attack.

Contact me at kevin.w.w...@gmail.com if you need more info or want to see how 
it was fixed in OWASP ESAPI.

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

[jira] Commented: (MYFACES-2934) Side-channel timing attack in StateUtils class may still allow padding oracle attack

2010-09-30 Thread Leonardo Uribe (JIRA) 

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

Leonardo Uribe commented on MYFACES-2934:
-

I have checked it and well, the probability to be succesful using that type of 
attack is very, very, very, very, very low, because the comparison done in this 
case takes very few time compared with other tasks done by myfaces itself on a 
single request.

Anyway, I would like to know how to fix it, maybe replace the line break with 
continue should do the job. If that so, I can commit the code on all myfaces 
branches.


 Side-channel timing attack in StateUtils class may still allow padding oracle 
 attack
 

 Key: MYFACES-2934
 URL: https://issues.apache.org/jira/browse/MYFACES-2934
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 1.2.9
 Environment: All using MyFaces 1.2.9
Reporter: Kevin W. Wall
   Original Estimate: 48h
  Remaining Estimate: 48h

 [FYI: I'm the person who fixed the padding oracle attack in ESAPI 2.0-rc# 
 crypto which is why I spotted this.]
 I did a quick code inspection of encrypt() / decrypt() methods in 
 org.apache.myfaces.shared_impl.util.StateUtils as it relates to the fix for 
 MYFACES-2749.  Most everything is done correct (MAC is over IV+ciphertext and 
 checked before decryption), but I noticed a subtle flaw that, at least in 
 theory (or enough data gathering and statistical analysis), that opens a 
 side-channel timing attack that might be still be used as a oracle in a 
 padded oracle attack such as described by Duong and Rizzo.
 The problem is in the 'for' loop at lines 471-478 in StateUtils.java. You 
 need to compare ALWAYS compare ALL the bytes in the MAC to ensure a timing 
 side-channel attack cannot be used to as an oracle in the padding oracle 
 attack.
 Contact me at kevin.w.w...@gmail.com if you need more info or want to see how 
 it was fixed in OWASP ESAPI.

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

[jira] Commented: (TRINIDAD-1930) Ability to easily create a meta tag

2010-09-30 Thread Andrew Robinson (JIRA) 

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

Andrew Robinson commented on TRINIDAD-1930:
---

Do we need the more verbose nameType or would type be sufficient?

 Ability to easily create a meta tag
 ---

 Key: TRINIDAD-1930
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1930
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 1.2.14-core ,  2.0.0.2-core 
Reporter: Matt Cooper
Assignee: Matt Cooper

 Ability to easily create a meta tag (e.g. 
 http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safarihtmlref/articles/MetaTags.html
  or http://www.webmarketingnow.com/tips/meta-tags-uncovered.html ) via a new 
 trh:meta tag.
 Currently it is quite tedious to create a meta tag out of a component:
 tr:document ...
   f:facet name=metaContainer
 tr:group id=metaContainer
   tr:outputText escape=false
  value='lt;meta name=viewport 
 content=width=device-width'
  id=metaTag1/
   tr:outputText escape=false
  value='lt;meta name=apple-mobile-web-app-capable 
 content=yes'
  id=metaTag2/
   tr:outputText escape=false
  value='lt;meta http-equiv=refresh 
 content=2;url=./test/index.jspx'
  id=metaTag3/
 /tr:group
   /f:facet
 /tr:document
 It would be much better if we had a trh:meta component that looked like this:
 tr:document ...
   f:facet name=metaContainer
 tr:group id=metaContainer
   trh:meta name=viewport content=width=device-width/
   trh:meta name=apple-mobile-web-app-capable content=yes/
   trh:meta name=refresh nameType=http-equiv 
 content=2;url=./test/index.jspx/
 /tr:group
   /f:facet
 /tr:document
 So I would like to see a new trh:meta component that has an API like this:
 Tag name: trh:meta
 UIComponent class: org.apache.myfaces.trinidad.component.core.CoreMeta
 Component type: org.apache.myfaces.trinidad.CoreMeta
 The meta component generates an HTML meta tag and is intended to be used 
 inside either the trh:head tag or the document component's metaContainer 
 facet.
 Events
 Type  Phases  Description
 org.apache.myfaces.trinidad.event.AttributeChangeEventInvoke 
 Application, Apply Request ValuesEvent delivered to describe an 
 attribute change. Attribute change events are not delivered for any 
 programmatic change to a property. They are only delivered when a renderer 
 changes a property without the application's specific request. An example of 
 an attribute change events might include the width of a column that supported 
 client-side resizing.
 Attributes
 Name  TypeSupports EL?Description
 attributeChangeListener   javax.el.MethodExpression   Only EL 
 a method reference to an attribute change listener. Attribute change events 
 are not delivered for any programmatic change to a property. They are only 
 delivered when a renderer changes a property without the application's 
 specific request. An example of an attribute change events might include the 
 width of a column that supported client-side resizing.
 binding   org.apache.myfaces.trinidad.component.core.CoreMeta Only EL 
 an EL reference that will store the component instance on a bean. 
 This can be used to give programmatic access to a component from a backing 
 bean, or to move creation of the component to a backing bean.
 idString  No  the identifier for the component. The identifier must 
 follow a subset of the syntax allowed in HTML:
 * Must not be a zero-length String.
 * First character must be an ASCII letter (A-Za-z) or an underscore ('_').
 * Subsequent characters must be an ASCII letter or digit (A-Za-z0-9), an 
 underscore ('_'), or a dash ('-').
 rendered  boolean Yes whether the component is rendered. When 
 set to false, no output will be delivered for this component (the component 
 will not in any way be rendered, and cannot be made visible on the client).
 name  String  Yes the name or http-equiv attribute of the meta attribute 
 (see nameType)
 nameType  String  Yes name or http-equiv indicating which kind of 
 name attribute is desired (name is the most common attribute but some older 
 meta tags need http-equiv)
 content   String  Yes the content of the meta attribute 

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

RE: [jira] Commented: (MYFACES-2934) Side-channel timing attack in StateUtils class may still allow padding oracle attack

2010-09-30 Thread Wall, Kevin 
Changing from 'break;' to 'continue;' is the most straightforward
fix, but I'd recommend adding a comment as to WHY you are doing
this, so that later on, someone doesn't come back to optimize
the code and change it back to 'break'. I'd just put something like
this at the beginning of the 'for' loop:

// Must compare *ALL* bytes of the hash, otherwise a
// side-channel timing attack is possible.

And I agree, very low probability, although this sort of thing is
not unheard of. It just takes a monstrous # of requests (sometimes
millions) to get a good statistical average to distinguish things
at the microsec range. But if it's this easy to fix, why not???

-kevin
---
Kevin W. Wall   Qwest Information Technology, Inc.
kevin.w...@qwest.comPhone: 614.215.4788
It is practically impossible to teach good programming to students
 that have had a prior exposure to BASIC: as potential programmers
 they are mentally mutilated beyond hope of regeneration
- Edsger Dijkstra, How do we tell truths that matter?
  http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html

 -Original Message-
 From: Leonardo Uribe (JIRA) [mailto:d...@myfaces.apache.org]
 Sent: Thursday, September 30, 2010 2:30 PM
 To: kww...@acm.org
 Subject: [jira] Commented: (MYFACES-2934) Side-channel timing attack in
 StateUtils class may still allow padding oracle attack


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

 Leonardo Uribe commented on MYFACES-2934:
 -

 I have checked it and well, the probability to be succesful using that type
 of attack is very, very, very, very, very low, because the comparison done
 in this case takes very few time compared with other tasks done by myfaces
 itself on a single request.

 Anyway, I would like to know how to fix it, maybe replace the line break
 with continue should do the job. If that so, I can commit the code on all
 myfaces branches.


  Side-channel timing attack in StateUtils class may still allow padding
 oracle attack
  -
 ---
 
  Key: MYFACES-2934
  URL: https://issues.apache.org/jira/browse/MYFACES-2934
  Project: MyFaces Core
   Issue Type: Bug
 Affects Versions: 1.2.9
  Environment: All using MyFaces 1.2.9
 Reporter: Kevin W. Wall
Original Estimate: 48h
   Remaining Estimate: 48h
 
  [FYI: I'm the person who fixed the padding oracle attack in ESAPI 2.0-rc#
 crypto which is why I spotted this.]
  I did a quick code inspection of encrypt() / decrypt() methods in
 org.apache.myfaces.shared_impl.util.StateUtils as it relates to the fix for
 MYFACES-2749.  Most everything is done correct (MAC is over IV+ciphertext
 and checked before decryption), but I noticed a subtle flaw that, at least
 in theory (or enough data gathering and statistical analysis), that opens a
 side-channel timing attack that might be still be used as a oracle in a
 padded oracle attack such as described by Duong and Rizzo.
  The problem is in the 'for' loop at lines 471-478 in StateUtils.java. You
 need to compare ALWAYS compare ALL the bytes in the MAC to ensure a timing
 side-channel attack cannot be used to as an oracle in the padding oracle
 attack.
  Contact me at kevin.w.w...@gmail.com if you need more info or want to see
 how it was fixed in OWASP ESAPI.

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


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

[jira] Commented: (TRINIDAD-1930) Ability to easily create a meta tag

2010-09-30 Thread Matt Cooper (JIRA) 

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

Matt Cooper commented on TRINIDAD-1930:
---

+1; type instead of nameType works for me.

 Ability to easily create a meta tag
 ---

 Key: TRINIDAD-1930
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1930
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 1.2.14-core ,  2.0.0.2-core 
Reporter: Matt Cooper
Assignee: Matt Cooper

 Ability to easily create a meta tag (e.g. 
 http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safarihtmlref/articles/MetaTags.html
  or http://www.webmarketingnow.com/tips/meta-tags-uncovered.html ) via a new 
 trh:meta tag.
 Currently it is quite tedious to create a meta tag out of a component:
 tr:document ...
   f:facet name=metaContainer
 tr:group id=metaContainer
   tr:outputText escape=false
  value='lt;meta name=viewport 
 content=width=device-width'
  id=metaTag1/
   tr:outputText escape=false
  value='lt;meta name=apple-mobile-web-app-capable 
 content=yes'
  id=metaTag2/
   tr:outputText escape=false
  value='lt;meta http-equiv=refresh 
 content=2;url=./test/index.jspx'
  id=metaTag3/
 /tr:group
   /f:facet
 /tr:document
 It would be much better if we had a trh:meta component that looked like this:
 tr:document ...
   f:facet name=metaContainer
 tr:group id=metaContainer
   trh:meta name=viewport content=width=device-width/
   trh:meta name=apple-mobile-web-app-capable content=yes/
   trh:meta name=refresh nameType=http-equiv 
 content=2;url=./test/index.jspx/
 /tr:group
   /f:facet
 /tr:document
 So I would like to see a new trh:meta component that has an API like this:
 Tag name: trh:meta
 UIComponent class: org.apache.myfaces.trinidad.component.core.CoreMeta
 Component type: org.apache.myfaces.trinidad.CoreMeta
 The meta component generates an HTML meta tag and is intended to be used 
 inside either the trh:head tag or the document component's metaContainer 
 facet.
 Events
 Type  Phases  Description
 org.apache.myfaces.trinidad.event.AttributeChangeEventInvoke 
 Application, Apply Request ValuesEvent delivered to describe an 
 attribute change. Attribute change events are not delivered for any 
 programmatic change to a property. They are only delivered when a renderer 
 changes a property without the application's specific request. An example of 
 an attribute change events might include the width of a column that supported 
 client-side resizing.
 Attributes
 Name  TypeSupports EL?Description
 attributeChangeListener   javax.el.MethodExpression   Only EL 
 a method reference to an attribute change listener. Attribute change events 
 are not delivered for any programmatic change to a property. They are only 
 delivered when a renderer changes a property without the application's 
 specific request. An example of an attribute change events might include the 
 width of a column that supported client-side resizing.
 binding   org.apache.myfaces.trinidad.component.core.CoreMeta Only EL 
 an EL reference that will store the component instance on a bean. 
 This can be used to give programmatic access to a component from a backing 
 bean, or to move creation of the component to a backing bean.
 idString  No  the identifier for the component. The identifier must 
 follow a subset of the syntax allowed in HTML:
 * Must not be a zero-length String.
 * First character must be an ASCII letter (A-Za-z) or an underscore ('_').
 * Subsequent characters must be an ASCII letter or digit (A-Za-z0-9), an 
 underscore ('_'), or a dash ('-').
 rendered  boolean Yes whether the component is rendered. When 
 set to false, no output will be delivered for this component (the component 
 will not in any way be rendered, and cannot be made visible on the client).
 name  String  Yes the name or http-equiv attribute of the meta attribute 
 (see nameType)
 nameType  String  Yes name or http-equiv indicating which kind of 
 name attribute is desired (name is the most common attribute but some older 
 meta tags need http-equiv)
 content   String  Yes the content of the meta attribute 

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

Re: Myfaces vs. mojarra restore view performance

2010-09-30 Thread Martin Koci 
Hi,

Leonardo, can you please review :
https://issues.apache.org/jira/browse/MYFACES-2922
https://issues.apache.org/jira/browse/MYFACES-2862

and apply them if they are suitable?


Thanks,

Kočičák

Martin Koci píše v Út 14. 09. 2010 v 23:05 +0200:
 Hi,
 
 
 please review https://issues.apache.org/jira/browse/MYFACES-2922 and
 apply if possible.
 
 Thanks,
 
 Kočičák
 
 
 Leonardo Uribe píše v Pá 06. 08. 2010 v 13:07 -0500:
  Hi
  
  2010/8/6 Martin Koci martin.k...@aura.cz
  Hi,
  
  
  is it possible to cache inspected classes in
  RequestViewContext? I did
  something like that:
  
  if (isProduction  !
  requestViewContext.isAlreadyInspected(inspectedClass)) {
  
 _handleListenerForAnnotations(context, inspected,
  inspectedClass, component, isProduction);
  
 _handleResourceDependencyAnnotations(context,
  inspectedClass, component, isProduction);
  
 requestViewContext.setAsProcessed(inspectedClass);
 }
  
  in _handleAnnotations and it reduces restore view time to
  30-40 ms.
  
  
  It is necessary to apply @ListenerFor annotations on every component
  that has registered
  it in the view. The reason why we can cache @ResourceDependency is
  this annotation
  cause a component resource to be added, and that one will be always
  the same.
  
   regards,
  
  Leonardo
   
  
  regards,
  
  Martin Kočí
  
  Leonardo Uribe píše v Čt 05. 08. 2010 v 15:56 -0500:
  
   Hi
  
   Ok, good to know that. I closed MYFACES-2854. Maybe on
  MYFACES-2862 we
   can use FacesContext.isProjectStage(ProjectStage).
  
   regards,
  
   Leonardo
  
   2010/8/5 Martin Koci martin.k...@aura.cz
   Hi,
  
   success!
  
   myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70
  ms in
   restore view
   phase. It was *750 ms* before.
  
   Thanks,
  
   Martin Kočí
  
   Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
  
Hi
   
I implemented a proposal for this one on
   MYFACES-2854-2.patch using
the suggestion
proposed (do not apply ResourceDependency if it
  was already
processed). I hope that
patch solve the problem.
   
regards,
   
Leonardo

RE: [jira] Commented: (MYFACES-2934) Side-channel timing attack in StateUtils class may still allow padding oracle attack

2010-09-30 Thread Wall, Kevin 
BTW, if you want, feel free to bump this down in priority.
I had no idea of what criteria you use in determining them,
so I just left it at its default, which I think was 'Major'.
Also, I figured 2d was max time, including testing, re-packaging,
etc. since fix was so easy. Maybe I should have mentioned it,
but I didn't want to tell people how to do their jobs and figured
the MyFaces team would see how easy it was on their own.

-kevin
---
Kevin W. Wall   Qwest Information Technology, Inc.
kevin.w...@qwest.comPhone: 614.215.4788
It is practically impossible to teach good programming to students
 that have had a prior exposure to BASIC: as potential programmers
 they are mentally mutilated beyond hope of regeneration
- Edsger Dijkstra, How do we tell truths that matter?
  http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html

 -Original Message-
 From: Leonardo Uribe (JIRA) [mailto:d...@myfaces.apache.org]
 Sent: Thursday, September 30, 2010 2:30 PM
 To: kww...@acm.org
 Subject: [jira] Commented: (MYFACES-2934) Side-channel timing attack in
 StateUtils class may still allow padding oracle attack


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

 Leonardo Uribe commented on MYFACES-2934:
 -

 I have checked it and well, the probability to be succesful using that type
 of attack is very, very, very, very, very low, because the comparison done
 in this case takes very few time compared with other tasks done by myfaces
 itself on a single request.

 Anyway, I would like to know how to fix it, maybe replace the line break
 with continue should do the job. If that so, I can commit the code on all
 myfaces branches.


  Side-channel timing attack in StateUtils class may still allow padding
 oracle attack
  -
 ---
 
  Key: MYFACES-2934
  URL: https://issues.apache.org/jira/browse/MYFACES-2934
  Project: MyFaces Core
   Issue Type: Bug
 Affects Versions: 1.2.9
  Environment: All using MyFaces 1.2.9
 Reporter: Kevin W. Wall
Original Estimate: 48h
   Remaining Estimate: 48h
 
  [FYI: I'm the person who fixed the padding oracle attack in ESAPI 2.0-rc#
 crypto which is why I spotted this.]
  I did a quick code inspection of encrypt() / decrypt() methods in
 org.apache.myfaces.shared_impl.util.StateUtils as it relates to the fix for
 MYFACES-2749.  Most everything is done correct (MAC is over IV+ciphertext
 and checked before decryption), but I noticed a subtle flaw that, at least
 in theory (or enough data gathering and statistical analysis), that opens a
 side-channel timing attack that might be still be used as a oracle in a
 padded oracle attack such as described by Duong and Rizzo.
  The problem is in the 'for' loop at lines 471-478 in StateUtils.java. You
 need to compare ALWAYS compare ALL the bytes in the MAC to ensure a timing
 side-channel attack cannot be used to as an oracle in the padding oracle
 attack.
  Contact me at kevin.w.w...@gmail.com if you need more info or want to see
 how it was fixed in OWASP ESAPI.

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


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

Re: [jira] Commented: (MYFACES-2934) Side-channel timing attack in StateUtils class may still allow padding oracle attack

2010-09-30 Thread Leonardo Uribe 
Hi

Ok. I'll lower the priority. I don't think a release is necessary for this
one, so I'll just fix it on trunk. Thanks for your help.

regards,

Leonardo

2010/9/30 Wall, Kevin kevin.w...@qwest.com

 BTW, if you want, feel free to bump this down in priority.
 I had no idea of what criteria you use in determining them,
 so I just left it at its default, which I think was 'Major'.
 Also, I figured 2d was max time, including testing, re-packaging,
 etc. since fix was so easy. Maybe I should have mentioned it,
 but I didn't want to tell people how to do their jobs and figured
 the MyFaces team would see how easy it was on their own.

 -kevin
 ---
 Kevin W. Wall   Qwest Information Technology, Inc.
 kevin.w...@qwest.comPhone: 614.215.4788
 It is practically impossible to teach good programming to students
  that have had a prior exposure to BASIC: as potential programmers
  they are mentally mutilated beyond hope of regeneration
- Edsger Dijkstra, How do we tell truths that matter?
  
 http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.htmlhttp://www.cs.utexas.edu/%7EEWD/transcriptions/EWD04xx/EWD498.html

  -Original Message-
  From: Leonardo Uribe (JIRA) [mailto:d...@myfaces.apache.org]
  Sent: Thursday, September 30, 2010 2:30 PM
  To: kww...@acm.org
  Subject: [jira] Commented: (MYFACES-2934) Side-channel timing attack in
  StateUtils class may still allow padding oracle attack
 
 
  [ https://issues.apache.org/jira/browse/MYFACES-
  2934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
  tabpanelfocusedCommentId=12916595#action_12916595 ]
 
  Leonardo Uribe commented on MYFACES-2934:
  -
 
  I have checked it and well, the probability to be succesful using that
 type
  of attack is very, very, very, very, very low, because the comparison
 done
  in this case takes very few time compared with other tasks done by
 myfaces
  itself on a single request.
 
  Anyway, I would like to know how to fix it, maybe replace the line
 break
  with continue should do the job. If that so, I can commit the code on
 all
  myfaces branches.
 
 
   Side-channel timing attack in StateUtils class may still allow padding
  oracle attack
  
 -
  ---
  
   Key: MYFACES-2934
   URL:
 https://issues.apache.org/jira/browse/MYFACES-2934
   Project: MyFaces Core
Issue Type: Bug
  Affects Versions: 1.2.9
   Environment: All using MyFaces 1.2.9
  Reporter: Kevin W. Wall
 Original Estimate: 48h
Remaining Estimate: 48h
  
   [FYI: I'm the person who fixed the padding oracle attack in ESAPI
 2.0-rc#
  crypto which is why I spotted this.]
   I did a quick code inspection of encrypt() / decrypt() methods in
  org.apache.myfaces.shared_impl.util.StateUtils as it relates to the fix
 for
  MYFACES-2749.  Most everything is done correct (MAC is over IV+ciphertext
  and checked before decryption), but I noticed a subtle flaw that, at
 least
  in theory (or enough data gathering and statistical analysis), that opens
 a
  side-channel timing attack that might be still be used as a oracle in a
  padded oracle attack such as described by Duong and Rizzo.
   The problem is in the 'for' loop at lines 471-478 in StateUtils.java.
 You
  need to compare ALWAYS compare ALL the bytes in the MAC to ensure a
 timing
  side-channel attack cannot be used to as an oracle in the padding oracle
  attack.
   Contact me at kevin.w.w...@gmail.com if you need more info or want to
 see
  how it was fixed in OWASP ESAPI.
 
  --
  This message is automatically generated by JIRA.
  -
  You can reply to this email to add a comment to the issue online.


 This communication is the property of Qwest and may contain confidential or
 privileged information. Unauthorized use of this communication is strictly
 prohibited and may be unlawful.  If you have received this communication
 in error, please immediately notify the sender by reply e-mail and destroy
 all copies of the communication and any attachments.

Re: Myfaces vs. mojarra restore view performance

2010-09-30 Thread Leonardo Uribe 
Hi

Yes, sure!. Give me some time, right now I'm doing some stuff related to
@ListenerFor annotation, so as soon as I'm done I'll take a look.

regards,

Leonardo

2010/9/30 Martin Koci martin.kocicak.k...@gmail.com

 Hi,

 Leonardo, can you please review :
 https://issues.apache.org/jira/browse/MYFACES-2922
 https://issues.apache.org/jira/browse/MYFACES-2862

 and apply them if they are suitable?


 Thanks,

 Kočičák

 Martin Koci píše v Út 14. 09. 2010 v 23:05 +0200:
  Hi,
 
 
  please review https://issues.apache.org/jira/browse/MYFACES-2922 and
  apply if possible.
 
  Thanks,
 
  Kočičák
 
 
  Leonardo Uribe píše v Pá 06. 08. 2010 v 13:07 -0500:
   Hi
  
   2010/8/6 Martin Koci martin.k...@aura.cz
   Hi,
  
  
   is it possible to cache inspected classes in
   RequestViewContext? I did
   something like that:
  
   if (isProduction  !
   requestViewContext.isAlreadyInspected(inspectedClass)) {
  
  _handleListenerForAnnotations(context, inspected,
   inspectedClass, component, isProduction);
  
  _handleResourceDependencyAnnotations(context,
   inspectedClass, component, isProduction);
  
  requestViewContext.setAsProcessed(inspectedClass);
  }
  
   in _handleAnnotations and it reduces restore view time to
   30-40 ms.
  
  
   It is necessary to apply @ListenerFor annotations on every component
   that has registered
   it in the view. The reason why we can cache @ResourceDependency is
   this annotation
   cause a component resource to be added, and that one will be always
   the same.
  
regards,
  
   Leonardo
  
  
   regards,
  
   Martin Kočí
  
   Leonardo Uribe píše v Čt 05. 08. 2010 v 15:56 -0500:
  
Hi
   
Ok, good to know that. I closed MYFACES-2854. Maybe on
   MYFACES-2862 we
can use FacesContext.isProjectStage(ProjectStage).
   
regards,
   
Leonardo
   
2010/8/5 Martin Koci martin.k...@aura.cz
Hi,
   
success!
   
myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70
   ms in
restore view
phase. It was *750 ms* before.
   
Thanks,
   
Martin Kočí
   
Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
   
 Hi

 I implemented a proposal for this one on
MYFACES-2854-2.patch using
 the suggestion
 proposed (do not apply ResourceDependency if it
   was already
 processed). I hope that
 patch solve the problem.

 regards,

 Leonardo

Re: Myfaces vs. mojarra restore view performance

2010-09-30 Thread Matthias Wessendorf 
MArtin,

your account is now setup - you even could apply them yourself,
after Leo did a successful review

-;M

On Thu, Sep 30, 2010 at 1:14 PM, Martin Koci
martin.kocicak.k...@gmail.com wrote:
 Hi,

 Leonardo, can you please review :
 https://issues.apache.org/jira/browse/MYFACES-2922
 https://issues.apache.org/jira/browse/MYFACES-2862

 and apply them if they are suitable?


 Thanks,

 Kočičák

 Martin Koci píše v Út 14. 09. 2010 v 23:05 +0200:
 Hi,


 please review https://issues.apache.org/jira/browse/MYFACES-2922 and
 apply if possible.

 Thanks,

 Kočičák


 Leonardo Uribe píše v Pá 06. 08. 2010 v 13:07 -0500:
  Hi
 
  2010/8/6 Martin Koci martin.k...@aura.cz
          Hi,
 
 
          is it possible to cache inspected classes in
          RequestViewContext? I did
          something like that:
 
          if (isProduction  !
          requestViewContext.isAlreadyInspected(inspectedClass)) {
 
                     _handleListenerForAnnotations(context, inspected,
          inspectedClass, component, isProduction);
 
                     _handleResourceDependencyAnnotations(context,
          inspectedClass, component, isProduction);
 
                     requestViewContext.setAsProcessed(inspectedClass);
                 }
 
          in _handleAnnotations and it reduces restore view time to
          30-40 ms.
 
 
  It is necessary to apply @ListenerFor annotations on every component
  that has registered
  it in the view. The reason why we can cache @ResourceDependency is
  this annotation
  cause a component resource to be added, and that one will be always
  the same.
 
   regards,
 
  Leonardo
 
 
          regards,
 
          Martin Kočí
 
          Leonardo Uribe píše v Čt 05. 08. 2010 v 15:56 -0500:
 
           Hi
          
           Ok, good to know that. I closed MYFACES-2854. Maybe on
          MYFACES-2862 we
           can use FacesContext.isProjectStage(ProjectStage).
          
           regards,
          
           Leonardo
          
           2010/8/5 Martin Koci martin.k...@aura.cz
                   Hi,
          
                   success!
          
                   myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70
          ms in
                   restore view
                   phase. It was *750 ms* before.
          
                   Thanks,
          
                   Martin Kočí
          
                   Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
          
                    Hi
                   
                    I implemented a proposal for this one on
                   MYFACES-2854-2.patch using
                    the suggestion
                    proposed (do not apply ResourceDependency if it
          was already
                    processed). I hope that
                    patch solve the problem.
                   
                    regards,
                   
                    Leonardo
                   
          
          
          
          
 
 
 
 








-- 
Matthias Wessendorf

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

[core] FacesEL vs. UEL vs. UEL 2.2

2010-09-30 Thread Martin Koci 
Hi, 


there is a disorder in Expression Lauguage names in myfaces core.
Currently myfaces (method
javax.faces.validator._ExternalSpecifications.isUnifiedELAvailable() for
example) output a log:

MyFaces Unified EL support enabled

But this is a little misleading: there should be Unified EL 2.2 support
enabled because it tests presence of EL 2.2. Unified EL support
enabled does not make sence at all because JSF use Unified EL as core
technology and that cannot be disabled.


There are three major versions of ELs:

1) javax.faces.el - old and depreceated

2) javax.el 2.0, 2.1 (from JSP 2.0, 2.1) 

3) javax.el 2.2 from JSP 2.2, part of Java EE 6, EL with method
invocations


Suggestions:
Rename isUnifiedELAvailable to isUnifiedEL22Available,
TagValueExpressionUEL to TagValueExpressionUEL22 and so on.
For EL 2.3 (not released yet) we can add similar methods/classes.

Change log to MyFaces Unified EL 2.2 support enabled (method
invocations are available). 

I'll add similiar log MyFaces Faces EL (javax.faces.el) support
disabled  as part of disabling old technologies

WDYT ?


Kočičák

[jira] Commented: (TRINIDAD-1930) Ability to easily create a meta tag

2010-09-30 Thread Matt Cooper (JIRA) 

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

Matt Cooper commented on TRINIDAD-1930:
---

Other changes for consistency with other components in the trh namespace:

UIComponent class: org.apache.myfaces.trinidad.component.html.HtmlMeta
Component type: org.apache.myfaces.trinidad.HtmlMeta

 Ability to easily create a meta tag
 ---

 Key: TRINIDAD-1930
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1930
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 1.2.14-core ,  2.0.0.2-core 
Reporter: Matt Cooper
Assignee: Matt Cooper

 Ability to easily create a meta tag (e.g. 
 http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safarihtmlref/articles/MetaTags.html
  or http://www.webmarketingnow.com/tips/meta-tags-uncovered.html ) via a new 
 trh:meta tag.
 Currently it is quite tedious to create a meta tag out of a component:
 tr:document ...
   f:facet name=metaContainer
 tr:group id=metaContainer
   tr:outputText escape=false
  value='lt;meta name=viewport 
 content=width=device-width'
  id=metaTag1/
   tr:outputText escape=false
  value='lt;meta name=apple-mobile-web-app-capable 
 content=yes'
  id=metaTag2/
   tr:outputText escape=false
  value='lt;meta http-equiv=refresh 
 content=2;url=./test/index.jspx'
  id=metaTag3/
 /tr:group
   /f:facet
 /tr:document
 It would be much better if we had a trh:meta component that looked like this:
 tr:document ...
   f:facet name=metaContainer
 tr:group id=metaContainer
   trh:meta name=viewport content=width=device-width/
   trh:meta name=apple-mobile-web-app-capable content=yes/
   trh:meta name=refresh nameType=http-equiv 
 content=2;url=./test/index.jspx/
 /tr:group
   /f:facet
 /tr:document
 So I would like to see a new trh:meta component that has an API like this:
 Tag name: trh:meta
 UIComponent class: org.apache.myfaces.trinidad.component.core.CoreMeta
 Component type: org.apache.myfaces.trinidad.CoreMeta
 The meta component generates an HTML meta tag and is intended to be used 
 inside either the trh:head tag or the document component's metaContainer 
 facet.
 Events
 Type  Phases  Description
 org.apache.myfaces.trinidad.event.AttributeChangeEventInvoke 
 Application, Apply Request ValuesEvent delivered to describe an 
 attribute change. Attribute change events are not delivered for any 
 programmatic change to a property. They are only delivered when a renderer 
 changes a property without the application's specific request. An example of 
 an attribute change events might include the width of a column that supported 
 client-side resizing.
 Attributes
 Name  TypeSupports EL?Description
 attributeChangeListener   javax.el.MethodExpression   Only EL 
 a method reference to an attribute change listener. Attribute change events 
 are not delivered for any programmatic change to a property. They are only 
 delivered when a renderer changes a property without the application's 
 specific request. An example of an attribute change events might include the 
 width of a column that supported client-side resizing.
 binding   org.apache.myfaces.trinidad.component.core.CoreMeta Only EL 
 an EL reference that will store the component instance on a bean. 
 This can be used to give programmatic access to a component from a backing 
 bean, or to move creation of the component to a backing bean.
 idString  No  the identifier for the component. The identifier must 
 follow a subset of the syntax allowed in HTML:
 * Must not be a zero-length String.
 * First character must be an ASCII letter (A-Za-z) or an underscore ('_').
 * Subsequent characters must be an ASCII letter or digit (A-Za-z0-9), an 
 underscore ('_'), or a dash ('-').
 rendered  boolean Yes whether the component is rendered. When 
 set to false, no output will be delivered for this component (the component 
 will not in any way be rendered, and cannot be made visible on the client).
 name  String  Yes the name or http-equiv attribute of the meta attribute 
 (see nameType)
 nameType  String  Yes name or http-equiv indicating which kind of 
 name attribute is desired (name is the most common attribute but some older 
 meta tags need http-equiv)
 content   String  Yes the content of the meta attribute 

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

[jira] Resolved: (TRINIDAD-1930) Ability to easily create a meta tag

2010-09-30 Thread Matt Cooper (JIRA) 

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

Matt Cooper resolved TRINIDAD-1930.
---

Fix Version/s: 1.2.14-core 
2.0.0.2-core 
   Resolution: Fixed

 Ability to easily create a meta tag
 ---

 Key: TRINIDAD-1930
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1930
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 1.2.14-core ,  2.0.0.2-core 
Reporter: Matt Cooper
Assignee: Matt Cooper
 Fix For: 1.2.14-core ,  2.0.0.2-core 


 Ability to easily create a meta tag (e.g. 
 http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safarihtmlref/articles/MetaTags.html
  or http://www.webmarketingnow.com/tips/meta-tags-uncovered.html ) via a new 
 trh:meta tag.
 Currently it is quite tedious to create a meta tag out of a component:
 tr:document ...
   f:facet name=metaContainer
 tr:group id=metaContainer
   tr:outputText escape=false
  value='lt;meta name=viewport 
 content=width=device-width'
  id=metaTag1/
   tr:outputText escape=false
  value='lt;meta name=apple-mobile-web-app-capable 
 content=yes'
  id=metaTag2/
   tr:outputText escape=false
  value='lt;meta http-equiv=refresh 
 content=2;url=./test/index.jspx'
  id=metaTag3/
 /tr:group
   /f:facet
 /tr:document
 It would be much better if we had a trh:meta component that looked like this:
 tr:document ...
   f:facet name=metaContainer
 tr:group id=metaContainer
   trh:meta name=viewport content=width=device-width/
   trh:meta name=apple-mobile-web-app-capable content=yes/
   trh:meta name=refresh nameType=http-equiv 
 content=2;url=./test/index.jspx/
 /tr:group
   /f:facet
 /tr:document
 So I would like to see a new trh:meta component that has an API like this:
 Tag name: trh:meta
 UIComponent class: org.apache.myfaces.trinidad.component.core.CoreMeta
 Component type: org.apache.myfaces.trinidad.CoreMeta
 The meta component generates an HTML meta tag and is intended to be used 
 inside either the trh:head tag or the document component's metaContainer 
 facet.
 Events
 Type  Phases  Description
 org.apache.myfaces.trinidad.event.AttributeChangeEventInvoke 
 Application, Apply Request ValuesEvent delivered to describe an 
 attribute change. Attribute change events are not delivered for any 
 programmatic change to a property. They are only delivered when a renderer 
 changes a property without the application's specific request. An example of 
 an attribute change events might include the width of a column that supported 
 client-side resizing.
 Attributes
 Name  TypeSupports EL?Description
 attributeChangeListener   javax.el.MethodExpression   Only EL 
 a method reference to an attribute change listener. Attribute change events 
 are not delivered for any programmatic change to a property. They are only 
 delivered when a renderer changes a property without the application's 
 specific request. An example of an attribute change events might include the 
 width of a column that supported client-side resizing.
 binding   org.apache.myfaces.trinidad.component.core.CoreMeta Only EL 
 an EL reference that will store the component instance on a bean. 
 This can be used to give programmatic access to a component from a backing 
 bean, or to move creation of the component to a backing bean.
 idString  No  the identifier for the component. The identifier must 
 follow a subset of the syntax allowed in HTML:
 * Must not be a zero-length String.
 * First character must be an ASCII letter (A-Za-z) or an underscore ('_').
 * Subsequent characters must be an ASCII letter or digit (A-Za-z0-9), an 
 underscore ('_'), or a dash ('-').
 rendered  boolean Yes whether the component is rendered. When 
 set to false, no output will be delivered for this component (the component 
 will not in any way be rendered, and cannot be made visible on the client).
 name  String  Yes the name or http-equiv attribute of the meta attribute 
 (see nameType)
 nameType  String  Yes name or http-equiv indicating which kind of 
 name attribute is desired (name is the most common attribute but some older 
 meta tags need http-equiv)
 content   String  Yes the content of the meta attribute 

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

[jira] Resolved: (MYFACES-2934) Side-channel timing attack in StateUtils class may still allow padding oracle attack

2010-09-30 Thread Leonardo Uribe (JIRA) 

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

Leonardo Uribe resolved MYFACES-2934.
-

 Assignee: Leonardo Uribe
Fix Version/s: 1.1.9-SNAPSHOT
   1.2.10-SNAPSHOT
   2.0.3-SNAPSHOT
   Resolution: Fixed

I just removed the break, and left a message to prevent remove developers to 
remove that code.

Thanks to Kevin W. Wall for this report.

 Side-channel timing attack in StateUtils class may still allow padding oracle 
 attack
 

 Key: MYFACES-2934
 URL: https://issues.apache.org/jira/browse/MYFACES-2934
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 1.2.9
 Environment: All using MyFaces 1.2.9
Reporter: Kevin W. Wall
Assignee: Leonardo Uribe
Priority: Minor
 Fix For: 1.1.9-SNAPSHOT, 1.2.10-SNAPSHOT, 2.0.3-SNAPSHOT

   Original Estimate: 48h
  Remaining Estimate: 48h

 [FYI: I'm the person who fixed the padding oracle attack in ESAPI 2.0-rc# 
 crypto which is why I spotted this.]
 I did a quick code inspection of encrypt() / decrypt() methods in 
 org.apache.myfaces.shared_impl.util.StateUtils as it relates to the fix for 
 MYFACES-2749.  Most everything is done correct (MAC is over IV+ciphertext and 
 checked before decryption), but I noticed a subtle flaw that, at least in 
 theory (or enough data gathering and statistical analysis), that opens a 
 side-channel timing attack that might be still be used as a oracle in a 
 padded oracle attack such as described by Duong and Rizzo.
 The problem is in the 'for' loop at lines 471-478 in StateUtils.java. You 
 need to compare ALWAYS compare ALL the bytes in the MAC to ensure a timing 
 side-channel attack cannot be used to as an oracle in the padding oracle 
 attack.
 Contact me at kevin.w.w...@gmail.com if you need more info or want to see how 
 it was fixed in OWASP ESAPI.

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

[jira] Commented: (MYFACES-2509) @ListenerFor not processed for global system events

2010-09-30 Thread Leonardo Uribe (JIRA) 

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

Leonardo Uribe commented on MYFACES-2509:
-

Attached patch with some changes and sent to jsr-314-open list the question 
under the topic:

[jsr-314-open] Cannot register listener for PostConstructApplicationEvent and 
PreDestroyApplicationEvent using @ListenerFor annotation

 @ListenerFor not processed for global system events
 ---

 Key: MYFACES-2509
 URL: https://issues.apache.org/jira/browse/MYFACES-2509
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-314
Affects Versions: 2.0.0-alpha
Reporter: Jan-Kees van Andel
Assignee: Jan-Kees van Andel
 Attachments: ListenerFor_support.patch, MYFACES-2509-1.patch


 We currently don't process @ListenerFor and @ListenerFor annotations on 
 non-component types.
 This is specified in the spec for global system events, see:
 http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/index.html?javax/faces/event/ListenerFor.html
 It would be nice to have it in the beta.

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

Re: Myfaces vs. mojarra restore view performance

2010-09-30 Thread Leonardo Uribe 
Hi

Both optimizations are ok. +1

If you want I can commit it but I suggest you commit them.

regards,

Leonardo

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

 MArtin,

 your account is now setup - you even could apply them yourself,
 after Leo did a successful review

 -;M

 On Thu, Sep 30, 2010 at 1:14 PM, Martin Koci
 martin.kocicak.k...@gmail.com wrote:
  Hi,
 
  Leonardo, can you please review :
  https://issues.apache.org/jira/browse/MYFACES-2922
  https://issues.apache.org/jira/browse/MYFACES-2862
 
  and apply them if they are suitable?
 
 
  Thanks,
 
  Kočičák
 
  Martin Koci píše v Út 14. 09. 2010 v 23:05 +0200:
  Hi,
 
 
  please review https://issues.apache.org/jira/browse/MYFACES-2922 and
  apply if possible.
 
  Thanks,
 
  Kočičák
 
 
  Leonardo Uribe píše v Pá 06. 08. 2010 v 13:07 -0500:
   Hi
  
   2010/8/6 Martin Koci martin.k...@aura.cz
   Hi,
  
  
   is it possible to cache inspected classes in
   RequestViewContext? I did
   something like that:
  
   if (isProduction  !
   requestViewContext.isAlreadyInspected(inspectedClass)) {
  
  _handleListenerForAnnotations(context, inspected,
   inspectedClass, component, isProduction);
  
  _handleResourceDependencyAnnotations(context,
   inspectedClass, component, isProduction);
  
  requestViewContext.setAsProcessed(inspectedClass);
  }
  
   in _handleAnnotations and it reduces restore view time to
   30-40 ms.
  
  
   It is necessary to apply @ListenerFor annotations on every component
   that has registered
   it in the view. The reason why we can cache @ResourceDependency is
   this annotation
   cause a component resource to be added, and that one will be always
   the same.
  
regards,
  
   Leonardo
  
  
   regards,
  
   Martin Kočí
  
   Leonardo Uribe píše v Čt 05. 08. 2010 v 15:56 -0500:
  
Hi
   
Ok, good to know that. I closed MYFACES-2854. Maybe on
   MYFACES-2862 we
can use FacesContext.isProjectStage(ProjectStage).
   
regards,
   
Leonardo
   
2010/8/5 Martin Koci martin.k...@aura.cz
Hi,
   
success!
   
myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70
   ms in
restore view
phase. It was *750 ms* before.
   
Thanks,
   
Martin Kočí
   
Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
   
 Hi

 I implemented a proposal for this one on
MYFACES-2854-2.patch using
 the suggestion
 proposed (do not apply ResourceDependency if it
   was already
 processed). I hope that
 patch solve the problem.

 regards,

 Leonardo

   
   
   
   
  
  
  
  
 
 
 
 
 



 --
 Matthias Wessendorf

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

Re: [core] FacesEL vs. UEL vs. UEL 2.2

2010-09-30 Thread Leonardo Uribe 
Hi

2010/9/30 Martin Koci martin.kocicak.k...@gmail.com

 Hi,


 there is a disorder in Expression Lauguage names in myfaces core.
 Currently myfaces (method
 javax.faces.validator._ExternalSpecifications.isUnifiedELAvailable() for
 example) output a log:

 MyFaces Unified EL support enabled

 But this is a little misleading: there should be Unified EL 2.2 support
 enabled because it tests presence of EL 2.2. Unified EL support
 enabled does not make sence at all because JSF use Unified EL as core
 technology and that cannot be disabled.


 There are three major versions of ELs:

 1) javax.faces.el - old and depreceated

 2) javax.el 2.0, 2.1 (from JSP 2.0, 2.1)


Isn't javax.el version 1.0 on maven repo?


 3) javax.el 2.2 from JSP 2.2, part of Java EE 6, EL with method
 invocations


 Suggestions:
 Rename isUnifiedELAvailable to isUnifiedEL22Available,
 TagValueExpressionUEL to TagValueExpressionUEL22 and so on.
 For EL 2.3 (not released yet) we can add similar methods/classes.

 Change log to MyFaces Unified EL 2.2 support enabled (method
 invocations are available).

 I'll add similiar log MyFaces Faces EL (javax.faces.el) support
 disabled  as part of disabling old technologies

 WDYT ?


Sounds reasonable for me. The message about MyFaces Faces EL
really is not necessary at all in my personal opinion, but if it is added
no problem.

regards,

Leonardo


 Kočičák

Result (was: [VOTE] release for myfaces tomahawk 1.1.10)

2010-09-30 Thread Leonardo Uribe 
Hi

Thanks to all people who vote

We have 3 +1

Werner Punz
Jakob Korherr
Leonardo Uribe

So we can continue with the necessary steps to release tomahawk 1.1.10

regards,

Leonardo

[jira] Created: (MYFACES-2935) SystemEvent Acid Test

2010-09-30 Thread Kennard Consulting (JIRA) 
SystemEvent Acid Test
-

 Key: MYFACES-2935
 URL: https://issues.apache.org/jira/browse/MYFACES-2935
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.2
Reporter: Kennard Consulting


Hi guys,

First - thanks for the great work you do with MyFaces. It's an awesome product 
and it's wonderful to have an independent implementation of the JSF spec!

I am the author of Metawidget (http://metawidget.org), a JSF component that 
does a lot of runtime component tree manipulation. This was unreliable under 
JSF 1, but JSF 2 introduced SystemEvents which promise to make this more solid. 
I believe Metawidget exercises SystemEvents more than most, and as such I am 
seeing problems both in MyFaces (2.0.2) and in Mojarra (2.0.3).

As a bit of fun I have created a small Acid Test (inspired by 
http://acidtests.org) for SystemEvents. I would be most grateful if you could 
work through the 3 tests and get MyFaces working with them. Basically the tests 
all use a combination of PreRenderViewEvent and tree manipulation. Full 
instructions are included on each JSF page. Of course, there may be bugs in the 
test itself in which case feel free to point them out :)

Regards,

Richard.

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

[CANCELED] [VOTE] Release Tobago 1.0.30

2010-09-30 Thread Bernd Bohmann 
Ok

I'm for the option 1. So I cancel this vote and create a new vote.

Regards

Bernd

On Thu, Sep 30, 2010 at 4:05 PM, Udo Schnurpfeil u...@schnurpfeil.de wrote:
  Hi, all,

 I've found a new critical bug:
 https://issues.apache.org/jira/browse/TOBAGO-921
 I've fixed it, but it is not in 1.0.30. So we have two possibilities:

  1. put it in 1.0.30 and rebuild it or
  2. put it in 1.0.31 and release it asap.

 Regards

 Udo


 Am 29.09.10 09:20, schrieb Bernd Bohmann:

 Hello Volker,

 TOBAGO-920 has the fixed version 1.0.30. I reasign the fixed version
 to 1.0.30. Now the release notes includes TOBAGO-920. Maybe a jira
 bug?

 Regards

 Bernd

 On Wed, Sep 29, 2010 at 9:08 AM, Volker Weberv.we...@inexso.de  wrote:

 Hi Bernd,

 the release notes did not include TOBAGO-920 (The layout of the
 TabGroup is broken if one Tab is rendered=false).

 Wasn't this fixed before you tag this release?


 Regards,
    Volker

 2010/9/28 Bernd Bohmannbernd.bohm...@atanion.com:

 Hello,

 I would like to release Tobago 1.0.30.

 For a detail list please consult the release notes:


 http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12315336

 The version is available at the nexus staging repository.


 Staging repository:

 https://repository.apache.org/content/repositories/orgapachemyfaces-021/

 The Vote is open for 72h.

 [ ] +1
 [ ] +0
 [ ] -1

 Regards

 Bernd



 --
 inexso - information exchange solutions GmbH
 Ofener Str. 30      | 26121 Oldenburg
 Tel.: +49 441 219 730 56 |
 FAX:  +49 441 219 730 66 | eMail: volker.we...@inexso.de

 Firmensitz: Hamburg   | Amtsgericht Hamburg, HRB 84273
 Geschäftsführer: Stefan Schulte, Michael Terschüren, Dirk Fangohr