[jira] Created: (TRINIDAD-1293) AttributeComponentChange throws an IllegalArgumentException when attributeValue is null

2008-11-07 Thread Andrew Robinson (JIRA)
AttributeComponentChange throws an IllegalArgumentException when attributeValue 
is null
---

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


AttributeComponentChange throws an IllegalArgumentException when attributeValue 
is null when it checks to see if the value is serializable.

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



Patches available

2008-11-07 Thread Tadashi Enomori

Hello,

Just a heads up... I would appreciate if someone can review, and commit 
upon approval, the following patches (mobile).


TRINIDAD-1263 
TRINIDAD-1264 
TRINIDAD-1266 
TRINIDAD-1272 

Thanks,
Tadashi


[jira] Updated: (TOMAHAWK-1365) Input field id in error messages is not properly replaced with label text

2008-11-07 Thread Leonardo Uribe (JIRA)

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

Leonardo Uribe updated TOMAHAWK-1365:
-

   Resolution: Fixed
Fix Version/s: 1.1.8-SNAPSHOT
 Assignee: Leonardo Uribe
   Status: Resolved  (was: Patch Available)

> Input field id in error messages is not properly replaced with label text
> -
>
> Key: TOMAHAWK-1365
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1365
> Project: MyFaces Tomahawk
>  Issue Type: Bug
>  Components: Message(s)
>Affects Versions: 1.1.8-SNAPSHOT
>Reporter: Val Blant
>Assignee: Leonardo Uribe
> Fix For: 1.1.8-SNAPSHOT
>
> Attachments: TOMAHAWK-1365.patch
>
>
> When we have a label associated with an input field via the 'for' attribute 
> on the label, the client id substitution is not properly handled by 
> org.apache.myfaces.renderkit.html.ext.HtmlMessageRenderer.findInputId().
> The problem is that when an error message is put together by a converter, 
> javax.faces.convert._MessageUtils.getLabel() places the full clientId of the 
> input component into the message text, whereas HtmlMessageRenderer replaces 
> only the id with the label text.

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



Re: [Trinidad] a roadmap ?

2008-11-07 Thread Grant Smith
+1

However, is there any chance of clearing out some of the branches/ in the
svn repo ? Theres a ton of branches, do we really need them all ? Doing a
clean myfaces/ checkout was a real pain with all that extra bloat.

On Fri, Nov 7, 2008 at 10:53 AM, Cagatay Civici <[EMAIL PROTECTED]>wrote:

> +1
>
> Cagatay
>
>
> On Fri, Nov 7, 2008 at 5:07 PM, Gerhard Petracek <
> [EMAIL PROTECTED]> wrote:
>
>> +1
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2008/11/7 Andrew Robinson <[EMAIL PROTECTED]>
>>
>> I am all for making 1.2 the trunk and 1.0 a support-based branch
>>>
>>> -Andrew
>>>
>>> On Fri, Nov 7, 2008 at 1:16 AM, Matthias Wessendorf <[EMAIL PROTECTED]>
>>> wrote:
>>> > Hi folks,
>>> >
>>> > currently we support both, JSF 1.1 and JSF 1.2. The JSF 1.1, however
>>> > is the real trunk and JSF 1.2 is kinda a stepchild like trunk.
>>> > I'd like to *swap* the trunks.
>>> >
>>> > trunk -> JSF 1.2 based Trinidad
>>> > trunk1x -> JSF 1.1 based Trinidad
>>> >
>>> > Also, I'd like focus for upcoming releases (not the next 1.x.10
>>> > release) more on the JSF 1.2 version of Trinidad, at least for *big*
>>> > improvements (like fixing memory leaks, HA support, etc.) or
>>> > enhancements (new (api) features).
>>> >
>>> > I think technically that would mean, the 1.0.n version kinda go into a
>>> > maintaining stage, where we "only" apply (serious) bug fixes.
>>> >
>>> > Also, when we move to JSF 2.0 (yes... that may take a bit since a)
>>> > spec isn't final b) nobody will use it before 2010) it would make
>>> > sense
>>> > to kinda focus only on JSF 1.2, since applying those *new* 2.0
>>> > features require JSF 1.2.
>>> >
>>> > Based the communities feedback, I'd like to write a wiki page, that
>>> > has a more detailed outline.
>>> >
>>> > -Matthias
>>> >
>>> > --
>>> > Matthias Wessendorf
>>> >
>>> > blog: http://matthiaswessendorf.wordpress.com/
>>> > sessions: http://www.slideshare.net/mwessendorf
>>> > twitter: http://twitter.com/mwessendorf
>>> >
>>>
>>
>>
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>
>


