date:20071219

no other comments ?

that would mean to me, everbody is fine w/ the change.

-M

On Dec 16, 2007 3:29 PM, Manfred Geiler [EMAIL PROTECTED] wrote:
 yes, myfaces-build-tools is a much better name

 --Manfred



 On 12/16/07, Bruno Aranda [EMAIL PROTECTED] wrote:
  +1 About the naming, though, this seems to be more myfaces-build-tools
  than myfaces-dev-tools, because as far as I understand, this artifacts
  are used during the build, not for just development...
 
  Thanks for the good work!
 
  Bruno
 
  On 15/12/2007, Matthias Wessendorf [EMAIL PROTECTED] wrote:
   Bernd's wagon could be also hosted there as well.
  
   -M
  
   On Dec 15, 2007 11:12 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
   
there is this maven plugins folder for the Trinidad Plugins (see [1]).
The Trinidad inside the name may confuse people. The plugins
are generally usable outside of Trinidad as well.
The maven-faces-plugin for instance, is used in other projects, such
as MyFaces Core, or MyFaces Commons.
   
The idea is to move them into a different location.
A name like  myfaces developers toolkit, myfaces dev tools, or
what ever you like ?
   
The idea would be to keep it abstract like
   
/myfaces-dev-tools
  -/maven2-plugins
  -tbc
   
that would allow us to have maven3 or ant or what ever support as 
well.
   
Greetings,
Matze  Manfred
   
   
[1] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/
   
--
Matthias Wessendorf
   
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
   
  
  
  
   --
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   sessions: http://www.slideshare.net/mwessendorf
   mail: matzew-at-apache-dot-org
  
 


 --
 http://www.irian.at
 Your JSF powerhouse - JSF Consulting,
 Development and Courses in English and
 German

 Professional Support for Apache MyFaces




-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[jira] Resolved: (MYFACES-1790) HtmlColumnTag.getComponentType returns the wrong value

2007-12-19 Thread JIRA


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

Matthias Weßendorf resolved MYFACES-1790.
-

   Resolution: Fixed
Fix Version/s: 1.2.1-SNAPSHOT

 HtmlColumnTag.getComponentType returns the wrong value
 --

 Key: MYFACES-1790
 URL: https://issues.apache.org/jira/browse/MYFACES-1790
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions:  1.2.0
Reporter: Cameron Bateman
Assignee: Matthias Weßendorf
 Fix For: 1.2.1-SNAPSHOT


 According to the spec, the component type of the default h:column tag is 
 supposed to be javax.faces.Column, however HtmlColumnTag returns 
 javax.faces.HtmlColumn.

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

[Committers] Please read

Are you listed here (inside the developers section)?:
https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml

If not,

check out this pom:
https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml

and add your self to the developers section.

Thx,
Matthias

-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[Trinidad] release of plugins

Hi,

there were several changes in the plugins;
-JDEV
-Trinidad
-Commons
-MyFaces
etc.

so, there are now some dependencies to SNAPSHOTS.

I'd like to get the plugins 1.2.6 out and start (afterwards) the re-org.
(see other thread for the re-org)

Any veto (on the release)?

-M

-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[Trinidad] Website for 1.2.x

Hi,

we have now the site for Trinidad 1.2.x online:
http://myfaces.apache.org/trinidad/trinidad-1_2/

Most important is the API-JavaDoc, IMO:
http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-api/apidocs/index.html

Greetings,
Matthias

-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[jira] Created: (TRINIDAD-876) Height attribute value (af|menuBar::empty)

2007-12-19 Thread Jesper Pedersen (JIRA)

Height attribute value (af|menuBar::empty)
--

 Key: TRINIDAD-876
 URL: https://issues.apache.org/jira/browse/TRINIDAD-876
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.4-core
 Environment: Trinidad 1.2 branch
Reporter: Jesper Pedersen


Currently the following is rendered when no menubar is defined:

table class=af_menuBar_empty width=100% cellspacing=0 cellpadding=0 
border=0 summary=
  tbody
tr
  td height=1/
/tr
  /tbody
/table

The following would be better:

table class=af_menuBar_empty width=100% cellspacing=0 cellpadding=0 
border=0 summary=
  tbody
tr
  td height=0/
/tr
  /tbody
/table

with a changed 'height' value (before: 1 after: 0) -- if not removed completely.

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

[jira] Created: (TRINIDAD-877) af|tableSelectMany and af|tableSelectOne selectors exist in Tinidad though both components are no longer around

2007-12-19 Thread Frank Nimphius (JIRA)

af|tableSelectMany and af|tableSelectOne selectors exist in Tinidad though both 
components are no longer around
---

 Key: TRINIDAD-877
 URL: https://issues.apache.org/jira/browse/TRINIDAD-877
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components, Skinning
Affects Versions: 1.2.4-core
Reporter: Frank Nimphius
Priority: Minor


To skin the table select one and table select many radio buttons and column, 
the Trinidad selectors to use are af|tableSelectMany or af|tableSelectOne. This 
is odd because the components af:tableSelectMany and af:tableSelectOne no 
longer exist in Trinidad (they did exist in ADF Faces). To be more consistent 
with the component changes in Trinidad, the two selectors should be renamed to 
e.g. af:table::SelectMany and af|table::SelectOne



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

Re: site restructure

2007-12-19 Thread Sorin Silaghi

yes, subcategories look a bit more organized.

On Dec 15, 2007 10:53 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:

I like the sub-categories from Manfred's proposal

-M

On Dec 15, 2007 9:45 PM, Manfred Geiler [EMAIL PROTECTED] wrote:
I also fiddled with the site a few weeks ago... and got stuck. ;-)

Well here is the outcome of my fiddling:
http://people.apache.org/~manolito/myfaces-site/http://people.apache.org/%7Emanolito/myfaces-site/

Notice the collapsible menu items. I made them uncollapsed for this
example, but they should be collapsed on the main page (like on the
Maven site for instance).

There is a slight difference in the structure.
According to the nature of the various sub projects there is a
difference between the core stuff and the component libs. I think it's
more natural to think of two different projects for the core: Core
(JSF 1.1) and Core (JSF 1.2). Both are then divided into API and
Impl.
Trinidad on the other hand is one project with two flavours JSF 1.1and
1.2.

There is also a technical issue I would like to propose:
What about changing the version value of the site pom to unversioned
to reflect the fact that this site project will never be deployed or
released?

--Manfred

On 12/15/07, Simon Kitching [EMAIL PROTECTED] wrote:
Ok, I've been fiddling with the myfaces site for a bit, in order to
clarify JSF1.1 vs JSF1.2 support.

Every page in the docs section, except the wiki link needs a
different version for the two JSF versions. Reading the 1.1 version would
be really confusing for someone intending to use 1.2.

And many (but not all) of the subprojects need a different home page
for the different versions.

Here's a possible restructure of the home page:

http://people.apache.org/~skitching/myfaces-site/http://people.apache.org/%7Eskitching/myfaces-site/

Most of the links don't currently work; the distributionManagement
section of the poms in the 1.1 and 1.2 branches would just need to be
updated to match, then new sites for them pushed out.

And of course the documentation pages (esp the ones in the JSF12
sections) would need to be updated. But that needs the restructure to happen
first.

Comments? Better ideas?

Note that AFAIK there is no way for a menu on the left navbar to have
a submenu.

Regards,

Simon

--
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[jira] Created: (TRINIDAD-878) Overhaul ConverterTagGenerator's writeCreateConverter()

