[
http://issues.apache.org/jira/browse/MYFACES-592?page=comments#action_12330259
]
Jamie Cash commented on MYFACES-592:
New fix, that solves regression issues has been submitted under issue 606.
> tomahawke SelectOneRadio in datatable no longer working
myfaces-all.jar lacks the faces-config.xml
--
Key: MYFACES-608
URL: http://issues.apache.org/jira/browse/MYFACES-608
Project: MyFaces
Type: Bug
Components: General
Versions: 1.1.0
Environment: Linux Fedora Core 4,
Thanks a lot!
great news for our developers ;)
regards,
Martin
On 9/23/05, Heng Yuan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Sorry for the late reply. I've made the changes to the current theme files.
> Please test it out. The user defined theme base name should have prefix of
> "my" instead of
[ http://issues.apache.org/jira/browse/MYFACES-592?page=all ]
Martin Marinschek reopened MYFACES-592:
---
> tomahawke SelectOneRadio in datatable no longer working
> ---
>
> Key: MYFACES-59
[ http://issues.apache.org/jira/browse/MYFACES-434?page=all ]
Shinsuke SUGAYA updated MYFACES-434:
Attachment: filterportlet.patch
filterportlet.tar.gz
Attached filterportlet.patch and filterportlet.tar.gz(added files).
In order to fi
[ http://issues.apache.org/jira/browse/MYFACES-608?page=all ]
Bruno Aranda closed MYFACES-608:
Resolution: Won't Fix
Closing, because MYFACES-598 is the reason for this.
> myfaces-all.jar lacks the faces-config.xml
> ---
[
http://issues.apache.org/jira/browse/MYFACES-594?page=comments#action_12330268
]
Jamie Cash commented on MYFACES-594:
The RC1 test was a red herring, the problem was caused by a bug in all recent
JBoss versions (I will raise with JBoss shortly) where
[ http://issues.apache.org/jira/browse/MYFACES-594?page=all ]
Bruno Aranda closed MYFACES-594:
Resolution: Invalid
Closing at it does not seem a myfaces bug... Thanks Jamie!
> Examples and myfaces 1.0.9 apps don't work on tomcat 5.5 running under J
[ http://issues.apache.org/jira/browse/MYFACES-592?page=all ]
Jamie Cash updated MYFACES-592:
---
Attachment: 606.patch.txt
This is the same patch as for issue 606. It should only be applied once.
> tomahawke SelectOneRadio in datatable no longer working
> -
[ http://issues.apache.org/jira/browse/MYFACES-607?page=all ]
Bruno Aranda closed MYFACES-607:
Resolution: Fixed
Fixed. Thanks Mike!
> t:inputFileUpload shown as t:fileUpload in web docs
> ---
>
>
[
http://issues.apache.org/jira/browse/MYFACES-594?page=comments#action_12330272
]
Jamie Cash commented on MYFACES-594:
Logged with JBoss
http://jira.jboss.com/jira/browse/JBAS-2286
> Examples and myfaces 1.0.9 apps don't work on tomcat 5.5 running un
[ http://issues.apache.org/jira/browse/MYFACES-596?page=all ]
Bruno Aranda closed MYFACES-596:
Resolution: Invalid
Closing as it seems to be a bad use of the 'onclick' attribute...
> "onclick" doesn't work!
> ---
>
> Ke
[ http://issues.apache.org/jira/browse/MYFACES-588?page=all ]
Bruno Aranda closed MYFACES-588:
Fix Version: Nightly Build
Resolution: Fixed
This should be fixed now in the SVN. Thanks for reporting!
> JSCookMenu separator bug - phantom item
>
I agree with Martin on this - if you need everything, you can always
checkout MyFaces, right?
regards,
Martin
On 9/23/05, Martin Cooper <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 22 Sep 2005, Bill Dudney wrote:
>
> > Well the idea is that people would then be using current/trunk to checkout
> > in
Bill,
please go ahead and check in what you have got now. If you do it
anytime during the next hour, I will go ahead and prepare a new
release from this so that we get this faces-config problem out of the
world as fast as possible!
regards,
Martin
On 9/22/05, Bill Dudney <[EMAIL PROTECTED]> wro
-1
Note that after I tagged the 1.1 release I created a external in the
"release" dir so if you use
http://svn.apache.org/repos/asf/myfaces/release/1_1_0/ you will get
"current" but for the release. It doesn't include sandbox so its not
quite the same but sandbox is not part of the official relea
Remember to release without the sandbox. In theory you should use 'ant
-Dskip.sandbox=true dist-all', but that is the origin of the bug. I
cannot look at it right now...
Bruno
2005/9/23, Martin Marinschek <[EMAIL PROTECTED]>:
> Bill,
>
> please go ahead and check in what you have got now. If you
Yes,
as long as 1_1_0 is ok to change (by convention tags are not
modified, only branches).
All I'm looking for is a place to change the release only enough to
get the faces-config.xml file in place (as well as the other missing
bits because that file is not found) and then get a new rele
Hi All,
This is the essence of what I fixed. I've rebuilt and used the
myfaces-all.jar in the the 'simple.war' test application and
everything I tested worked.
Instead of 'dist-all' use 'release'.
The only problem I see with this approach is that we could introduce
unintended consequence
You are right - no question.
we should definitely rerun the TCK if possible.
Oliver is on holidays, remains Manfred to do so...
Manfred?
;)
regards,
Martin
On 9/23/05, Bill Dudney <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> This is the essence of what I fixed. I've rebuilt and used the
> myface
checked into the trunk
Thanks Martin!
-bd-
On Sep 23, 2005, at 6:16 AM, Martin Marinschek wrote:
You are right - no question.
we should definitely rerun the TCK if possible.
Oliver is on holidays, remains Manfred to do so...
Manfred?
;)
regards,
Martin
On 9/23/05, Bill Dudney <[EMAIL PR
t:dataScroller fires unnecessary ScrollerActionEvents
-
Key: MYFACES-609
URL: http://issues.apache.org/jira/browse/MYFACES-609
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: Nightly Build
Env
[ http://issues.apache.org/jira/browse/MYFACES-598?page=all ]
Bill Dudney resolved MYFACES-598:
-
Fix Version: Nightly Build
Resolution: Fixed
updated the build.xml file to use the tomahawk/config/faces-config.xml file if
the sandbox is exclude
Hi Enrico,
You have to have commons-lang.jar in your WEB-INF/lib directory.
Sorry this was a bug in the getting started docs that has just been
fixed.
Good luck,
-bd-
On Sep 23, 2005, at 4:03 AM, Enrico Nicola Mirco wrote:
Hi,
every day I download and update my project with last nighly
Getting IllegalStateException exception when setting
javax.faces.STATE_SAVING_METHOD to "server"
Key: MYFACES-610
URL: http://issues.apache.org/jira/browse/MYFACES-610
Project:
> as long as 1_1_0 is ok to change (by convention tags are not
> modified, only branches).
Technically you can change it but SVN (at least Tortoise SVN) warns
you and says its a tag and you shouldn't. Why do we need a branch at
this point?
We could create a branch for it but lets establish why t
Lets use mock when possible but certainly Cactus is fine for when mock
won't suffice. Also, I suggest we focus on testing tomahawk for now
since we basically have a pretty decent test suite for the
implementation (the TCK tests.)
sean
On 9/22/05, Bill Dudney <[EMAIL PROTECTED]> wrote:
> Hi All,
We have been discussing doing a release as the problem with the
faces-config.xml missing in the myfaces-all.jar is a very prominent
one ;)
If there is a way of fixing the existing release with just the
faces-config.xml file, that would be better!
regards,
Martin
On 9/23/05, Sean Schofield <[EMA
Sigh. How did we miss this one? I thought we did a test of
everything? This is probably the only type of error where we could
justify doing this although its kind of embarassing that it happened
in the first place.
Technically you can check into a tagged version so this is probably
the best thi
Ok, Bill,
can you take over here?
You tried this before?
regards,
Martin
On 9/23/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> Sigh. How did we miss this one? I thought we did a test of
> everything? This is probably the only type of error where we could
> justify doing this although its
We just need the corrected build.xml put into the 1_1_0 tag. The
build should *only* contain the changes necessary for faces-config.xml
(not the new unit testing stuff, etc.) Do we have volunteers to test
once its built?
sean
On 9/23/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> Ok, Bill,
I'm certainly no expert in making releases nor am I a committer, but
why start off being sloppy? There's a bug that warrants an immediate
release. There's no guarantee that another such bug won't turn up
after the next release and require another release. That's what
branches are for, so why r
ConverterException is not properly handled in several instances
---
Key: MYFACES-611
URL: http://issues.apache.org/jira/browse/MYFACES-611
Project: MyFaces
Type: Bug
Components: JSR-127
Versions: 1.1
[ http://issues.apache.org/jira/browse/MYFACES-605?page=all ]
Mike Kienenberger updated MYFACES-605:
--
Attachment: ServletFacesContextImpl.java.patch.txt
Ok. My previous thoughts of delegating don't allow wrapping of the
ServletResponse outputStrea
We can certainly create a branch but the idea is that we eventually
have an official release and that's it. Of course there will be minor
bugs and those just get fixed in the next release. If you need
something before then you use the nightly. This is kind of a weird
exception.
Even with a bran
Agreed,
We need a branch and we need to edit it.
As I understand it there is currently the
release/ with externals to all the tags except the sandbox.
I've just checked out and the tag won't build because it does not
included sandbox.
My proposal;
1) Create a branch of each subproject that
[Oops. Replied to Sean and not the list. Resending].
I'm probably adding to the confusion because I'm used to seeing
releases for minor bug fixes and new features differently. Ie,
fixing the build bug would be a 1.1.0.1 release whereas the next
regular release would be 1.1.1, so you'd need a b
The tag definitely will build without the sandbox b/c that is how I
built the release. You need -Dskip.sandbox=True. Or if you use the
bootstrap you just execute the release tag. Now the skip.sandbox
stuff might be part of why faces-config.xml is missing but we can (and
should) fix that part.
P
On Sep 23, 2005, at 8:13 AM, Sean Schofield wrote:
We can certainly create a branch but the idea is that we eventually
have an official release and that's it. Of course there will be minor
bugs and those just get fixed in the next release. If you need
something before then you use the nightly
IllegalStateException: Cannot forward after response has been committed
---
Key: MYFACES-612
URL: http://issues.apache.org/jira/browse/MYFACES-612
Project: MyFaces
Type: Bug
Components: Implementat
Bill,
Why don't you create a new branch then but follow my wiki instructions
(replacing 'tags' with 'branches.' I think we should *definitely*
skip the sandbox as it is not part of the release. We must get the
build working without the sandbox anyways.
You can create a svn external in the "rele
On Sep 23, 2005, at 8:27 AM, Sean Schofield wrote:
The tag definitely will build without the sandbox b/c that is how I
built the release. You need -Dskip.sandbox=True. Or if you use the
bootstrap you just execute the release tag. Now the skip.sandbox
stuff might be part of why faces-config.x
Lets get rid of the sandbox stuff from faces-config.xml for now (at
least in the branch.) It is causing to much headache and its only
there to support sandbox. What do you think? This last minute
addition to the mix is the source of all the problems.
sean
On 9/23/05, Bill Dudney <[EMAIL PROTEC
I disagree that we should be committing to tags.
Over time it will get very messy to know what the 1_1_0 was, as an
example having a 1_1_0 tag will help us understand what has changed
between releases, we can diff tag 1_1_0 and 1_1_1, the branch lets us
make changes and keep a 'known' state
IMO releasing 1.1.0 was a fast shot.
What I´ve missed where the release candidates which normally come
before the final release. We should get back to the normal procedure.
RCs give us the feedback we need to create good releases.
Tags are supposed to be fixed and shouldn´t be changed after makin
I think we can move past the tag vs. branch discussion now. I've
conceded a few emails ago that we should do a branch.
I have to go offline for a few hours. Can this wait until a little
later this afternoon? I can create a branch for us using the tag as
the starting point.
There is no rush. R
Hi Sean,
I don't mind creating the branches in the same way we have created
the tags.
I'm glad to create the branches, update the build.xml file run the
build and put myfaces-all.jar and (tomahawk, api & impl) and make
sure stuff works there.
I'll call it 1_1_0_1.
TTFN,
-bd-
On Sep
[
http://issues.apache.org/jira/browse/MYFACES-612?page=comments#action_12330293
]
Jeremy Green commented on MYFACES-612:
--
I have also been able to demonstrate this using a myfaces-all.jar built from
the svn source code:
$ svn info
Path: .
URL: https
Fixed misnamed myfaces.jar reference and added link to Extensions Filter setup
on Tomahawk overview page
Key: MYFACES-613
URL: http://issues.apache.org/jira/browse/MYFACES-61
[ http://issues.apache.org/jira/browse/MYFACES-613?page=all ]
Mike Kienenberger updated MYFACES-613:
--
Attachment: tomahawk-overview.patch.txt
Fixed misnamed myfaces.jar reference and added link to Extensions Filter setup
on Tomahawk overview page.
Apparently there is a problem with faces-config.xml in myfaces-all.jar
of the current release. All of this confusion seems to be coming from
the fact that sandbox is in myfaces-all.jar in the nighlty but not the
release. We have the -Dskip.sandbox option and a bunch of other hacks
in the build to
OK just found this thread from yesterday afternoon. Man if you leave
your computer for a few hours I guess you miss a lot of action!
We definitely should run the TCK before releasing and we should test
everything (for real this time) and vote. This wil take about a week
but we rushed things last
Local component xml files in the sourcebase reference in the dtd a url which
fails
--
Key: MYFACES-614
URL: http://issues.apache.org/jira/browse/MYFACES-614
Project: MyFaces
Type: Bug
[ http://issues.apache.org/jira/browse/MYFACES-613?page=all ]
sean schofield closed MYFACES-613:
--
Resolution: Fixed
> Fixed misnamed myfaces.jar reference and added link to Extensions Filter
> setup on Tomahawk overview page
>
[
http://issues.apache.org/jira/browse/MYFACES-434?page=comments#action_12330313
]
Stan Silvert commented on MYFACES-434:
--
I take a look as soon as I can. I like it so far!!!
Thanks Shinsuke.
> MyFaces's Portlet enhancement
> ---
Totally agree that we should not shoot ourselves in the foot again.
The branches are complete and I have a fix in place on the branch.
I added a tags and branches directory to the release dir
release/
tags/
1_1_0 <- is what we released
branches/
1_1_0 <- is what I've fix
Agreed,
-bd-
On Sep 23, 2005, at 11:20 AM, Sean Schofield wrote:
Apparently there is a problem with faces-config.xml in myfaces-all.jar
of the current release. All of this confusion seems to be coming from
the fact that sandbox is in myfaces-all.jar in the nighlty but not the
release. We hav
+1
2005/9/23, Bill Dudney <[EMAIL PROTECTED]>:
> Agreed,
>
> -bd-
>
> On Sep 23, 2005, at 11:20 AM, Sean Schofield wrote:
>
> > Apparently there is a problem with faces-config.xml in myfaces-all.jar
> > of the current release. All of this confusion seems to be coming from
> > the fact that sandbo
sure!
+1 on that.
thanks for catching this Sean!
-Matthias
On 9/23/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> Apparently there is a problem with faces-config.xml in myfaces-all.jar
> of the current release. All of this confusion seems to be coming from
> the fact that sandbox is in myface
I will start on the change that I proposed in the other thread. We
can always roll it back if there are a lot of -1.
Also, I asked this is the other thread but I should've asked you here,
did you branch off the 1.1.0 tag or latest trunk?
It matters because the fix is in the trunk already and we'
>From Sean sent directly to me:
@Bill,
About the branch you created, was it off the trunk or the 1_1_0 tag?
On 9/23/05, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> sure!
>
> +1 on that.
>
> thanks for catching this Sean!
>
> -Matthias
>
> On 9/23/05, Sean Schofield <[EMAIL PROTECTED]> wr
If we're going to do a general release based on the current svn, I've
already run into one blocker issue that I'm still trying to track
down.
1.1.0 (just tested it) and before (Aug 16 snapshot for sure) both had
working inputCalendar renderAsPopup="true"behavior.
However, the Sep 18th nightly and
[
http://issues.apache.org/jira/browse/MYFACES-568?page=comments#action_12330317
]
Jon Travis commented on MYFACES-568:
Bett,
I've run into the same problem as you. We are working with a server-based tree
and
need to do dynamic updates to it.
The wa
+1
Manfred
2005/9/23, Sean Schofield <[EMAIL PROTECTED]>:
> Apparently there is a problem with faces-config.xml in myfaces-all.jar
> of the current release. All of this confusion seems to be coming from
> the fact that sandbox is in myfaces-all.jar in the nighlty but not the
> release. We have
I don't think the plan is to release against the current svn but we're
waiting for clarification from Bill about the branch.
sean
On 9/23/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> If we're going to do a general release based on the current svn, I've
> already run into one blocker issue t
Yes, no problem. I will run the new release against TCK. But not
before monday, because my home machine is too weak.
-Manfred
2005/9/23, Martin Marinschek <[EMAIL PROTECTED]>:
> You are right - no question.
>
> we should definitely rerun the TCK if possible.
>
> Oliver is on holidays, remains Manf
The branch is based on the tag.
Sean could you push a release?
TTFN,
-bd-
On Sep 23, 2005, at 12:28 PM, Sean Schofield wrote:
I will start on the change that I proposed in the other thread. We
can always roll it back if there are a lot of -1.
Also, I asked this is the other thread but I sh
You mean put a RC up? I'm working on that. Right now I am fixing the
build along the lines of the proposal that we discussed (simplifying
sandbox stuff.) I am testing it as we speak but as with most Ant
builds, I am sure it will take a few iterrations ;-)
sean
On 9/23/05, Bill Dudney <[EMAIL P
Hi all,
Sorry if I have missed something important, but for lack of time I
only could rush through this thread. Just my 0.02 on this issue:
- If I got it right, there is only a problem with the myfacse-all.jar, right?
- So, as someone proposed earlier we could give a workaround hint
("use the singl
Yeah,
No hurry, the real thing I was trying to say is that its ready when
you are :-)
Have a great weekend.
TTFN,
-bd-
On Sep 23, 2005, at 1:08 PM, Sean Schofield wrote:
You mean put a RC up? I'm working on that. Right now I am fixing the
build along the lines of the proposal that we d
Hi All,
We have the branch created as 1_1_0 (a copy of the 1_1_0 tag) and
once done it can become 1_1_1 or 1_1_0_1 whatever we agree to.
Agreed that we need to have an RC1 tag (which I'm happy to create
when the vote happens).
Once we agree to release we will create another tag (1_1_1 or
> We have the branch created as 1_1_0 (a copy of the 1_1_0 tag) and
> once done it can become 1_1_1 or 1_1_0_1 whatever we agree to.
But someone also mentioned that there is a serious bug (showstopper?)
in jscookmenu.
Therefore my proposal for doing it from current stuff. Or someone does
fix this
Yes, there's a showstopper regression bug in inputCalendar as well.
Still trying to see what revision it broke at, but likely either
289859 -- Martin's revamp on the 17-18th
289189 - Myfaces-569 fix on the 15th
Trying to download and build the revisions right before each to
determine when since
The bug is on the trunk though and Bill created the branch off the
release. So this is not a show stopper for 1.1.1. I agree that we
should call it 1.1.1 and Bill is right that we can rename the branch
to whatever we want later.
I'm working on the revised build.xml now. Hopefully we can put up
Yes the bug should only be on the trunk and not in the branch.
TTFN,
-bd-
On Sep 23, 2005, at 2:17 PM, Sean Schofield wrote:
The bug is on the trunk though and Bill created the branch off the
release. So this is not a show stopper for 1.1.1. I agree that we
should call it 1.1.1 and Bill is
Hi
Everyone,
I've been trying out
the MyFacesGenericPortlet, I am not sure to how get the portlet to
show different content when switching portlet modes. What is the best
way to do this?
I've looked at the
DefaultViewSelector and thought I could implement that interface to look up init
Just checked in a revised build.xml. I will take a look at the
resulting jar files to make sure they look good but I am counting on
the others to help me. The sandbox stuff is defnitely not working but
that is not important at the moment. For now we just need to build
without the sandbox.
I wil
Thanks Sean,
I will be off line for the next 5 or 6 hrs but will check in before
bed time.
TTFN,
-bd-
On Sep 23, 2005, at 2:41 PM, Sean Schofield wrote:
Just checked in a revised build.xml. I will take a look at the
resulting jar files to make sure they look good but I am counting on
the
Thanks Sean and Bill,
I will now be offline too until Sunday late evening. As mentioned
before, I can check TCK compatibility Monday morning (european time).
-Manfred
2005/9/23, Bill Dudney <[EMAIL PROTECTED]>:
> Thanks Sean,
>
> I will be off line for the next 5 or 6 hrs but will check in befor
Just remember to use -Dskip.sandbox=true. That is still necessary to
skip the sandbox stuff for the examples and source bundles. I'm
offline for the rest of the evening as well.
sean
On 9/23/05, Bill Dudney <[EMAIL PROTECTED]> wrote:
> Thanks Sean,
>
> I will be off line for the next 5 or 6 hrs
regression -- t:inputCalendar no longer has js popup in nightlies
-
Key: MYFACES-615
URL: http://issues.apache.org/jira/browse/MYFACES-615
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions
tree2 creates TWO cookies
-
Key: MYFACES-616
URL: http://issues.apache.org/jira/browse/MYFACES-616
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: Nightly Build
Reporter: Jan Dockx
Cookies for tree2 are generated by
I realize there are bigger issues right
now, but one of you may want to change the second exception constructor
in ConverterUtils.convertToBoolean from "Cannot convert ... to int"
to "Cannot convert ... to boolean".
Dennis Byrne
[ http://issues.apache.org/jira/browse/MYFACES-580?page=all ]
Mathias Werlitz updated MYFACES-580:
Attachment: tree2_duplicateIDv2.diff
updated the patch - now it does not create warnings about automatic ids
> tree2: tree component can cause duplica
[
http://issues.apache.org/jira/browse/MYFACES-616?page=comments#action_12330331
]
Mathias Werlitz commented on MYFACES-616:
-
getting rid of cookies would breake the preserveToggle feature in client side
toggle mode :(
> tree2 creates TWO cookies
[ http://issues.apache.org/jira/browse/MYFACES-580?page=all ]
sean schofield updated MYFACES-580:
---
Attachment: (was: tree2_duplicateID.txt)
> tree2: tree component can cause duplicate id problems
> --
[ http://issues.apache.org/jira/browse/MYFACES-580?page=all ]
sean schofield updated MYFACES-580:
---
Attachment: (was: tree2_duplicateIDv2.diff)
> tree2: tree component can cause duplicate id problems
> ---
[ http://issues.apache.org/jira/browse/MYFACES-210?page=all ]
sean schofield updated MYFACES-210:
---
Fix Version: (was: 1.1.0)
> Undesired dependency on ApplicationImpl in FacesConfigurator
> --
[ http://issues.apache.org/jira/browse/MYFACES-580?page=all ]
sean schofield closed MYFACES-580:
--
Fix Version: Nightly Build
Resolution: Fixed
> tree2: tree component can cause duplicate id problems
> --
[
http://issues.apache.org/jira/browse/MYFACES-552?page=comments#action_12330355
]
Sh Ma commented on MYFACES-552:
---
Hi Thomas,
When you mean "irreproducible," are you confirming that there is a problem with
multiple autoUpdateDataTable elements or are you s
[
http://issues.apache.org/jira/browse/MYFACES-552?page=comments#action_12330356
]
Sh Ma commented on MYFACES-552:
---
I probably should have noted that I'm also using Tiles... I hope that isn't
causing any problems...
> Multiple autoUpdateDataTable elements
Hi,
every day I download and update my project with last nighly build
myfaces library.
>From 2005-09-18 nighly build ,when I open a page with a
property startDate is a java.util.Date
Any Ideas?
please, help us.
Thanks
Enrico, Nicola, Mirco
92 matches
Mail list logo