-- 
Grant Smith


[jira] Resolved: (MYFACES-2033) Change the main download page to reference the sub project download pages

2008-11-07 Thread Grant Smith (JIRA)

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

Grant Smith resolved MYFACES-2033.
--

Resolution: Fixed

Done. Should filter through to mirrors in 6 hours.

> Change the main download page to reference the sub project download pages 
> --
>
> Key: MYFACES-2033
> URL: https://issues.apache.org/jira/browse/MYFACES-2033
> Project: MyFaces Core
>  Issue Type: Task
>  Components: website
>Reporter: Grant Smith
>Assignee: Grant Smith
>Priority: Minor
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Description says it all. We have download pages on all the sub projects, and 
> another "global" download page for everything again. It's redundant and a 
> pain to maintain.

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



[jira] Resolved: (MYFACES-654) HTML TLD differences between myFaces and the RI

2008-11-07 Thread Grant Smith (JIRA)

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

Grant Smith resolved MYFACES-654.
-

Resolution: Fixed

This should no longer be an issue due to the new builder-plugin's automatic 
generation of tags, etc.

> HTML TLD differences between myFaces and the RI
> ---
>
> Key: MYFACES-654
> URL: https://issues.apache.org/jira/browse/MYFACES-654
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.4.1-SNAPSHOT, 
> 1.1.5-SNAPSHOT
>Reporter: Manfred Klug
>Assignee: Grant Smith
> Attachments: AbstractTagLibTestCase.java, 
> ReferenceImplementationCompareTestCase.java
>
>
> There are still differences in the possible attributes between myFaces and 
> the RI.
> myFaces attributes not in the RI:
>   commandButton
> size
>   commandLink
> onclick
>   dataTable
> align
> datafld
> dataformatas
> datasrc
>   form
> name
>   inputSecret
> align
>   inputText
> align
>   inputTextarea
> datafld
> dataformatas
> datasrc
>   message
> dir
> lang
> onclick
> ondblclick
> onkeydown
> onkeypress
> onkeyup
> onmousedown
> onmousemove
> onmouseout
> onmouseover
> onmouseup
>   messages
> dir
> lang
> onclick
> ondblclick
> onkeydown
> onkeypress
> onkeyup
> onmousedown
> onmousemove
> onmouseout
> onmouseover
> onmouseup
>   outputFormat
> dir
> lang
> onclick
> ondblclick
> onkeydown
> onkeypress
> onkeyup
> onmousedown
> onmousemove
> onmouseout
> onmouseover
> onmouseup
>   outputText
> dir
> lang
> onclick
> ondblclick
> onkeydown
> onkeypress
> onkeyup
> onmousedown
> onmousemove
> onmouseout
> onmouseover
> onmouseup
>   panelGrid
> align
> datafld
> dataformatas
> datasrc
>   panelGroup
> dir
> lang
> onclick
> ondblclick
> onkeydown
> onkeypress
> onkeyup
> onmousedown
> onmousemove
> onmouseout
> onmouseover
> onmouseup
> title
>   selectBooleanCheckbox
> alt
> datafld
> dataformatas
> datasrc
>   selectManyCheckbox
> alt
> datafld
> dataformatas
> datasrc
>   selectManyListbox
> datafld
> dataformatas
> datasrc
>   selectManyMenu
> datafld
> dataformatas
> datasrc
>   selectOneListbox
> datafld
> dataformatas
> datasrc
>   selectOneMenu
> datafld
> dataformatas
> datasrc
>   selectOneRadio
> alt
> datafld
> dataformatas
> datasrc
> --
> Attributes missing in myFaces:
>   commandButton
> readonly
>   outputLabel
> tabindex
>   selectManyCheckbox
> border
>   selectManyListbox
> accesskey
> onselect
>   selectManyMenu
> accesskey
> onselect
>   selectOneListbox
> accesskey
> onselect
>   selectOneMenu
> accesskey
> onselect
> --
> Case difference:
>   form
> acceptCharset <-> acceptcharset

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