2007-12-19 Thread JIRA

Overhaul ConverterTagGenerator's writeCreateConverter()
---

 Key: TRINIDAD-878
 URL: https://issues.apache.org/jira/browse/TRINIDAD-878
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Plugins
Affects Versions:  1.2.6-plugins
Reporter: Matthias Weßendorf
Assignee: Matthias Weßendorf


Currently the writeCreateConverter() method is only defined in 
AbstractConverterTagGenerator.
That causes an issue, when running the build of commons-converter w/ JSF 1.2

We need to make the writeCreateConverter() more clean, to support these type of 
requirements as well.
(one issue is, that EnumConverter in Commons has NO! properties, so generation 
isn't working).

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

Re: [Trinidad] release of plugins

I think, I'd like to get
https://issues.apache.org/jira/browse/TRINIDAD-878
fixed first

On Dec 19, 2007 10:42 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 Hi,

 there were several changes in the plugins;
 -JDEV
 -Trinidad
 -Commons
 -MyFaces
 etc.

 so, there are now some dependencies to SNAPSHOTS.

 I'd like to get the plugins 1.2.6 out and start (afterwards) the re-org.
 (see other thread for the re-org)

 Any veto (on the release)?

 -M

 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 mail: matzew-at-apache-dot-org




-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[commons] enum converter

do we need really need a TAG for the enum-converter ?
Shouldn't it be (like in JSF 1.2) enough, to just have it declared in
the faces-config ?

-M

-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [commons] enum converter

2007-12-19 Thread Volker Weber

Hi,

i like to extend the converter to make it usable via tag instead of
converter attribute of component tags.

getAsString() should return something like
enum.getClass().getName() + # + enum.name()

then we don't need the targetClass.


Regards,
Volker

2007/12/19, Matthias Wessendorf [EMAIL PROTECTED]:
 do we need really need a TAG for the enum-converter ?
 Shouldn't it be (like in JSF 1.2) enough, to just have it declared in
 the faces-config ?

 -M

 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 mail: matzew-at-apache-dot-org



-- 
inexso - information exchange solutions GmbH
Bismarckstraße 13  | 26122 Oldenburg
Tel.: +49 441 4082 356 |
FAX:  +49 441 4082 355 | www.inexso.de

Re: [Trinidad] release of plugins

2007-12-19 Thread Gary Kind

Matthias, this is fine with me.  I have a couple of changes to make in 
the jdev plugin, but they can wait until the next release.

When do you plan to freeze for the 1.2.6 plugins release?

Matthias Wessendorf wrote:

Hi,

there were several changes in the plugins;
-JDEV
-Trinidad
-Commons
-MyFaces
etc.

so, there are now some dependencies to SNAPSHOTS.

I'd like to get the plugins 1.2.6 out and start (afterwards) the re-org.
(see other thread for the re-org)

Any veto (on the release)?

-M

Re: [Trinidad] release of plugins

since the issue isn't that bad, I've no problems in providing a
RC bundle for 1.2.6, by tomorrow.
That means, after the vote (3 days) the release would be out
on 23th.

After that 1.2.6, I'd also re-org the structure, by naming the plugins
myfaces-dev-toolkit (discussion for that happens in another thread),
etc.

-Matthias

On Dec 19, 2007 7:44 PM, Gary Kind [EMAIL PROTECTED] wrote:
 Matthias, this is fine with me.  I have a couple of changes to make in
 the jdev plugin, but they can wait until the next release.
 When do you plan to freeze for the 1.2.6 plugins release?


 Matthias Wessendorf wrote:
  Hi,
 
  there were several changes in the plugins;
  -JDEV
  -Trinidad
  -Commons
  -MyFaces
  etc.
 
  so, there are now some dependencies to SNAPSHOTS.
 
  I'd like to get the plugins 1.2.6 out and start (afterwards) the re-org.
  (see other thread for the re-org)
 
  Any veto (on the release)?
 
  -M
 
 




-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[jira] Commented: (MYFACES-1783) IndexOutOfBoundsException in custom compound compoment


[ 
https://issues.apache.org/jira/browse/MYFACES-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553442
 ] 

Leonardo Uribe commented on MYFACES-1783:
-

deffered to 1.2.2

 IndexOutOfBoundsException in custom compound compoment
 --

 Key: MYFACES-1783
 URL: https://issues.apache.org/jira/browse/MYFACES-1783
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions:  1.2.0
 Environment: Windows XP, java 1.6.0_03
 myfaces 1.2.1-SNAPSHOT and 1.2.0 on jetty-6.1.0pre0
Reporter: Jeroen Verhagen
 Fix For: 1.2.2-SNAPSHOT


 The following code for a custom (compound) component causes and 
 IndexOutOfBoundsException on submit. It renders OK.  
  package com.mycompany;
 import javax.el.ELContext;
 import javax.el.ExpressionFactory;
 import javax.el.ValueExpression;
 import javax.faces.application.Application;
 import javax.faces.component.EditableValueHolder;
 import javax.faces.component.UIComponent;
 import javax.faces.component.UIInput;
 import javax.faces.component.UISelectItems;
 import javax.faces.component.html.HtmlSelectOneRadio;
 import javax.faces.context.FacesContext;
 import javax.faces.context.ResponseWriter;
 import javax.faces.convert.BooleanConverter;
 import javax.faces.model.SelectItem;
 import java.io.IOException;
 import java.util.Map;
 public class UIBooleanFieldset extends UIInput {
   public UIBooleanFieldset() {
   setConverter(new BooleanConverter());
   setRendererType(null);
   Application application = 
 FacesContext.getCurrentInstance().getApplication();
   HtmlSelectOneRadio htmlSelectOneRadio = (HtmlSelectOneRadio) 
 application.createComponent(HtmlSelectOneRadio.COMPONENT_TYPE);
   htmlSelectOneRadio.setId(getId() + _radios);
   ExpressionFactory ef = 
 FacesContext.getCurrentInstance().getApplication().getExpressionFactory();
   ELContext elContext = 
 FacesContext.getCurrentInstance().getELContext();
   ValueExpression sexValueExpression = 
 ef.createValueExpression(elContext, #{persoonBean.sex}, String.class);
   htmlSelectOneRadio.setValueExpression(value, 
 sexValueExpression);
   htmlSelectOneRadio.setLayout(pageDirection);
   UISelectItems selectItems = (UISelectItems) 
 application.createComponent(UISelectItems.COMPONENT_TYPE);
   ValueExpression sexItemsValueExpression = 
 ef.createValueExpression(elContext, #{persoonBean.sexItems}, 
 SelectItem[].class);
   selectItems.setValueExpression(value, 
 sexItemsValueExpression);
   htmlSelectOneRadio.getChildren().add(selectItems);
   getChildren().add(htmlSelectOneRadio);
   }
   public void encodeBegin(FacesContext context) throws IOException {
   ResponseWriter writer = context.getResponseWriter();
   String clientId = getClientId(context);
   writer.startElement(fieldset, this);
   writer.startElement(legend, this);
   writer.writeText(getAttributes().get(legend), this, clientId);
   }
   public void encodeEnd(FacesContext context) throws IOException {
   ResponseWriter writer = context.getResponseWriter();
   writer.endElement(legend);
   writer.endElement(fieldset);
   }
   public void decode(FacesContext context, UIComponent component) {
   EditableValueHolder fieldset = (EditableValueHolder) component;
   MapString, String requestMap = 
 context.getExternalContext().getRequestParameterMap();
   String clientId = component.getClientId(context);
   try {
   int submittedValue = Integer.parseInt((String) 
 requestMap.get(clientId));
   int newValue = 0;
   fieldset.setSubmittedValue( + newValue);
   fieldset.setValid(true);
   } catch (NumberFormatException ex) {
   // let the converter take care of bad input, but we 
 still have
   // to set the submitted value, or the converter won't 
 have
   // any input to deal with
   fieldset.setSubmittedValue((String) 
 requestMap.get(clientId));
   }
   }
 }
 The exception:
 ava.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:546)
at java.util.ArrayList.get(ArrayList.java:321)
at 
 javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:740)
