New snapshots of MyFaces Core 1.1.4 are available:
http://people.apache.org/builds/myfaces/core-1.1.x/
Please see the release plan wiki page for more information:
http://wiki.apache.org/myfaces/CoreRelease114
--
Wendy
Thanks!
(I asked Wendy to check out the shared_203 branch and core_114 to
provide a new RC/snapshot)
-Matthias
On 8/2/06, Wendy Smoak [EMAIL PROTECTED] wrote:
New snapshots of MyFaces Core 1.1.4 are available:
http://people.apache.org/builds/myfaces/core-1.1.x/
Please see the release
greeetz
On 8/1/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Ladies(!) and Gentlemen,
Please welcome our new MyFaces PMC member Mario Ivankovits!
Mario has been a well known MyFaces contributor and committer for some
time and helped out on many places within the MyFaces world. Therefore
[
http://issues.apache.org/jira/browse/TOMAHAWK-523?page=comments#action_12425453
]
Ronald Müller commented on TOMAHAWK-523:
you' re mike. but the itention of this bug-report is to discuss and determine
that
1.) it is is definitly a
I have written an autogenerator for the facelets-taglib. Maybe we can
use this one.
What about adding new MyFaces examples using facelets? We will need it
to test tomahawk facelet support.
On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Yes, I know...
there is also the Trinidad
[
http://issues.apache.org/jira/browse/TOMAHAWK-566?page=comments#action_12425459
]
Stefan Willems commented on TOMAHAWK-566:
-
No, I didn't meant that the issue is closed, I simply corrected my description.
groupBy doesn't work with
Hello,
I’m working on a web application using MyFaces 1.1.1 and I have a bug during
validation process.
I tried MyFaces 1.1.5 snapshot and I have the same problem.
Here is my simple test case to reproduce the bug :
Put only two fields in a form :
- first has a number converter
-
Hello all,
maybe this group is a better place for my question
below.
Can someone please tell me if this is a bug or if it works
as designed?
Roland
Von: Schaal, Roland Gesendet: Montag,
31. Juli 2006 09:44An: MyFaces DiscussionBetreff: bug in
panelTab? was: access attributes of
[
http://issues.apache.org/jira/browse/TOMAHAWK-325?page=comments#action_12425490
]
Alexander Langer commented on TOMAHAWK-325:
---
Is there a reason you removed the escape attribute with this patch, or was it
by mistake when trying to
Problem with f:convertDateTime Component giving the day before the correct one
--
Key: MYFACES-1378
URL: http://issues.apache.org/jira/browse/MYFACES-1378
Project: MyFaces
panelNavigation2 JavaScript problem
---
Key: TOMAHAWK-580
URL: http://issues.apache.org/jira/browse/TOMAHAWK-580
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Panel Navigation2
Affects
[
http://issues.apache.org/jira/browse/TOMAHAWK-325?page=comments#action_12425506
]
Mike Kienenberger commented on TOMAHAWK-325:
Alexander,
This patch has been in place long enough that it's unlikely to be reverted.
I'd recommend
What about adding new MyFaces examples using facelets? We will need it
to test tomahawk facelet support.
I am currently writing such an example over at Shale (just getting it
started.) It uses Shale, MyFaces, Tomahawk, Facelets, Hibernate and
Spring. IMO this single example would suffice for
On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
As for the getScrolling issue, I could've sworn this worked in the
latest simple examples *before* I switched in the rc core api jars.
Maybe I'm wrong though ... I will try to investigate further.
with 1.1.5 yes; the getScrolling is now
So is there a new RC we should be testing against? I can update it
with the latest branch later today perhaps.
Sean
On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
@Tomahawk_1_1_4 branch:
works, when you compile against the *patched* shared-203
On 8/2/06, Matthias Wessendorf
On 8/3/06, Thomas Spiegl [EMAIL PROTECTED] wrote:
I have written an autogenerator for the facelets-taglib. Maybe we can
use this one.
It seems like extra work to maintain two generators when they both
generate the same kind of information.
What about adding new MyFaces examples using
On 8/2/06, Sean Schofield [EMAIL PROTECTED] wrote:
Why not apply it to 1.1.4 branch and merge it down? Eventually we
need to merge everything down. My vote is to fix it once merge it the
second time. But I don't know the nature of the fix so maybe I'm way
off here.
It's already in trunk,
For struts, it uses Digester to process the configuration file. I tried to find something like this in FacesServlet, but cannot find any similar code. So, my question is how jsf web application implement this kind of work?
On 8/3/06, bin z [EMAIL PROTECTED] wrote:
For struts, it uses Digester to process the configuration file. I tried to
find something like this in FacesServlet, but cannot find any similar code.
So, my question is how jsf web application implement this kind of work?
Yep. Same deal.
Take a look
[
http://issues.apache.org/jira/browse/TOMAHAWK-523?page=comments#action_12425515
]
Mike Kienenberger commented on TOMAHAWK-523:
you' re mike. but the itention of this bug-report is to discuss and determine
that
1.) it is is
[
http://issues.apache.org/jira/browse/TOMAHAWK-579?page=comments#action_12425518
]
Bryan Hansen commented on TOMAHAWK-579:
---
I have read that this was solved in the past, but this is still occuring with
the RI and Tomahawk 1.1.3.
But in sun's jsf1.2 specification, I cannot find the some package like myfaces' config. How does it parse the configuration file?On 8/3/06, Mike Kienenberger
[EMAIL PROTECTED] wrote:On 8/3/06, bin z
[EMAIL PROTECTED] wrote: For struts, it uses Digester to process the configuration file. I tried
Well, this is the MyFaces mailing list. We can tell you how our
implementation works.
If you want to know how the RI's JSF 1.2 implementation works you need
to ask on their mailing lists :)
[EMAIL PROTECTED]
On 8/3/06, bin z [EMAIL PROTECTED] wrote:
But in sun's jsf1.2 specification, I
thanks for help :)On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
Well, this is the MyFaces mailing list. We can tell you how ourimplementation works.If you want to know how the RI's JSF 1.2 implementation works you needto ask on their mailing lists :)
[EMAIL PROTECTED]On 8/3/06, bin z
I checked the myfaces' FacesServlet src, which is almost the same like jsf1.2 specification, and I cannot found any code using Digester liked class. Then how jsf application read configuration file?
On 8/3/06, bin z [EMAIL PROTECTED] wrote:
thanks for help :)On 8/3/06, Mike Kienenberger
[EMAIL
On 8/3/06, bin z [EMAIL PROTECTED] wrote:
I checked the myfaces' FacesServlet src, which is almost the same like
jsf1.2 specification, and I cannot found any code using Digester liked
class. Then how jsf application read configuration file?
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
Sure. I can't start it until about 11 hours from now, but it'll get done. In
the meantime, please provide a URL to both jars.
Dennis Byrne
-Original Message-
From: Matthias Wessendorf [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 3, 2006 01:17 AM
To: 'Dennis Byrne'
Subject: myfaces
Tell me what revision the check in was so I can revert it. Then just
apply to the trunk ok?
Sean
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 8/2/06, Sean Schofield [EMAIL PROTECTED] wrote:
Why not apply it to 1.1.4 branch and merge it down? Eventually we
need to merge
I agree with Mike here. Matthias, can you explain the problem in more
detail? We should fix this problem before releasing (if there's a
problem to fix.)
Sean
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
As for the
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
It's already in trunk,
And then on 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
Tell me what revision the check in was so I can revert it. Then just
apply to the trunk ok?
This is very hard to follow. Maybe I'm quoting out of
On 8/3/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
It's already in trunk,
And then on 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
Tell me what revision the check in was so I can revert it. Then just
apply to the trunk ok?
This is
RANT MODE
However, I think it's a backward approach to be making patches to a
branch, and then porting them over at some later time to trunk.
Branches should be static except when applying maintenance fixes, and
those fixes should be merged over from trunk after being tested, not
the other way
In an attempt to not add confusion to this thread, and hopefully to infuse some encouragement, I just copied all the new SNAPSHOT jars into my production system and tested the hell out of it. Other than having to add a form around a jsCookMenu, everything seems to work really well. I did not have
Yes,
Martin changed on head the name of the getScrolling() function to
org_apache_myfaces_getScrolling() (JS function). So, Tomahawk post
1.1.4 (means 1.1.5-SNAPSHOT and following) don't render that
getScrolling() but the myfaces pre 1.1.5 (like 1.1.4 snapshot) does.
That was the reason for
And what I fixed was MYFACES-1376 for the branch of shared_203 + core_114;
that was the blocker Sean opend, and I guess wendy reffered to.
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 8/3/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED]
Hi Sean,
wendy posted the *new* RC to this folder
http://people.apache.org/builds/myfaces/core-1.1.x/
that contains the fix for your blocker.
-Matthias
On 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
So is there a new RC we should be testing against? I can update it
with the latest
Mike
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
I understand why we want to clean up our namespaces, but is this
cleanup really important enough to warrant breaking compatibility in
the 1.1 releases?
I think not; Maybe it is. There was no announcement or something like that.
For
On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Maybe we should remove the *renamed* JS function and add it the the 1.2 branch ?
My vote would be for reverting this renaming and going back to the old name.
It's too bad that Martin isn't around to comment, though.
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Maybe we should remove the *renamed* JS function and add it the the 1.2
branch ?
My vote would be for reverting this renaming and going back to the old name.
that said, we have the
[
http://issues.apache.org/jira/browse/MYFACES-1376?page=comments#action_12425566
]
Wendy Smoak commented on MYFACES-1376:
--
On 02-Aug-2006, Matthias wrote:
FIXED IN BRANCH
URL: http://svn.apache.org/viewvc?rev=428231view=rev
Log: fixed
[
http://issues.apache.org/jira/browse/MYFACES-1377?page=comments#action_12425569
]
Wendy Smoak commented on MYFACES-1377:
--
Discussion thread:
http://www.mail-archive.com/dev%40myfaces.apache.org/msg16177.html
h:dataTable with
Well, the internet connection part of the dtd is solved, then.
I'm not aware of any other parts of MyFaces that might require an
internet connection.
The following stack track is for a null pointer exception -- you need
to investigate a little more and figure out why that's happening.
One easy
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Maybe we should remove the *renamed* JS function and add it the the 1.2
branch ?
My vote would be for reverting this renaming and going back to the old name.
... and now we're
I patched the 1.1.4 branch; so now 1.1.4 core works with
tomahawk 1.1.5-Snap
and tomahawk 1.1.4-SNAP (after you compile it against the *patched* shared_203)
Great.
-Matthias
Sean
On 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
I patched the 1.1.4 branch; so now 1.1.4 core works with
tomahawk 1.1.5-Snap
and tomahawk 1.1.4-SNAP (after you compile it against the *patched*
shared_203)
Great.
but ... tomahawk 1.1.3 won't work with 1.1.4-RC (and post this)
let's
I'm assuming you mean apply it to the branch.
Sorry. That's what I meant.
As for the revision,
http://issues.apache.org/jira/browse/TOMAHAWK-467?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel
states 428204
I'm more than happy to learn how to do this myself
Without knowing to much about the reason for this, I'd vote like you!
+1 for using getScrolling
+1 I think that we can live with the simple getScrolling for now,
and leave the rename for the next major release (1.2). If this is what
is blocking the release I would say go for it, and lets
I understand why we want to clean up our namespaces, but is this
cleanup really important enough to warrant breaking compatibility in
the 1.1 releases?
No.
getScrolling has been used for a long time, and it's not just going to
break between 1.1.3 and 1.1.4, it's going to break anyone who's
Focus component cannot focus controls within a subview.
---
Key: TOMAHAWK-581
URL: http://issues.apache.org/jira/browse/TOMAHAWK-581
Project: MyFaces Tomahawk
Issue Type: Bug
Affects
[
http://issues.apache.org/jira/browse/MYFACES-1372?page=comments#action_12425593
]
Wolf Benz commented on MYFACES-1372:
@ Matthias W:
Hi Matthias, I saw you changed the fix version from 114 to 115.
As this is a basic issue (h:messages is
[
http://issues.apache.org/jira/browse/MYFACES-1372?page=comments#action_12425598
]
Mike Kienenberger commented on MYFACES-1372:
It's a case of needing to get the release out (There will always be another
release).
Since it's not
[ http://issues.apache.org/jira/browse/MYFACES-1374?page=all ]
Ken Lowther resolved MYFACES-1374.
--
Resolution: Invalid
This was NOT a bug in MyFaces, but was related to the values being set for the
UISelectBoolean's submittedValue when it the form was
It's that unit test vs integration test thing again. Your
example will show that facelets works as an integration test, but
isn't really as comprehensive as having a facelets example for every
component.
Yes a facelets example for every component wouldn't hurt. Also,
Wendy's work with the
looks like all people here are
-1 on keeping (or +1 on putting it to the 1.2 branch)
I'll wait until tonight (US time) and do some stuff there;
Makes sense?
Yes. Thanks for helping (again.)
Matthias Wessendorf
Sean
Ok,
I think this dif can stay
dif
public static void appendAutoScrollAssignment(StringBuffer
onClickValue, String formName)
{
+onClickValue.append(if(window.+AUTO_SCROLL_FUNCTION+!=undefined));
+onClickValue.append({);
ok,
I tested that
dif_to_revert
-private static final String AUTO_SCROLL_PARAM = autoScroll;
-private static final String AUTO_SCROLL_FUNCTION = getScrolling();
+private static final String AUTO_SCROLL_PARAM =
org_apache_myfaces_autoScroll;
+private static final String
[
http://issues.apache.org/jira/browse/MYFACES-1376?page=comments#action_12425678
]
Wendy Smoak commented on MYFACES-1376:
--
Matthias reverted part of r421297, here:
http://svn.apache.org/viewvc?rev=428629view=rev (shared 2.0.4 trunk)
Folks,
should we ask on the user list for some *testing* help?
Since it's summer/vacation time, I guess not much will happen here :)
.Matthias
On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
ok,
I tested that
dif_to_revert
-private static final String AUTO_SCROLL_PARAM =
58 matches
Mail list logo