[RESULTS] Release of Trinidad Plugins 1.2.8

2008-11-07 Thread Scott O'Bryan

Vote passed with 7 +1 votes from:

 Andrew Robinson
 Matthias Wessendorf
 Scott O'Bryan
 Grant Smith
 Cagatay Civici
 Matt Cooper
 Bruno Aranda

No +0 or -1 votes.  Wow..  That was painless.  :)

Thanks to everyone, I'll distribute the artifacts, update the documents, 
and send out a message to the lists.


Scott



Grant Smith wrote:

+1

On Tue, Nov 4, 2008 at 3:02 PM, Matthias Wessendorf <[EMAIL PROTECTED] 
> wrote:


+1

On Tue, Nov 4, 2008 at 11:59 PM, Andrew Robinson
<[EMAIL PROTECTED]
> wrote:
> +1
> (verified new code working as intented in maven-faces-plugin & the
> binary sigs for the sha1 & md5 on that jar)
>
> -Andrew
>
> On Tue, Nov 4, 2008 at 3:20 PM, Scott O'Bryan
<[EMAIL PROTECTED] > wrote:
>> Hi,
>>
>> I was running the needed tasks to get the 1.2.8 release of the
Apache
>> MyFaces Trinidad Maven 2 Plugins.
>>
>> The artifacts are deployed to my private Apache account ([1]).
>>
>> Please take a look at the "1.2.8" artifacts and vote.
>>
>> How to test those JARs ?
>>
>> Use the stage repo inside your pom.xml file:
>> ...
>> 
>> 
>> apache.stage
>> Apache Stage Repository
>> http://people.apache.org/~sobryan/trinidad-maven/1.2.8

>> default
>> 
>> 
>> ...
>>
>> 
>> [ ] +1 for community members who have reviewed and tested the bits
>> [ ] +0
>> [ ] -1 for fatal flaws that should cause these bits not to be
released,
>> and why..
>> 
>>
>> Thanks,
>> Scott
>>
>> [1] http://people.apache.org/~sobryan/trinidad-maven/1.2.8

>>
>>
>



--
Matthias Wessendorf

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




--
Grant Smith





Re: [Trinidad] a roadmap ?

2008-11-07 Thread Cagatay Civici
+1

Cagatay

On Fri, Nov 7, 2008 at 5:07 PM, Gerhard Petracek <[EMAIL PROTECTED]
> wrote:

> +1
>
> regards,
> gerhard
>
>
>
> 2008/11/7 Andrew Robinson <[EMAIL PROTECTED]>
>
> I am all for making 1.2 the trunk and 1.0 a support-based branch
>>
>> -Andrew
>>
>> On Fri, Nov 7, 2008 at 1:16 AM, Matthias Wessendorf <[EMAIL PROTECTED]>
>> wrote:
>> > Hi folks,
>> >
>> > currently we support both, JSF 1.1 and JSF 1.2. The JSF 1.1, however
>> > is the real trunk and JSF 1.2 is kinda a stepchild like trunk.
>> > I'd like to *swap* the trunks.
>> >
>> > trunk -> JSF 1.2 based Trinidad
>> > trunk1x -> JSF 1.1 based Trinidad
>> >
>> > Also, I'd like focus for upcoming releases (not the next 1.x.10
>> > release) more on the JSF 1.2 version of Trinidad, at least for *big*
>> > improvements (like fixing memory leaks, HA support, etc.) or
>> > enhancements (new (api) features).
>> >
>> > I think technically that would mean, the 1.0.n version kinda go into a
>> > maintaining stage, where we "only" apply (serious) bug fixes.
>> >
>> > Also, when we move to JSF 2.0 (yes... that may take a bit since a)
>> > spec isn't final b) nobody will use it before 2010) it would make
>> > sense
>> > to kinda focus only on JSF 1.2, since applying those *new* 2.0
>> > features require JSF 1.2.
>> >
>> > Based the communities feedback, I'd like to write a wiki page, that
>> > has a more detailed outline.
>> >
>> > -Matthias
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > blog: http://matthiaswessendorf.wordpress.com/
>> > sessions: http://www.slideshare.net/mwessendorf
>> > twitter: http://twitter.com/mwessendorf
>> >
>>
>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>