at 
 javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:743)
at 
 javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:743)

[jira] Commented: (MYFACES-1761) Handling PostConstruct annotations - wrong order


[ 
https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553443
 ] 

Leonardo Uribe commented on MYFACES-1761:
-

deffered to 1.2.2

 Handling PostConstruct annotations - wrong order
 

 Key: MYFACES-1761
 URL: https://issues.apache.org/jira/browse/MYFACES-1761
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions:  1.2.0, 1.2.1-SNAPSHOT
Reporter: Bernhard Huemer
Assignee: Paul McMahan
 Fix For: 1.2.2-SNAPSHOT

 Attachments: MYFACES-1761-01.diff, MyFaces-1761.patch, 
 postconstruct-demo.zip


 The specification states that managed bean methods annotated with 
 @PostConstruct have to be called after the object is initialized and after 
 dependency injection is performed. However, MyFaces calls those methods after 
 the bean instance is created but before dependency injection is performed 
 (for example, see 
 http://www.nabble.com/myfaces-1.2.0-postConstruct-tf4760326.html ). In order 
 to resolve this bug the LifecycleProvider interface has to be changed. 
 Currently there's only one method responsible for creating/initializing a new 
 bean: newInstance(). This design choice implicates that there's no 
 possibility to seperate the steps creating the bean and postconstructing 
 the bean.

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

[jira] Commented: (MYFACES-1790) HtmlColumnTag.getComponentType returns the wrong value


[ 
https://issues.apache.org/jira/browse/MYFACES-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553444
 ] 

Leonardo Uribe commented on MYFACES-1790:
-

deffered to 1.2.2 because it's necessary to release maven-faces-plugins for 
this issue only

 HtmlColumnTag.getComponentType returns the wrong value
 --

 Key: MYFACES-1790
 URL: https://issues.apache.org/jira/browse/MYFACES-1790
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions:  1.2.0
Reporter: Cameron Bateman
Assignee: Matthias Weßendorf
 Fix For: 1.2.2-SNAPSHOT


 According to the spec, the component type of the default h:column tag is 
 supposed to be javax.faces.Column, however HtmlColumnTag returns 
 javax.faces.HtmlColumn.

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

[jira] Created: (TOMAHAWK-1170) Resource mapping missing / throwExtensionsFilterMissing reported incorrectly under load

2007-12-19 Thread Simon Kitching (JIRA)

Resource mapping missing / throwExtensionsFilterMissing reported incorrectly 
under load
---

 Key: TOMAHAWK-1170
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1170
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: ExtensionsFilter
Affects Versions: 1.1.7-SNAPSHOT
Reporter: Simon Kitching


It has been reported by two users that under load an application using Tomahawk 
intermittently throws an exception claiming resource mapping missing.

This message is meant to be thrown when a component in a request wants to 
register stuff for the extensions filter to output, but the current request 
never passed through the extensions filter. This is a sanity check to ensure 
that people that misconfigure the ExtensionsFilter get a helpful error message 
rather than just having tomahawk components that need additional resources 
acting weirdly.

A workaround is to disable this safety check. The first reporter of this 
problem did disable the check and found the issue disappeared.

The problem appears to be a race condition between multiple threads *reading* a 
map; at least that was the only piece of code I found that had any obvious 
thread race issues. I can't remember the exact piece of code for the moment, 
but will update this issue when I find it again.

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

[Vote] release for myfaces 1.2.1

Hi,

I was running the needed tasks to get the 1.2.1 release of Apache
MyFaces core out.

Please note that this vote concerns all of the following parts:
 1. Maven artifact group org.apache.myfaces.shared v3.0.1  [1]
 2. Maven artifact group org.apache.myfaces.core v1.2.1  [1]

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

Please take a look at the 1.2.0 artifacts and vote!

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


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


Thanks,
Leonardo Uribe

[1] http://people.apache.org/~lu4242/myfaces121
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: [Vote] release for myfaces 1.2.1

2007-12-19 Thread Grant Smith

+1

On 12/19/07, Leonardo Uribe [EMAIL PROTECTED] wrote:

 Hi,

 I was running the needed tasks to get the 1.2.1 release of Apache
 MyFaces core out.

 Please note that this vote concerns all of the following parts:
 1. Maven artifact group org.apache.myfaces.shared v3.0.1  [1]
 2. Maven artifact group org.apache.myfaces.core v1.2.1  [1]

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

 Please take a look at the 1.2.0 artifacts and vote!

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

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

 Thanks,
 Leonardo Uribe

 [1] http://people.apache.org/~lu4242/myfaces121
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes




-- 
Grant Smith

Re: site restructure

Hi All,

Just for people's info, I have worked a bit more on what Manfred started
with the site.

At the moment, the core 1.1.x stuff is deployed at
  myfaces.apache.org/api
and
  myfaces.apache.org/impl

Manfred changed things so that the core/trunk site now deploys to
  myfaces.apache.org/core11
and core/trunk_1_2_x deploys to
  myfaces.apache.org/core12

I have updated these sites, and actually deployed them to the main
apache server. They are not visible to most people because the home
page still links to /api and /impl, but you can see them here:
   http://myfaces.apache.org/core11/index.html
   http://myfaces.apache.org/core12/index.html

As you can see, they are not quite perfect yet. For some reason, there
is no collapsed toggle on the core12 option of the core11 page.  And
the core12 page has picked up a different skin from somewhere. But I
hope to get that cleaned up soon.

Then if people think it is ok we can publish a new home page that
links to these new versions.

Note that at the moment the site.xml is essentially copy-and-pasted into
core/trunk, core/trunk_1_2_x, and would need to go into tomahawk, etc.
too. It would be nice to be able to just inherit these definitions from
somewhere rather than copy-and-paste but this appears to be a limitation
of Maven. While a project can inherit a POM from anywhere (the poms are
all in the registry just waiting to be referenced), site settings can
only be inherited by invoking a build in a directory and having that
build pass the settings down to its submodules. Running a site build in
a subdirectory doesn't work as the settings are not inherited. But we
cannot rebuild the whole myfaces site every time some subproject wants
to update its webpages. Well, at least that's how I understand things at
the moment.

I'm not claiming this is perfect, but I think it is better than what was
there before. Slow steps...

By the way, the myfaces core 1.2 pom has some funky profile called
generate-site that AFAICT is trying to build a report that contains
pretty TLD documentation for the components. That would be great to
have, but I cannot get it to work. Could someone who knows about that
please document it (eg add comments to the pom.xml) or at least email
instructions on how to make it work?

Cheers,

Simon

On Wed, 2007-12-19 at 12:33 +0200, Sorin Silaghi wrote:
 yes, subcategories look a bit more organized.
 
 
 On Dec 15, 2007 10:53 PM, Matthias Wessendorf [EMAIL PROTECTED]
 wrote:
 I like the sub-categories from Manfred's proposal
 
 -M
 
 
 On Dec 15, 2007 9:45 PM, Manfred Geiler
 [EMAIL PROTECTED]  wrote:
  I also fiddled with the site a few weeks ago... and got
 stuck.  ;-)
 
  Well here is the outcome of my fiddling:
  http://people.apache.org/~manolito/myfaces-site/
 
  Notice the collapsible menu items. I made them uncollapsed
 for this
  example, but they should be collapsed on the main page (like
 on the
  Maven site for instance). 
 
  There is a slight difference in the structure.
  According to the nature of the various sub projects there is
 a
  difference between the core stuff and the component libs. I
 think it's
  more natural to think of two different projects for the
 core: Core
  (JSF 1.1) and Core (JSF 1.2). Both are then divided into
 API and
  Impl.
  Trinidad on the other hand is one project with two
 flavours JSF 1.1 and 1.2.
 
  There is also a technical issue I would like to propose:
  What about changing the version value of the site pom to
 unversioned
  to reflect the fact that this site project will never be
 deployed or 
  released?
 
 
  --Manfred
 
 
 
  On 12/15/07, Simon Kitching [EMAIL PROTECTED]
 wrote:
   Ok, I've been fiddling with the myfaces site for a bit, in
 order to clarify JSF1.1 vs JSF1.2 support.
  
   Every page in the docs section, except the wiki link
 needs a different version for the two JSF versions. Reading
 the 1.1 version would be really confusing for someone
 intending to use 1.2.
  
   And many (but not all) of the subprojects need a different
 home page for the different versions.
  
   Here's a possible restructure of the home page:
 http://people.apache.org/~skitching/myfaces-site/
  
   Most of the links don't currently work; the
 distributionManagement section of the poms in the 1.1 and 1.2
 branches would just need to be updated to match, then new
 sites for them pushed out.
  
   And of course the documentation pages (esp the ones in the
 JSF12 sections) would need

Re: [Vote] release for myfaces 1.2.1


On Wed, 2007-12-19 at 11:54 -0800, Grant Smith wrote:
 +1

That was very quick, Grant!

Have you really inspected all the artifacts Leonardo created to see if
they are right? Licenses need to be correct, MANIFEST files should be
double-checked, checksums verified, etc.

Regards,

Simon

Re: Server state saving and multiple frames

Hi Nicu,

I haven't got time to look at this closely, but IMO siomething like this
is definitely needed in MyFaces. A user with multiple windows is
certainly going to have trouble at the moment.

I think a modification to the view pool to include a window id (or
frame id) is definitely a good idea.

The second part of the problem still remains: how to associate a
different id with each window/frame. Checking CommandLink components for
a target attribute is clever; it doesn't solve all the cases but does
solve some.

Regards,

Simon

On Tue, 2007-12-18 at 19:07 +0200, Nicu Mercioiu wrote:
 Hi,
 
   There is a problem in JSF when more than one window are opened
 in an application.
 There are only a maximum number of NUMBER_OF_VIEWS_IN_SESSION  view
 states saved at one moment (when server side state saving is enabled).
 If you have 2 windows opened and you navigate on one of them for
 NUMBER_OF_VIEWS_IN_SESSION times, you will lose the other window's
 state.
 
 I've been facing this problem while developing a project so I've
 implemented a solution for it.
 
The solution is having a number of view states saved for each
 opened window at one moment.
 For determining when a new window (frame) is opened, the target of the
 submitting component (or its enclosing form) is used.
 This is obtained in the HtmlLinkRendererBase's and
 HtmlButtonRendererBase's decode methods and it is set in the
 RequestMap.
 Using the submitted target, the JspStateManagerImpl figures out
 whether a new frame was opened.
 If so, a new frame id is generated.
 In the renderResponse phase, the frameId is encoded in the
 javax.faces.ViewState field
 and is used along with the viewId to save the state in a
 SerializedViewCollection.
 In the restore view phase the frameId is decoded from the
 javax.faces.ViewState field
 and is used along with the viewId to restore the corresponding state
 from the SerializedViewCollection.
 
In SerializedViewCollection instead of a list of recently used
 views, now a list is kept for each frameId.
 The following context params are defined for configuring this.
 NUMBER_OF_FRAMES_IN_SESSION (max frames stored)
 NUMBER_OF_VIEWS_IN_FRAME (max views stored per frame)
 These replace the old: NUMBER_OF_VIEWS_IN_SESSION context-param.
 
 
 What is your opinion on this solution?
 
   Of course this solution only works with MyFaces Tomahawk's
 commandLink and commandButton.
 Ohter component sets that do not use a custom stateManager might use
 this feature
 if they will just modify the renderers of command components to set
 the target attribute in the requestMap.
 
   An extra feature would be to enable this for outputLinks (plain
 old links) and for JS (openWindow).
 The solution for this is quite simple, just add a GET parameter named
 'target' and set the value the same as the target attribute.
 In the JspStateManagerImpl this value is obtained from the
 requestParameterMap and used the same as in the other case.
 Do you think this would be useful too?
 
 Regards,
 Nicu

Re: [Vote] release for myfaces 1.2.1

I updated the dependency of the mfp to 126-SNAP.
Did you notice that ?

-M

On Dec 19, 2007 8:49 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
 Hi,

 I was running the needed tasks to get the 1.2.1 release of Apache
 MyFaces core out.

 Please note that this vote concerns all of the following parts:
  1. Maven artifact group org.apache.myfaces.shared v3.0.1  [1]
  2. Maven artifact group org.apache.myfaces.core v1.2.1  [1]

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

 Please take a look at the 1.2.0 artifacts and vote!

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

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

 Thanks,
 Leonardo Uribe

 [1] http://people.apache.org/~lu4242/myfaces121
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes




-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [Vote] release for myfaces 1.2.1

-1
the license/notice files are not located in META-INF
but they are in the JAR, that's right. But they should be placed
in META-INF.

not sure if MYFACES-1790 is a showstopper.

-M