problem with UIColumns and HtmlSelectBooleanCheckbox

2008-11-07 Thread kpv

hi!
In my project I need to create dynamically a table (Rows and Columns are
created dynamically)
to do this UIColumns is used.
every cell rendering is performed in AdapterComponent that takes as an input
current row and current column.
AdapterComponent is a child of UIColumns;
AdapterComponent extends HtmlPanelGroup and can contain as a child
HtmlOutputText object etc.
Problems appear when AdapterComponent contains as a child
HtmlSelectBooleanCheckbox object:
(even more: every implementation of EditableValueHolder interface).

java.lang.NullPointerException
at
org.apache.myfaces.custom.crosstable.UIColumns.restoreDescendantComponentStates(UIColumns.java:197)
at
org.apache.myfaces.custom.crosstable.UIColumns.restoreDescendantComponentStates(UIColumns.java:200)
at
org.apache.myfaces.custom.crosstable.UIColumns.restoreDescendantComponentStates(UIColumns.java:200)
at
org.apache.myfaces.custom.crosstable.UIColumns.setRowIndex(UIColumns.java:152)
at javax.faces.component.UIData.encodeEnd(UIData.java:368)
at
org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:450)
at
org.apache.myfaces.renderkit.html.ext.HtmlTableRenderer.renderColumnBody(HtmlTableRenderer.java:206)
at
org.apache.myfaces.renderkit.html.ext.HtmlTableRenderer.encodeColumnChild(HtmlTableRenderer.java:169)
at
org.apache.myfaces.renderkit.html.HtmlTableRendererBase.encodeInnerHtml(HtmlTableRendererBase.java:154)
at
org.apache.myfaces.renderkit.html.HtmlTableRendererBase.encodeChildren(HtmlTableRendererBase.java:94)
at
org.apache.myfaces.renderkit.html.ext.HtmlTableRenderer.encodeChildren(HtmlTableRenderer.java:57)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:319)
at
org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:444)
at
org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427)
...

   any ideas?
-- 
View this message in context: 
http://www.nabble.com/problem-with-UIColumns-and-HtmlSelectBooleanCheckbox-tp20386203p20386203.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.



[jira] Created: (TRINIDAD-1292) Use javax.faces.context.ResponseWriterWrapper in 1.2 trunk

2008-11-07 Thread Jeanne Waldman (JIRA)
Use javax.faces.context.ResponseWriterWrapper in 1.2 trunk
--

 Key: TRINIDAD-1292
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1292
 Project: MyFaces Trinidad
  Issue Type: Improvement
Reporter: Jeanne Waldman
Priority: Minor


Currently in Trinidad we use our own ResponseWriterDecorator from package 
org.apache.myfaces.trinidadinternal.io.

In the 1.2 branch, we should use the public API 
javax.faces.context.ResponseWriterWrapper instead.

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



Re: [Trinidad] a roadmap ?

2008-11-07 Thread Gerhard Petracek
+1

regards,
gerhard



2008/11/7 Andrew Robinson <[EMAIL PROTECTED]>