On Dec 19, 2007 11:11 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 I updated the dependency of the mfp to 126-SNAP.
 Did you notice that ?

 -M


 On Dec 19, 2007 8:49 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
  Hi,
 
  I was running the needed tasks to get the 1.2.1 release of Apache
  MyFaces core out.
 
  Please note that this vote concerns all of the following parts:
   1. Maven artifact group org.apache.myfaces.shared v3.0.1  [1]
   2. Maven artifact group org.apache.myfaces.core v1.2.1  [1]
 
  The artifacts are deployed to my private Apache account ([1]).
 
  Please take a look at the 1.2.0 artifacts and vote!
 
  Please note: This vote is majority approval with a minimum of three
  +1 votes (see [3]).
 
  
  [ ] +1 for community members who have reviewed the bits
  [ ] +0
  [ ] -1 for fatal flaws that should cause these bits not to be released,
  and why..
  
 
  Thanks,
  Leonardo Uribe
 
  [1] http://people.apache.org/~lu4242/myfaces121
  [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 



 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 mail: matzew-at-apache-dot-org




-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [Vote] release for myfaces 1.2.1

2007-12-19 Thread Grant Smith

Actually the guidelines for Release Voting [1] make no stipulation on the
detail of inspection. I performed a cursory inspection and compared the
contents and layout to previous release stagings. I am using this current
version in three projects without issue, so at a functional level I believe
this release to be ready.

I admittedly have not double checked the checksums or MANIFEST files, but
from a license perspective we cleared up all those issues quite a while ago.

My vote stands.

[2] http://www.apache.org/foundation/voting.html#ReleaseVotes


On 12/19/07, simon [EMAIL PROTECTED] wrote:


 On Wed, 2007-12-19 at 11:54 -0800, Grant Smith wrote:
  +1

 That was very quick, Grant!

 Have you really inspected all the artifacts Leonardo created to see if
 they are right? Licenses need to be correct, MANIFEST files should be
 double-checked, checksums verified, etc.

 Regards,

 Simon




-- 
Grant Smith

Re: [Vote] release for myfaces 1.2.1

On Dec 19, 2007 11:16 PM, Grant Smith [EMAIL PROTECTED] wrote:
 Actually the guidelines for Release Voting [1] make no stipulation on the
 detail of inspection. I performed a cursory inspection and compared the
 contents and layout to previous release stagings. I am using this current
 version in three projects without issue, so at a functional level I believe
 this release to be ready.

 I admittedly have not double checked the checksums or MANIFEST files, but
 from a license perspective we cleared up all those issues quite a while ago.

 My vote stands.

... and it is up to the release mgr to accept a -1 or not.
There are no vetos;

Since I care on the right location of license/notice files, I voted -1
(that means like I am not supporting the release as it is today)

not sure what went wrong in this release,
since the 1.2.0 and the 1.1.x license/notice files were OK

-M


 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes




 On 12/19/07, simon [EMAIL PROTECTED]  wrote:
 
  On Wed, 2007-12-19 at 11:54 -0800, Grant Smith wrote:
   +1
 
  That was very quick, Grant!
 
  Have you really inspected all the artifacts Leonardo created to see if
  they are right? Licenses need to be correct, MANIFEST files should be
  double-checked, checksums verified, etc.
 
  Regards,
 
  Simon
 
 



 --
 Grant Smith




-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [Vote] release for myfaces 1.2.1

2007-12-19 Thread Grant Smith

I'm not sure where you're getting your information from. See [1] for
instructions on where and how to apply license and NOTICE files.

[1] http://www.apache.org/dev/apply-license.html

On 12/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:

 -1
 the license/notice files are not located in META-INF
 but they are in the JAR, that's right. But they should be placed
 in META-INF.

 not sure if MYFACES-1790 is a showstopper.

 -M

 On Dec 19, 2007 11:11 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  I updated the dependency of the mfp to 126-SNAP.
  Did you notice that ?
 
  -M
 
 
  On Dec 19, 2007 8:49 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
   Hi,
  
   I was running the needed tasks to get the 1.2.1 release of Apache
   MyFaces core out.
  
   Please note that this vote concerns all of the following parts:
1. Maven artifact group org.apache.myfaces.shared v3.0.1  [1]
2. Maven artifact group org.apache.myfaces.core v1.2.1  [1]
  
   The artifacts are deployed to my private Apache account ([1]).
  
   Please take a look at the 1.2.0 artifacts and vote!
  
   Please note: This vote is majority approval with a minimum of three
   +1 votes (see [3]).
  
   
   [ ] +1 for community members who have reviewed the bits
   [ ] +0
   [ ] -1 for fatal flaws that should cause these bits not to be
 released,
   and why..
   
  
   Thanks,
   Leonardo Uribe
  
   [1] http://people.apache.org/~lu4242/myfaces121
   [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
  
 
 
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  mail: matzew-at-apache-dot-org
 



 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 mail: matzew-at-apache-dot-org




-- 
Grant Smith

[jira] Commented: (PORTLETBRIDGE-20) PortletConfig not added to the proper ELContext

2007-12-19 Thread Scott O'Bryan (JIRA)


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553519
 ] 

Scott O'Bryan commented on PORTLETBRIDGE-20:


I'm going to modify this patch to use the JDK 1.5 foreach notation.  It's a 
wash on performance and is a bit clearer to read.

 PortletConfig not added to the proper ELContext
 ---

 Key: PORTLETBRIDGE-20
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-20
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-SNAPSHOT
 Environment: Windows XP, eXo WebOS 2.0, snapshot as of 12/8, Tomcat 6
Reporter: Kito D. Mann
Assignee: Scott O'Bryan
 Attachments: jira_20.patch


 Currently, the portletConfig implicit variable consistently evaluates to 
 null. After stepping through the code, it looks as if BridgeImpl is adding 
 the PortletConfig object to the wrong ELContext. 
 BridgeImpl adds itself as an ELContext listener:
 // Add self as ELContextListener to the Faces App so we can add the
 // portletConfig to any newly created contexts.
 ApplicationFactory appFactory = 
   (ApplicationFactory) 
 FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
 Application app = appFactory.getApplication();
 app.addELContextListener(this);
 so that the following method gets called when a new ELContext is created:
   public void contextCreated(ELContextEvent ece)
   {
 // Add the portletConfig to the ELContext so it is evaluated
 ELContext elContext = ece.getELContext();
 // Only add if not already there
 if (elContext.getContext(PortletConfig.class) == null)
 {
   elContext.putContext(PortletConfig.class, mPortletConfig);
 }
   }
 However, it looks like this method is called by the JSP container (in Tomcat, 
 this is called by JspApplicationContextImpl.createELContext()). So, the 
 ELContext implementation passed in is the JSP container's ELContext, as 
 opposed to the one created by PortletFacesContext. So, when the 
 PorltetELResolver executes the following code in its getValue() method:
 case PORTLET_CONFIG:
   context.setPropertyResolved(true);
   return context.getContext(PortletConfig.class);
 It actually returns null, because it's checking the wrong context instance 
 (in this case, it's checking the PortletELContext, as expected).
 I'm not sure if this is the expected behavior of the container, but it would 
 explain by why the RI's FacesContextImpl doesn't call ELContextListeners 
 directly.

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

As I said; no vetos.
but we (Trinidad) got -1 and we were suggested to place them into
META-INF

That's what the maven-remote-resources-plugin does as well.

@Leonardo: did you use this plugin? Check the Trinidad profiles,
for the best version; they help a lot.

I really appreciate this release, since it is very good
(replacement of JARs w/ RI is possible), but I prefer
the files to be in META-INF...

Perhaps it is only me :-)

On Dec 19, 2007 11:23 PM, Grant Smith [EMAIL PROTECTED] wrote:
 I'm not sure where you're getting your information from. See [1] for
 instructions on where and how to apply license and NOTICE files.

 [1] http://www.apache.org/dev/apply-license.html



 On 12/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  -1
  the license/notice files are not located in META-INF
  but they are in the JAR, that's right. But they should be placed
  in META-INF.
 
  not sure if MYFACES-1790 is a showstopper.
 
  -M
 
  On Dec 19, 2007 11:11 PM, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
   I updated the dependency of the mfp to 126-SNAP.
   Did you notice that ?
  
   -M
  
  
   On Dec 19, 2007 8:49 PM, Leonardo Uribe  [EMAIL PROTECTED] wrote:
Hi,
   
I was running the needed tasks to get the 1.2.1 release of Apache
MyFaces core out.
   
Please note that this vote concerns all of the following parts:
 1. Maven artifact group org.apache.myfaces.shared v3.0.1  [1]
 2. Maven artifact group org.apache.myfaces.core  v1.2.1  [1]
   
The artifacts are deployed to my private Apache account ([1]).
   
Please take a look at the 1.2.0 artifacts and vote!
   
Please note: This vote is majority approval with a minimum of three
+1 votes (see [3]).
   

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

   
Thanks,
Leonardo Uribe
   
[1] http://people.apache.org/~lu4242/myfaces121
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes
   
  
  
  
   --
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   sessions: http://www.slideshare.net/mwessendorf
   mail: matzew-at-apache-dot-org
  
 
 
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  mail: matzew-at-apache-dot-org
 



 --
 Grant Smith




-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [Vote] release for myfaces 1.2.1

On Dec 19, 2007 11:31 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 As I said; no vetos.
 but we (Trinidad) got -1 and we were suggested to place them into
 META-INF

during incubation; I learned a lot there. Even I was already
around Apache years before

-M


 That's what the maven-remote-resources-plugin does as well.

 @Leonardo: did you use this plugin? Check the Trinidad profiles,
 for the best version; they help a lot.

 I really appreciate this release, since it is very good
 (replacement of JARs w/ RI is possible), but I prefer
 the files to be in META-INF...

 Perhaps it is only me :-)


 On Dec 19, 2007 11:23 PM, Grant Smith [EMAIL PROTECTED] wrote:
  I'm not sure where you're getting your information from. See [1] for
  instructions on where and how to apply license and NOTICE files.
 
  [1] http://www.apache.org/dev/apply-license.html
 
 
 
  On 12/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
   -1
   the license/notice files are not located in META-INF
   but they are in the JAR, that's right. But they should be placed
   in META-INF.
  
   not sure if MYFACES-1790 is a showstopper.
  
   -M
  
   On Dec 19, 2007 11:11 PM, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
I updated the dependency of the mfp to 126-SNAP.
Did you notice that ?
   
-M
   
   
On Dec 19, 2007 8:49 PM, Leonardo Uribe  [EMAIL PROTECTED] wrote:
 Hi,

 I was running the needed tasks to get the 1.2.1 release of Apache
 MyFaces core out.

 Please note that this vote concerns all of the following parts:
  1. Maven artifact group org.apache.myfaces.shared v3.0.1  [1]
  2. Maven artifact group org.apache.myfaces.core  v1.2.1  [1]

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

 Please take a look at the 1.2.0 artifacts and vote!

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

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

 Thanks,
 Leonardo Uribe

 [1] http://people.apache.org/~lu4242/myfaces121
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes

   
   
   
--
Matthias Wessendorf
   
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
   
  
  
  
   --
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   sessions: http://www.slideshare.net/mwessendorf
   mail: matzew-at-apache-dot-org
  
 
 
 
  --
  Grant Smith
 



 --

 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 mail: matzew-at-apache-dot-org




-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[jira] Resolved: (PORTLETBRIDGE-20) PortletConfig not added to the proper ELContext

2007-12-19 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan resolved PORTLETBRIDGE-20.


Resolution: Fixed

Thanks to Michael Freedman for the patch!

Committed r605725.

 PortletConfig not added to the proper ELContext
 ---

 Key: PORTLETBRIDGE-20
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-20
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-SNAPSHOT
 Environment: Windows XP, eXo WebOS 2.0, snapshot as of 12/8, Tomcat 6
Reporter: Kito D. Mann
Assignee: Scott O'Bryan
 Attachments: jira_20.patch


 Currently, the portletConfig implicit variable consistently evaluates to 
 null. After stepping through the code, it looks as if BridgeImpl is adding 
 the PortletConfig object to the wrong ELContext. 
 BridgeImpl adds itself as an ELContext listener:
 // Add self as ELContextListener to the Faces App so we can add the
 // portletConfig to any newly created contexts.
 ApplicationFactory appFactory = 
   (ApplicationFactory) 
 FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
 Application app = appFactory.getApplication();
 app.addELContextListener(this);
 so that the following method gets called when a new ELContext is created:
   public void contextCreated(ELContextEvent ece)
   {
 // Add the portletConfig to the ELContext so it is evaluated
 ELContext elContext = ece.getELContext();
 // Only add if not already there
 if (elContext.getContext(PortletConfig.class) == null)
 {
   elContext.putContext(PortletConfig.class, mPortletConfig);
 }
   }
 However, it looks like this method is called by the JSP container (in Tomcat, 
 this is called by JspApplicationContextImpl.createELContext()). So, the 
 ELContext implementation passed in is the JSP container's ELContext, as 
 opposed to the one created by PortletFacesContext. So, when the 
 PorltetELResolver executes the following code in its getValue() method:
 case PORTLET_CONFIG:
   context.setPropertyResolved(true);
   return context.getContext(PortletConfig.class);
 It actually returns null, because it's checking the wrong context instance 
 (in this case, it's checking the PortletELContext, as expected).
 I'm not sure if this is the expected behavior of the container, but it would 
 explain by why the RI's FacesContextImpl doesn't call ELContextListeners 
 directly.

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

Ok, i will put NOTICE and LICENSE on META-INF.

About MYFACES-1790, yes I noted this change on trunk:

plugin
  groupIdorg.apache.myfaces.trinidadbuild/groupId
  artifactIdmaven-faces-plugin/artifactId
  version1.2.6-SNAPSHOT/version
/plugin

for include this on this release we have to release this project too,
At start, for avoid this I switch back to 1.2.5 but if this is necessary
I'm not have problem to run the release procedure again. I'm on it.

Re: [Vote] release for myfaces 1.2.1

On Dec 19, 2007 11:39 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
 Ok, i will put NOTICE and LICENSE on META-INF.

cool! check the suggested maven-plugin;
late here in my timezone, I can help on that front
tomorrow.


 About MYFACES-1790, yes I noted this change on trunk:

 plugin
   groupIdorg.apache.myfaces.trinidadbuild/groupId
   artifactIdmaven-faces-plugin/artifactId
   version1.2.6-SNAPSHOT/version
 /plugin

 for include this on this release we have to release this project too

correct, but I am not sure if that is a blocker :-)
1.2.5 worked in the past, this bug was logged today;
I am cool with a 1.2.2 very soon ;-)

thanks for the work, so far!!

-M
,
 At start, for avoid this I switch back to 1.2.5 but if this is necessary
 I'm not have problem to run the release procedure again. I'm on it.




-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[jira] Created: (TOMAHAWK-1171) forceId doesn't work when page rendered after an 'immediate' action

2007-12-19 Thread Eric Price (JIRA)

forceId doesn't work when page rendered after an 'immediate' action
---

 Key: TOMAHAWK-1171
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1171
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: ForceId
Affects Versions: 1.1.3
 Environment: java 1.4.2_13, myfaces 1.1.4, tomahawk 1.1.3, windows XP
Reporter: Eric Price
Priority: Minor


I have a jsp with the following components:

   t:outputText value=Processed Date/Time:/
   t:panelGroup rendered=#{reportBean.dateCleared}
t:inputText styleClass=deactiveText title=-MM-dd 
   size=10 maxlength=10 readonly=true/
t:inputText styleClass=deactiveText title=HH:mm:ss 
  size=8 maxlength=8 readonly=true/
   /t:panelGroup
   t:panelGroup rendered=#{!reportBean.dateCleared}
t:inputText binding=#{reportBean.startDateInput} size=10
  maxlength=10 immediate=true 
  value=#{reportBean.startDate} title=-MM-dd 
  forceId=true id=processedDateStartDateInput
t:convertDateTime type=date pattern=-MM-dd/
/t:inputText
t:inputText binding=#{reportBean.startTimeInput} size=8
  maxlength=8 immediate=true 
  value=#{reportBean.startTime} title=HH:mm:ss 
  forceId=true id=processedDateStartTimeInput