> I am all for making 1.2 the trunk and 1.0 a support-based branch
>
> -Andrew
>
> On Fri, Nov 7, 2008 at 1:16 AM, Matthias Wessendorf <[EMAIL PROTECTED]>
> wrote:
> > Hi folks,
> >
> > currently we support both, JSF 1.1 and JSF 1.2. The JSF 1.1, however
> > is the real trunk and JSF 1.2 is kinda a stepchild like trunk.
> > I'd like to *swap* the trunks.
> >
> > trunk -> JSF 1.2 based Trinidad
> > trunk1x -> JSF 1.1 based Trinidad
> >
> > Also, I'd like focus for upcoming releases (not the next 1.x.10
> > release) more on the JSF 1.2 version of Trinidad, at least for *big*
> > improvements (like fixing memory leaks, HA support, etc.) or
> > enhancements (new (api) features).
> >
> > I think technically that would mean, the 1.0.n version kinda go into a
> > maintaining stage, where we "only" apply (serious) bug fixes.
> >
> > Also, when we move to JSF 2.0 (yes... that may take a bit since a)
> > spec isn't final b) nobody will use it before 2010) it would make
> > sense
> > to kinda focus only on JSF 1.2, since applying those *new* 2.0
> > features require JSF 1.2.
> >
> > Based the communities feedback, I'd like to write a wiki page, that
> > has a more detailed outline.
> >
> > -Matthias
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
>



-- 

http://www.irian.at

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

Professional Support for Apache MyFaces


Re: [Trinidad] a roadmap ?

2008-11-07 Thread Andrew Robinson
I am all for making 1.2 the trunk and 1.0 a support-based branch

-Andrew

On Fri, Nov 7, 2008 at 1:16 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> currently we support both, JSF 1.1 and JSF 1.2. The JSF 1.1, however
> is the real trunk and JSF 1.2 is kinda a stepchild like trunk.
> I'd like to *swap* the trunks.
>
> trunk -> JSF 1.2 based Trinidad
> trunk1x -> JSF 1.1 based Trinidad
>
> Also, I'd like focus for upcoming releases (not the next 1.x.10
> release) more on the JSF 1.2 version of Trinidad, at least for *big*
> improvements (like fixing memory leaks, HA support, etc.) or
> enhancements (new (api) features).
>
> I think technically that would mean, the 1.0.n version kinda go into a
> maintaining stage, where we "only" apply (serious) bug fixes.
>
> Also, when we move to JSF 2.0 (yes... that may take a bit since a)
> spec isn't final b) nobody will use it before 2010) it would make
> sense
> to kinda focus only on JSF 1.2, since applying those *new* 2.0
> features require JSF 1.2.
>
> Based the communities feedback, I'd like to write a wiki page, that
> has a more detailed outline.
>
> -Matthias
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>


[jira] Resolved: (EXTVAL-6) Create assembly project for examples

2008-11-07 Thread Leonardo Uribe (JIRA)

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

Leonardo Uribe resolved EXTVAL-6.
-

   Resolution: Fixed
Fix Version/s: 1.2.1-SNAPSHOT
   1.0.1-SNAPSHOT

> Create assembly project for examples
> 
>
> Key: EXTVAL-6
> URL: https://issues.apache.org/jira/browse/EXTVAL-6
> Project: MyFaces Extensions Validator
>  Issue Type: Task
>Affects Versions: 1.0.1-SNAPSHOT, 1.2.1-SNAPSHOT
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 1.0.1-SNAPSHOT, 1.2.1-SNAPSHOT
>
>


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



[jira] Updated: (TRINIDAD-1278) Don't display "-" in error message when label is null.

2008-11-07 Thread JIRA

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

Matthias Weßendorf updated TRINIDAD-1278:
-

   Resolution: Fixed
Fix Version/s: 1.0.10-core
   1.2.10-core
 Assignee: Matthias Weßendorf
   Status: Resolved  (was: Patch Available)