t:convertDateTime type=time pattern=HH:mm:ss/
/t:inputText
   /t:panelGroup


When the page is initially displayed the value of reportBean.dateCleared is 
false, so the first two inputText components are displayed. The source of the 
page looks like:

td class=fieldLabelColumnProcessed Date/Time:/td
td class=defaultColumn
input id=mainform:_idJsp393 name=mainform:_idJsp393 
   type=text value= maxlength=10 readonly=readonly 
   size=10 title=-MM-dd class=deactiveText/
input id=mainform:_idJsp396 name=mainform:_idJsp396 
   type=text value= maxlength=8 readonly=readonly  
   size=8 title=HH:mm:ss class=deactiveText/
/td...


which shows what I would expect for the componet IDs.

The page also contains a jsCookMenu with an action method that causes the 
processed date fields to be set according to the user selection. The action 
method is executed with immediate=true set on the menu component.

Once the date is set, the reportBean.dateCleared is set to false and the 
current page is re-rendered. The selected date is correctly displayed in the 
date fields, but the component IDs are not set correctly. After setting the 
date and the page re-rendered, the source looks like:

td class=fieldLabelColumnProcessed Date/Time:/td
td class=defaultColumn
input id=mainform:processedDateStartDateInput 
  name=mainform:processedDateStartDateInput type=text 
  value=2007-12-15 maxlength=10 size=10 
  title=-MM-dd /
input id=mainform:processedDateStartTimeInput 
  name=mainform:processedDateStartTimeInput type=text 
  value=23:59:59 maxlength=8 size=8 
  title=HH:mm:ss/
/td


The component IDs have the specified value, but the form name is prepended.

Once I navigate to the next page of the application, and then navigate back to 
this page (via an action method on a button), I see the following source:

td class=fieldLabelColumnProcessed Date/Time:/td
td class=defaultColumn
input id=processedDateStartDateInput 
  name=processedDateStartDateInput type=text 
  value=2007-12-15 maxlength=10 size=10 
  title=-MM-dd /
input id=processedDateStartTimeInput
  name=processedDateStartTimeInput type=text 
  value=23:59:59 maxlength=8 size=8 
  title=HH:mm:ss/
/td


Now the component IDs are what I expected, just the ID without the form name 
prepended.

Any insight as to why the forceId doesn't appear to work when rendering the 
page after an (immediate) action, but it does work when rendering the page via 
navigation?

Thanks. 

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

[jira] Commented: (TRINIDAD-722) add trinidad-skins schema

2007-12-19 Thread Jeanne Waldman (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553554
 ] 

Jeanne Waldman commented on TRINIDAD-722:
-

There is a laf.xsd. It's old and not up-to-date. It's named laf.xsd because a 
long time ago skins were called laf. So ideally, we'd rename this file and 
probably move it somewhere where the schemas should go.

 add trinidad-skins schema
 -

 Key: TRINIDAD-722
 URL: https://issues.apache.org/jira/browse/TRINIDAD-722
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Reporter: Jeanne Waldman

 Currently there is no trinidad-skins.xsd file.
 This would be helpful for design-time products to help a user when they 
 create a trinidad-skins.xml file.

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

[jira] Commented: (MYFACES-1790) HtmlColumnTag.getComponentType returns the wrong value


[ 
https://issues.apache.org/jira/browse/MYFACES-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553560
 ] 

Leonardo Uribe commented on MYFACES-1790:
-

added in vote trinidad-build for fix this issue on 1.2.1 release

 HtmlColumnTag.getComponentType returns the wrong value
 --

 Key: MYFACES-1790
 URL: https://issues.apache.org/jira/browse/MYFACES-1790
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions:  1.2.0
Reporter: Cameron Bateman
Assignee: Matthias Weßendorf
 Fix For: 1.2.1


 According to the spec, the component type of the default h:column tag is 
 supposed to be javax.faces.Column, however HtmlColumnTag returns 
 javax.faces.HtmlColumn.

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

Hi

I have done the release procedure again including

  groupIdorg.apache.myfaces.trinidadbuild/groupId
  artifactIdmaven-plugin-parent/artifactId

For resolve MYFACES-1790 and moved LICENSE and NOTICE to META-INF
folder for both myfaces api and impl.

regards

Leonardo Uribe

Re: [Vote] release for myfaces 1.2.1

Hi,

I was running the needed tasks to get the 1.2.1 release of Apache
MyFaces core out.

Please note that this vote concerns all of the following parts:
 1. Maven artifact group org.apache.myfaces.shared v3.0.1  [1]
 2. Maven artifact group org.apache.myfaces.core v1.2.1  [1]
 3. Maven artifact group org.apache.myfaces.trinidadbuild v 1.2.6 [3]

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

Please take a look at the 1.2.1 artifacts and vote!

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

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


Thanks,
Leonardo Uribe

[1] http://people.apache.org/~lu4242/myfaces121
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes
[3] http://people.apache.org/~lu4242/trinidad-build126

Re: [Vote] release for myfaces 1.2.1

hi,

don't get me wrong; but fixing 1790 means the build
depends on a SNAPSHOT.

I can provide the RC for the 1.2.6 plugins today (for a vote)
That would fix the SNAPSHOT dependency.

Again, thanks for doing this!!!

-Matthias

On Dec 20, 2007 2:55 AM, Leonardo Uribe [EMAIL PROTECTED] wrote:
 Hi

 I have done the release procedure again including

   groupIdorg.apache.myfaces.trinidadbuild/groupId
   artifactIdmaven-plugin-parent/artifactId

 For resolve MYFACES-1790 and moved LICENSE and NOTICE to META-INF
 folder for both myfaces api and impl.

 regards

 Leonardo Uribe




-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [Trinidad] release of plugins

Ok, the RC will be around in some hours;
For MyFaces 1.2.1 we need it as well
(fix for MYFACES-1790)

-M

On Dec 19, 2007 7:55 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 since the issue isn't that bad, I've no problems in providing a
 RC bundle for 1.2.6, by tomorrow.
 That means, after the vote (3 days) the release would be out
 on 23th.

 After that 1.2.6, I'd also re-org the structure, by naming the plugins
 myfaces-dev-toolkit (discussion for that happens in another thread),
 etc.

 -Matthias


 On Dec 19, 2007 7:44 PM, Gary Kind [EMAIL PROTECTED] wrote:
  Matthias, this is fine with me.  I have a couple of changes to make in
  the jdev plugin, but they can wait until the next release.
  When do you plan to freeze for the 1.2.6 plugins release?
 
 
  Matthias Wessendorf wrote:
   Hi,
  
   there were several changes in the plugins;
   -JDEV
   -Trinidad
   -Commons
   -MyFaces
   etc.
  
   so, there are now some dependencies to SNAPSHOTS.
  
   I'd like to get the plugins 1.2.6 out and start (afterwards) the re-org.
   (see other thread for the re-org)
  
   Any veto (on the release)?
  
   -M
  
  
 




 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 mail: matzew-at-apache-dot-org




-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [Vote] release for myfaces 1.2.1

Hi,

this is confusing and not everybody notices a vote for the trinidad plugins,
that is nested in a myfaces-core release vote :-)

As I said on a different thread (the one that talks about the plugins
release), I'll get
https://issues.apache.org/jira/browse/TRINIDAD-878
done as well. Fix is trivial, but I need some more testing

-Matthias