> Don't display "-" in error message when label is null.
> --
>
> Key: TRINIDAD-1278
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1278
> Project: MyFaces Trinidad
>  Issue Type: Bug
>Affects Versions: 1.2.9-core
>Reporter: Cale Scholl
>Assignee: Matthias Weßendorf
>Priority: Minor
> Fix For: 1.2.10-core, 1.0.10-core
>
> Attachments: 1.2.9.1_noDash.patch, trunk11_noDash.patch, 
> trunk12_noDash.patch
>
>
> When the label is null, the error message printed at the top of the screen 
> will be something like "- Invalid data". The "-" looks unsightly without any 
> text preceding it, so we shouldn't render it.

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



[jira] Updated: (TRINIDAD-1265) safari:buttons in navigation pane display only vertically

2008-11-07 Thread JIRA

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

Matthias Weßendorf updated TRINIDAD-1265:
-

   Resolution: Fixed
Fix Version/s: 1.0.10-core
   1.2.10-core
 Assignee: Matthias Weßendorf
   Status: Resolved  (was: Patch Available)

> safari:buttons in navigation pane display only vertically
> -
>
> Key: TRINIDAD-1265
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1265
> Project: MyFaces Trinidad
>  Issue Type: Bug
>  Components: Components
>Affects Versions: 1.2.9-core
> Environment: Windows and linux
>Reporter: Agam Dass
>Assignee: Matthias Weßendorf
>Priority: Minor
> Fix For: 1.2.10-core, 1.0.10-core
>
> Attachments: trinidadNavigationPane_safari_7268626.patch
>
>
> Problem
> ---
> Safari: commandNavigationItems are always displayed vertically when placed
> inside a NavigationPane
> The same buttons are displayed horizontally in FIrefox
> To Reproduce
> 
> 1. use the foll in the page
> 
>   
> 
> 
>   
> 
>   
>   
> 
> 
> 
> 
>   
> 
> 2. Run the page and note the items are displayed vertically 

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



[Trinidad] a roadmap ?

2008-11-07 Thread Matthias Wessendorf
Hi folks,

currently we support both, JSF 1.1 and JSF 1.2. The JSF 1.1, however
is the real trunk and JSF 1.2 is kinda a stepchild like trunk.
I'd like to *swap* the trunks.

trunk -> JSF 1.2 based Trinidad
trunk1x -> JSF 1.1 based Trinidad

Also, I'd like focus for upcoming releases (not the next 1.x.10
release) more on the JSF 1.2 version of Trinidad, at least for *big*
improvements (like fixing memory leaks, HA support, etc.) or
enhancements (new (api) features).

I think technically that would mean, the 1.0.n version kinda go into a
maintaining stage, where we "only" apply (serious) bug fixes.

Also, when we move to JSF 2.0 (yes... that may take a bit since a)
spec isn't final b) nobody will use it before 2010) it would make
sense
to kinda focus only on JSF 1.2, since applying those *new* 2.0
features require JSF 1.2.

Based the communities feedback, I'd like to write a wiki page, that
has a more detailed outline.

-Matthias

-- 
Matthias Wessendorf

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


[jira] Resolved: (TRINIDAD-1291) ThreadLocalUtils blows up if a referenced ThreadLocal has been GC'ed

2008-11-07 Thread JIRA

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

Matthias Weßendorf resolved TRINIDAD-1291.
--

   Resolution: Fixed
Fix Version/s: 1.2.10-core

> ThreadLocalUtils blows up if a referenced ThreadLocal has been GC'ed
> 
>
> Key: TRINIDAD-1291
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1291
> Project: MyFaces Trinidad
>  Issue Type: Bug
>  Components: Archetype
>Affects Versions: 1.2.9-core
> Environment: All
>Reporter: Blake Sullivan
>Assignee: Jeanne Waldman
> Fix For: 1.2.10-core
>
> Attachments: JIRA_1291_12MAIN.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> When iterating through the list of WeakReferences to remove from 
> the current thread, ThreadLocalUtils notices when a WeakReference is empty 
> because the ThreadLocal has been GC'ed and attempts to remove the entry from 
> the iterator so that we won't have to check it on the next request.  
> Unfortunately, the iterator is backed by a CopyOnWriteArrayList, so this 
> throws an UnsupportedOperationException

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