On Dec 20, 2007 2:58 AM, Leonardo Uribe [EMAIL PROTECTED] wrote:
 Hi,

 I was running the needed tasks to get the 1.2.1 release of Apache
 MyFaces core out.

 Please note that this vote concerns all of the following parts:
  1. Maven artifact group org.apache.myfaces.shared v3.0.1  [1]
  2. Maven artifact group org.apache.myfaces.core v1.2.1  [1]
  3. Maven artifact group org.apache.myfaces.trinidadbuild v 1.2.6 [3]

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

 Please take a look at the 1.2.1 artifacts and vote!

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

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

 Thanks,
 Leonardo Uribe

 [1] http://people.apache.org/~lu4242/myfaces121
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 [3] http://people.apache.org/~lu4242/trinidad-build126




-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [Vote] release for myfaces 1.2.1

Hi

The problem is that if we want to solve MYFACES-1790 for this release,
we need to
release trinidad build as well. I also prepare the release of trinidad
build on my private account here:

http://people.apache.org/~lu4242/trinidad-build126

and I wrote the steps done on

http://wiki.apache.org/myfaces/CoreRelease121

Based on this, I prepare the release again. So no snapshots dependencies left.

I understand that involve trinidad build in this vote tends to be confusing.
But the question to be solved is what to best? rollback? separate the
vote? let it as is?.

I'm open to hear all suggestions.

Leonardo Uribe

Re: [Vote] release for myfaces 1.2.1

 I understand that involve trinidad build in this vote tends to be confusing.
 But the question to be solved is what to best? rollback? separate the
 vote? let it as is?.

just send out a different mail on the Trinidad Plugins
release, and you'll get my +1

-Matthias


 I'm open to hear all suggestions.

 Leonardo Uribe




-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[Vote] release for Trinidad Plugins 1.2.6

Hi,

I was running the needed tasks to get the 1.2.6 release of Trinidad
Plugins out.

This task is necessary for release Myfaces 1.2.1, because it uses faces plugin.

Please note that this vote concerns all of the following parts:
 1. Maven artifact group org.apache.myfaces.trinidadbuild v 1.2.6 [1]

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

Please take a look at the 1.2.6 artifacts and vote!

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

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


Thanks,
Leonardo Uribe

[1] http://people.apache.org/~lu4242/trinidad-build126
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: [Vote] release for myfaces 1.2.1


On Wed, 2007-12-19 at 20:55 -0500, Leonardo Uribe wrote:
 Hi
 
 I have done the release procedure again including
 
   groupIdorg.apache.myfaces.trinidadbuild/groupId
   artifactIdmaven-plugin-parent/artifactId
 
 For resolve MYFACES-1790 and moved LICENSE and NOTICE to META-INF
 folder for both myfaces api and impl.

The convention used in apache commons is that each module has a
LICENSE.txt and NOTICE.txt file in its root directory, ie next to the
pom.xml file and then they are output into the jar using a resource
definition in the pom:

  resource
directory./directory
targetPathMETA-INF/targetPath
includes
  includeNOTICE.txt/include
  includeLICENSE.txt/include
/includes
  /resource

This means that people who check out the code (or browse the repository
online) see the LICENSE and NOTICE in the obvious place (first dir that
anyone sees), but the jar has it in *its* obvious place (with the rest
of the jar meta-data). Having the NOTICE in the module root dir also
means developers are more likely to keep it up-to-date if adding code
with special license conditions.

I would highly recommend using this approach for myfaces too. But it's
not a release-blocker IMO, as the license/notice *are* in svn and in the
jar.

As it happens, there is quite a vigorous discussion going on right now
in both apache commons and legal-discuss lists regarding NOTICE and
LICENSE files. Some people would like to use a maven feature to
auto-generate LICENSE and NOTICE files. This is quite controversial,
though, and a number of people prefer the existing apache-commons way
(including myself).

Regards,

Simon

Re: [Vote] release for myfaces 1.2.1

 As it happens, there is quite a vigorous discussion going on right now
 in both apache commons and legal-discuss lists regarding NOTICE and
 LICENSE files. Some people would like to use a maven feature to
 auto-generate LICENSE and NOTICE files. This is quite controversial,
 though, and a number of people prefer the existing apache-commons way
 (including myself).

I like having them in the root folder, like done in Trinidad
https://svn.apache.org/repos/asf/myfaces/trinidad/trunk_1.2.x/

but, the auto-generation plugins is fine for including them in
every JAR. Trinidad uses that plugin as well.

-M


 Regards,

 Simon






-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [Vote] release for myfaces 1.2.1

Thanks for replacing the bits.

+1

-Matthias

On Dec 19, 2007 9:13 PM, simon [EMAIL PROTECTED] wrote:

 On Wed, 2007-12-19 at 11:54 -0800, Grant Smith wrote:
  +1

 That was very quick, Grant!

 Have you really inspected all the artifacts Leonardo created to see if
 they are right? Licenses need to be correct, MANIFEST files should be
 double-checked, checksums verified, etc.

 Regards,

 Simon





-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [Vote] release for myfaces 1.2.1

the plugin includes the notice/license
if not present, it generates them

-M

On Dec 20, 2007 8:06 AM, simon [EMAIL PROTECTED] wrote:

 On Thu, 2007-12-20 at 07:52 +0100, Matthias Wessendorf wrote:
   As it happens, there is quite a vigorous discussion going on right now
   in both apache commons and legal-discuss lists regarding NOTICE and
   LICENSE files. Some people would like to use a maven feature to
   auto-generate LICENSE and NOTICE files. This is quite controversial,
   though, and a number of people prefer the existing apache-commons way
   (including myself).
 
  I like having them in the root folder, like done in Trinidad
  https://svn.apache.org/repos/asf/myfaces/trinidad/trunk_1.2.x/
 
  but, the auto-generation plugins is fine for including them in
  every JAR. Trinidad uses that plugin as well.

 ??

 Do you mean there is a license and notice checked in, but the built jar
 ignores these and uses something different instead? That sounds like the
 worst of both worlds to me. It would:
 (a) double the work, as *both* need to be checked for correctness, and
 (b) is really confusing for users if they differ.


 Regards,

 Simon





-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [Vote] release for Trinidad Plugins 1.2.6

2007-12-19 Thread Bernd Bohmann

Hello,

are the release notes correct?

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

Regards

Bernd

Matthias Wessendorf schrieb:
 +1
 
 On Dec 20, 2007 7:39 AM, Leonardo Uribe [EMAIL PROTECTED] wrote:
 Hi,

 I was running the needed tasks to get the 1.2.6 release of Trinidad
 Plugins out.

 This task is necessary for release Myfaces 1.2.1, because it uses faces 
 plugin.

 Please note that this vote concerns all of the following parts:
  1. Maven artifact group org.apache.myfaces.trinidadbuild v 1.2.6 [1]

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

 Please take a look at the 1.2.6 artifacts and vote!

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

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

 Thanks,
 Leonardo Uribe

 [1] http://people.apache.org/~lu4242/trinidad-build126
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: [Vote] release for Trinidad Plugins 1.2.6

Ouch!

I ignored that there is a version management inside trinidad for this.
I will solve it soon

regards

Leonardo Uribe

Re: [Vote] release for Trinidad Plugins 1.2.6

Hi

After looking JIRA I'm not have found more issues to be added on the
release notes. This release is
necessary for release myfaces 1.2.1, to solve an error (MYFACES-1790)
on faces plugin that where annotated on myfaces core project

regards

Leonardo Uribe

Re: [Vote] release for Trinidad Plugins 1.2.6