+1 for 1.2
2007/5/18, Matthias Wessendorf [EMAIL PROTECTED]:
So,
any interest in making this to 2.0.0 ?
-Matthias
On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote:
...
I am
+1 for Paul's suggestion:
JSF 1.1 - MyFaces 1.x
JSF 1.2 - MyFaces 2.x
and I am
+1 for JSF 2.0 (or JSF6
Hi Wendy,
can you also add my account (mbr) to the administrator group?
Thanks Cheers
Mathias
2007/5/13, Wendy Smoak [EMAIL PROTECTED]:
I decided to upgrade Continuum on the zone to 1.1-alpha-1 this
morning... and forgot that this version unpacks to 'continuum' rather
than
I fixed the continuum setup.
The problem where some orphan lock files of the embedded derby database:
rm /local/continuum-1.1-SNAPSHOT/data/continuum/database/*.lck
and restarted continuum.
The build should now be up and the artifacts be deployed to the
snapshot repository.
2007/4/19, Wendy
+1 but without a merge of the 1.1 trunk into 1.2. We have to select
each individual issue. That is quite time consuming and shouldn't be
done with this step.
What about this:
move current trunk to a 1.1 branch and
move current 1.2 branch to trunk.
That is quite a small step without any side
, Mathias Brökelmann [EMAIL PROTECTED] wrote:
+1 but without a merge of the 1.1 trunk into 1.2. We have to select
each individual issue. That is quite time consuming and shouldn't be
done with this step.
What about this:
move current trunk to a 1.1 branch and
move current 1.2 branch to trunk
+1
2007/4/17, Gary VanMatre [EMAIL PROTECTED]:
+1 non-binding
Gary VanMatre
From: Matthias Wessendorf [EMAIL PROTECTED]
Hi,
the Trinidad community has voted to graduate and being a subproject of
the Apache MyFaces project ([1]). Now it's up to the MyFaces PMC to
accept Trinidad as a
-3, ((UIInput)comp).getValue());
}
On 4/12/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
Mike please create a unit test for this (including one for a nested
table). It will help us tracking this issue if other things are
changing in this area.
2007/4/12, Mike Kienenberger [EMAIL
I introduced the FacesInitializer for 1.2 to get rid of the static
initFaces call and the dependency of MyFacesServlet to
StartupServletContextListener. The original intention of
setFacesInitializer was to make StartupServletContextListener
testable. But right now there is no test for
Thank you.
2007/3/16, Cagatay Civici [EMAIL PROTECTED]:
Hello Matthias,
As far as I know, there's no jsr-252 issue related to the new prependId
feature in jira,
Since you fixed it, I'm planning to create one and mark as resolved then.
Cagatay
On 3/16/07, [EMAIL PROTECTED] [EMAIL
://www.apache.org/dev/svn-eol-style.txt
Thanks,
Mathias
2007/3/16, Rahul Akolkar [EMAIL PROTECTED]:
On 3/15/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
I noticed that a lot of source files don't have the svn property
svn:eol-style=native set (at least in 1.2 core). Apache suggests to
use it - see http
I noticed that a lot of source files don't have the svn property
svn:eol-style=native set (at least in 1.2 core). Apache suggests to
use it - see http://www.apache.org/dev/version-control.html for more
info.
I'm currently not sure if it is wise to change it now so that every
non binary file has
I think the reason is that myfaces 1.2 contains its own
org.apache.AnnotationProcessor class which is loaded by a different
classloader than the AnnotationProcessor in tomcat.
2007/3/13, Cagatay Civici [EMAIL PROTECTED]:
Hi,
I'm trying to run the 1.2's test-webapp with tomcat 6.0.10 but keep
IMO the simple interface which David suggest is quite sufficient to
solve the problem. I also think that discovery to look up the
implementation is not a good way in a app server with a complex
classloader hierarchy.
2007/3/13, David Jencks [EMAIL PROTECTED]:
Hello Bernd,
Thanks for looking
complaints (Error in 1.2). I think having MyFaces use the proposed
LifecycleProvider interface and providing an adapter to the already used
AnnotationProcessor interface will cause less problems.
thanks
david jencks
On Mar 13, 2007, at 12:40 PM, Mathias Brökelmann wrote:
IMO the simple interface
Hi all,
During 1.2 development I came across the maven-faces-plugin from
trinidad. AFAIK it uses some xml files which contains the model for
the generated components. This saves a lot of time to quickly get new
components into work. But there is room to improve it.
Currently customizing the
Hi Dennis,
i fixed the build problems.
One problem was the host lookup for myfaces.zones.apache.org which
wasn't working on the zone box. I was not able to modify /etc/hosts
(the cause of the problem is the wrong ip address for
myfaces.zones.apache.org) but I found a workaround and defined in
recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI uses two ways to lookup the implementation of the vendor
The RI uses two ways to lookup the implementation of the vendor
specific implementation of the InjectionProvider. They first try to
use a web context init param and if that is not configured they simply
use a system property. Both keyed by the class name of the
InjectionProvider interface.
some of the builds are currently failing because the lookup for
myfaces.zones.apache.org failes on the zone host. I've looked into the
/etc/hosts config file and IMO there is a wrong ip address defined.
AFAIK the entry should be something like:
127.0.0.1 myfaces.zones.apache.orgloghost
tracker and I'll close
the @PostConstruct issue once Paul says it's good to go. I don't see the
point of the system property though.
Dennis Byrne
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI uses two ways to lookup the implementation of the vendor
specific implementation
The account (mrmaven) is still locked...
I'm not a member of the private list. Any chance to get me in?
2007/2/24, Wendy Smoak [EMAIL PROTECTED]:
On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
hello continuum admins,
the http://myfaces.zones.apache.org:8081 mrmaven account is
+1 for removing the static.
What is about java.util.logging? Can/Should we use it for 1.2?
IMO it is better to use java.util.logging. Apart from the unusable
default implementation for java.util.logging the reason not to use it
in myfaces 1.1 was the dependency to java 1.4. But jsf 1.2 will
Thanks, Wendy!
2007/2/27, Wendy Smoak [EMAIL PROTECTED]:
On 2/27/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The account (mrmaven) is still locked...
I'm not a member of the private list. Any chance to get me in?
Done.
--
Wendy
--
Mathias
can we also add this for 1.2 development?
2007/2/26, Dennis Byrne [EMAIL PROTECTED]:
http://www.sourcekibitzer.org/index.php?option=com_skprojectprojectid=myfaces-core
--
Dennis Byrne
--
Mathias
ok
2007/2/25, Matthias Wessendorf [EMAIL PROTECTED]:
since we used to work w/ 1.0.4-SNAP, which is old btw. I went ahead
and updated the shale stuff to 110-SNAP
-M
On 2/25/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
pressed to fast enter..
should we go w/ the Shale 1.1.x SNAPSHOT ?
That dependency should be optional or provided and we need to make
sure that myfaces can run without it.
2007/2/24, [EMAIL PROTECTED] [EMAIL PROTECTED]:
Author: dennisbyrne
Date: Sat Feb 24 05:42:20 2007
New Revision: 511270
URL: http://svn.apache.org/viewvc?view=revrev=511270
Log:
committing
Hi Dennis,
I have a problem with the handling of ManagedBeans in
VariableResolverImpl. According to the spec the VariableResolverImpl
should only delegate to the application elresolver now. The managed
beans where resolved in a new ManagedBeanResolver. We already have an
implementation for this
sorry - forget it. I have not seen that you have already done that.
2007/2/24, Mathias Brökelmann [EMAIL PROTECTED]:
Hi Dennis,
I have a problem with the handling of ManagedBeans in
VariableResolverImpl. According to the spec the VariableResolverImpl
should only delegate to the application
is in *both*
ManagedBeanResolver and VariableResolverImpl?
Dennis Byrne
On 2/24/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
Hi Dennis,
I have a problem with the handling of ManagedBeans in
VariableResolverImpl. According to the spec the VariableResolverImpl
should only delegate
Hi Matthias,
I still have no rights on the continuum server at port 8081. The
account mrmaven is locked there. I've created an account for me (mbr)
but someone needs to give me more rights.
Have you configured continuum to do the deployment? Or have you done
it manually?
The build problems for
section
to be able to run
mvn clean install source:jar deploy
-M
On 2/23/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
Hi Matthias,
I still have no rights on the continuum server at port 8081. The
account mrmaven is locked there. I've created an account for me (mbr)
but someone needs
I wasn't aware of this. the dtds of 1.0 and 1.1 are also present in
our repository...
2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]:
isn't that CCLD for what ever their OS license is named ?
Should go to the notice.txt file, IMO
-M
On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Not to
Yes that is true - I also marked that issue to be resolved later.
If I understand it right the extension elements are supposed to be
used by jsf implementations. The structure of these elements is not
defined. So it is rather hard to implement something without knowing
what to implement.
When I
Hi Wendy,
Thanks for looking into this.
I guess that the plugin
org.apache.myfaces.trinidadbuild:maven-faces-plugin:incubator-1.2-m1-SNAPSHOT
is the reason for this. Could you remove that artifact from the local
repository?
2007/2/21, Wendy Smoak [EMAIL PROTECTED]:
On 2/18/07, Mathias
Hi Paul,
I looked at you patch and found some other bugs around the resolvers
which I'm going to check now. But for the meantime I will commit your
patch to make the jsp stuff working.
Cheers,
Mathias
2007/2/19, Paul McMahan [EMAIL PROTECTED]:
Hey Matthias, I saw a couple of commits go
Hi *,
I'd like to get the automated builds fixed for the 1.2 builds. These
builds where failing in a while.
IMO a dependency might be the problem which is caused by an
inconsistent local repository for the builds. I verified that on my
personal continuum server and everything when well with a
Hi Tim,
I tried building current12 and got the same error. I found out that
changing the version for the two el dependencies from 1.2 to 1.0 for
the test-webapp module fixed that problem. I changed that in svn.
2007/1/31, Tim McConnell [EMAIL PROTECTED]:
Hi, I'm still unable to build the
Hi,
I changed the dependency to the xslt plugin from 1.0-SNAPSHOT to 1.0
in trunk for tomahawk/core, tomahawk/sandbox and core to make the
build run.
2006/4/26, Sean Schofield [EMAIL PROTECTED]:
Ahh this is because we dropped the atanion snapshot repo since this
plugin has been finalized. The
I think we should add this to the implementation of the tomahawk
DataTable. We can not change UIData since this behavior is specified
in the spec (see API Doc for UIData.encodeBegin()). Unfortunately I´m
currently not able to find the time to set up my test environment with
the new maven build
JSF 1.2 adds the observer pattern to DataModel but it only supports
rowselection events. It would be very cool to have something like the
TableModel in Swing which can be used to notify listeners if the data
in the model changes. UIData can add a listener to that model and can
be notified by the
AFAIK this is not supported by myfaces.
2006/2/7, Sabari Arasu A G [EMAIL PROTECTED]:
Hi,
I am involved to do conversion of screens from XML/XSL to JSF. In our
screens we have datatables with sorting and static header(when the size of
the rows exceeds table header stays static while the data
Hi,
its better to post such messages to the user list.
You should use a complex object for your columns. This allows you to
use boolean is* methods to determine which type of column should be
rendered. That is much easier than binding t:columns into a backing
bean to create depended components.
Thanks for the answer. I think something like myfaces-all would be
very handy too. Will we support this in the future?
2006/1/16, Sean Schofield [EMAIL PROTECTED]:
I´m quite new to maven so this question may get answered by reading
the maven docs but does anyone know how we will get a release
@Sean: I´m missing the externals in current...
I didn´t follow the discussion about the externals but I´m very happy
that they are going to be removed.
2006/1/7, Sean Schofield [EMAIL PROTECTED]:
From earlier discussions we are all pretty much in agreement that we
should eliminate externals
I changed my job and I currently have to learn a lot about steel
manufacturing which isn´t quite related to jsf or myfaces yet :(
But I´m still reading the mails whenever it is possible. I will try to
keep up the response for UIData issues as far as I can.
I think it should be no problem to
make sure that myBean.field2List and myBean.field3List never returns
an empty collection. This is required during processValidation.
If that will not fix it please post your bean code.
2005/12/19, Reiner K. Kappenberger [EMAIL PROTECTED]:
Simon,
No Javascript is used. All modifications to the
yes you are right Mike. I wasn´t aware of this. Thanks for the fix.
2005/12/5, Mike Kienenberger [EMAIL PROTECTED]:
Ok. Hearing no objections, or comments of any sort today, I guess
I'll go ahead and commit this change, and someone can change it back
if I'm wrong.
On 12/5/05, Mike
tomcat team applies only security fixes for 3.x and 4.x versions. IMO
we should do the same. New features or refactorings go only into the
upcoming 1.2 version. AFAIK there where not so much security related
issues in the past. I agree to Sean that we should fix as much as
possible before
the rowstate is not serialized with the view. If validation fails the
submitted value of any input component is rendered in the response.
IMO it is not necessary to save the sate of each row if validation
fails since the values are submitted again through the next request.
In any case saving this
/31, Mathias Brökelmann [EMAIL PROTECTED]:
Have talked about this in our googletalk? I thought it was about the
rowstate between request.
This solution might not work in every case. The spec says to discard
any row state before rendering the table if no errors are on the page.
IMO clearing
Yes you are right. But compressing binary data isn´t very effective at all.
2005/11/3, Martin Marinschek [EMAIL PROTECTED]:
I wonder if we should make this optional - while we have load tests
currently which show that the problem is processor time, it might be
the case that with a different
at how to
fix the FINE: No serialized view found in server session! problem?
Travis
On 10/27/05, Mathias Brökelmann [EMAIL PROTECTED] wrote:
use RendererUtils.SEQUENCE_PARAM or jsf_sequence
2005/10/27, Travis Reeder [EMAIL PROTECTED]:
The not finding the session in view problem
on the structure of the binary data.
So the question is - how much do we gain from this...
We could find that out easily for the client-side, right?
regards,
Martin
On 11/3/05, Mathias Brökelmann [EMAIL PROTECTED] wrote:
Yes you are right. But compressing binary data isn´t very effective at all
I should have done this. Unfortunately my forrest build fails building
a lot earlier saying:
BUILD FAILED
C:\java\myfaces\workspace\myfaces\forrest\build\build.xml:49: The
following error occurred while executing this line:
C:\java\apache-forrest-0.6\src\core\targets\validate.xml:143: Could
not
Have talked about this in our googletalk? I thought it was about the
rowstate between request.
This solution might not work in every case. The spec says to discard
any row state before rendering the table if no errors are on the page.
IMO clearing the rowstate and the datamodel must be done
I take a look into that now.
2005/10/28, Martin Marinschek [EMAIL PROTECTED]:
I have had this problem too.
Thanks Simon for figuring out what causes the problem.
Mathias, any time to look into this?
regards,
Martin
On 10/28/05, Simon Kitching [EMAIL PROTECTED] wrote:
Simon Kitching
its fixed now
2005/10/28, Mathias Brökelmann [EMAIL PROTECTED]:
I take a look into that now.
2005/10/28, Martin Marinschek [EMAIL PROTECTED]:
I have had this problem too.
Thanks Simon for figuring out what causes the problem.
Mathias, any time to look into this?
regards
double rendering is fixed now. Was a problem with my AddResource patch.
2005/10/28, Bruno Aranda [EMAIL PROTECTED]:
Well, it's the typical component where you have two listboxes and put
elements from the list on the left to the list on the right by
clicking buttons '' or ''. The elements that
Hi Travis,
we can´t define this. Since UIComponentBase is a class of the spec.
2005/10/27, [EMAIL PROTECTED] [EMAIL PROTECTED]:
Author: prophecy
Date: Wed Oct 26 17:00:12 2005
New Revision: 328766
URL: http://svn.apache.org/viewcvs?rev=328766view=rev
Log:
Fixed autoUpdateDataTable to
I currently don´t know how ajax is working in detail. To find the
serialized view in the server session it is necessary that the
introduced sequence number is being send in the ajax request, which
meight not be the case. I will take a closer look into that.
2005/10/25, Travis Reeder [EMAIL
it out.
Travis
On 10/27/05, Mathias Brökelmann [EMAIL PROTECTED] wrote:
I currently don´t know how ajax is working in detail. To find the
serialized view in the server session it is necessary that the
introduced sequence number is being send in the ajax request, which
meight
I have commited a fix for that allready.
2005/10/25, Travis Reeder [EMAIL PROTECTED]:
Hey Mathias,
Your checkin for this broke the build in HtmlDateRendererTest and
HtmlDateRenderCactus.
Travis
On 10/25/05, Mathias Brökelmann [EMAIL PROTECTED] wrote:
Hi all,
I have improved
AFAIK the 1.1.1 branch is based on trunk rather that 1.1.0.
I agree to Sean that we should get out the 1.1.1 release as soon as possible.
myfaces derives its version numbers from the spec. JSF 1.1 (JSR 127)
is currently implemented which is the reason why we start myfaces
version with 1.1. This
Hi all,
I have improved and refactored Addresource and its dependencies. I
introduced a ResourceLoader interface to allow any component to use
Addresource to render static and dynamic content from any source. This
will allow us (and the user) to create components to render dynamic
javascript,
+1
Mathias
2005/10/25, Werner Punz [EMAIL PROTECTED]:
Sean Schofield wrote:
I think this has dragged on long enough. Apparently there was a bug
introduced in one of the Tomahawk components but I don't think its
worth another prolonged release candidate cycle to address it.
So my
out down the
road that one object way down deep isn't serializable, and only when you
try clustering right before going production :) - but seems like an
unnecessary performance hit at deployment time. Perhaps a flag to
switch between the two?
-- Adam
On 10/19/05, *Mathias
deep isn't serializable, and only when you try
clustering right before going production :) - but seems like an unnecessary
performance hit at deployment time. Perhaps a flag to switch between the
two?
-- Adam
On 10/19/05, Mathias Brökelmann [EMAIL PROTECTED] wrote:
You are right the two
IMO having a max number of views stored in the session is quite
adequate for this. If the user navigates to other pages the oldest
view is dropped if the max number is reached. Correct me if I´m wrong
but this is different to the RI. AFAIK RI stores the last n views
based on a view. So you can end
I don´t know if forrest 0.7 is working but try to define your
FORREST_HOME to f:\apache-forrest-0.7\main
of use forrest-0.6 with f:\apache-forrest-0.6\src\core as FORREST_HOME
2005/10/20, sharath reddy [EMAIL PROTECTED]:
Hello,
I tried the usual 'ant dist' command, but I got the
following
to tell end users that their pages will expire after 5
minutes (or 5 hours) rather than saying they can only backtrack 15
views (most end-users have no idea what a view means). Not all of
us need to tune our backtracking based solely on memory usage.
-Mike
On 10/20/05, Mathias Brökelmann
guess that
you grab the SerializedView object with StateManager.saveState(),
and then save off its two components.
Getting per-request state to survive redirect/, like Mario's
proposing,
is a separate issue, as you say.
-- Adam
On 10/18/05, Mathias Brökelmann [EMAIL PROTECTED
You are right the two objects in SerailizedView are serialized and put
into the session.
The instances of the server side state where not serialized before.
This doesn´t affect the component instances since they are only
referenced by class name in the state but it could have an effect on
the
Well, I have not taken a look into the ri for this issue. So I can not
say if it is solved like the ri.
This is what I have done:
If server side state is uses the serialized view is now really
serialized (this was not the case before) into the session by using
the viewid and a sequence number.
+1
2005/10/18, Martin Marinschek [EMAIL PROTECTED]:
+1
regards,
Martin
On 10/18/05, Bill Dudney [EMAIL PROTECTED] wrote:
+1 from me too
I'd be glad to help with the branch/tag stuff if you could do the
build Sean.
TTFN,
-bd-
On Oct 18, 2005, at 8:27 AM, Werner Punz
Redirection is not handled. Neither by client nor by server side state saving.
2005/10/18, Mario Ivankovits [EMAIL PROTECTED]:
Mathias Brökelmann wrote:
If server side state is uses the serialized view is now really
serialized (this was not the case before) into the session by using
Cool down!
If you need a different behavior on rendering the datatabel and are
not able to change the implementation of your bean (which is mostly
the easiest one) you could write your own renderer for the datatable.
Simply subclass the existing renderer from myfaces
you have to call super.encodeBegin(facesContext, uiComponent) after
the getValue() call of course.
2005/10/12, Mathias Brökelmann [EMAIL PROTECTED]:
Cool down!
If you need a different behavior on rendering the datatabel and are
not able to change the implementation of your bean (which
I haven´t created a patch for this issue for time reasons. That´s the
reason why it is still open. We solved this problem by using a
formatted string which is returned by numberValue. Of course this is
not the best thing but saved us a lot of time.
Perhaps someone (maybe you) is able to create
it´s a subversion revision number (continuous number). If you use the
latest version from svn you are able to determine if you have the
patch in your workingcopy or not.
You can also wait for the next nightly of course.
Have a look at:
http://svn.apache.org/viewcvs.cgi/myfaces/
for current
I think this is ok, these ids are not part of the component tree. They
should only be unique within the same form. If a form submits it only
post the input fields inside the form so it is necessary to put them
into each form.
2005/9/29, Mike Kienenberger [EMAIL PROTECTED]:
I'm seeing duplicate
at 10:06 +0200, Mathias Brökelmann wrote:
Great! We definitely need a component to render dynamic images.
I took a view into the code and saw that the state is appended to the
image url. IMO it will not work in every case since the state could be
very large and as far as I know
I´m a little bit confused now.
I´ve committed a patch for MYFACES-636 into the trunk. This patch
should also go into the next release. So I normally would commit this
patch into the 1.1.1 release branch too. But if someone merges
everything after r292232 from the branch into the trunk again
-09-29 at 15:49 +0200, Mathias Brökelmann wrote:
I would prefer dynamicGraphicImage.
2005/9/29, Sylvain Vieujot [EMAIL PROTECTED]:
I just would like to settle on this, as the earlier we do the rename, the
easiest it'll be.
Any opinion on those graphicImageBytes downloadBytes names
dynaImage?
sean
On 9/28/05, Mathias Brökelmann
[EMAIL PROTECTED] wrote:
Great! We definitely need a component to render dynamic images.
I took a view into the code and saw that the state is appended to the
image url. IMO it will not work in every case since the state could
Great! We definitely need a component to render dynamic images.
I took a view into the code and saw that the state is appended to the
image url. IMO it will not work in every case since the state could be
very large and as far as I know there is a limitation around 1024
chars in a request url.
IMO it´s better if we fix a bug in both trunk and the branch. Trunk is
used by more users (either by svn or through the nightlies). This will
give us more feedback if a bugfix introduces a new bug.
2005/9/28, Sean Schofield [EMAIL PROTECTED]:
Bugs that have been introduced on the branch (ex.
Congratulations Werner!
It´s a pleasure to have you in the team! :)
--
Mathias
Great!
Do we have some info about how many times the new myfaces release has
been downloaded?
2005/9/27, Enrique Medina [EMAIL PROTECTED]:
Congratulations ;-)
2005/9/27, Werner Punz [EMAIL PROTECTED]:
Martin Marinschek wrote:
Congratulations to the team!
We have had a 100.000 hits
ROTFL
2005/9/27, Martin Marinschek [EMAIL PROTECTED]:
Eventually we should rename myfaces-all.jar to
myfaces-api-impl-tomahawk.jar as well, so as to ensure users know what
is in there ;)
--
Mathias
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
It looks like a problem with the setter method setSystem(...) in DealBean.
Can you post a stacktrace and the signature for the setter method?
2005/9/20, Cash, Jamie [EMAIL PROTECTED]:
I have found a problem with the selectOneListBox on the new myfaces release
(1.1.0).
When creatng a listbox
you are using Suns RI not myfaces.
2005/9/20, Cash, Jamie [EMAIL PROTECTED]:
There is no setter method as the list is generated, and cannot be set. Stack
trace as follows:
java.lang.IllegalArgumentException: Conversion Error setting value ''{0}''
for ''{1}''.
at
Message-
From: Mathias Brökelmann [mailto:[EMAIL PROTECTED]
Sent: 20 September 2005 13:57
To: MyFaces Development
Subject: Re: h:selectOneListBox bug
you are using Suns RI not myfaces.
2005/9/20, Cash, Jamie [EMAIL PROTECTED]:
There is no setter method as the list is generated
Enrique ask me to close this issue since he was not able to reproduce
this bug with a latest nightly.
2005/9/15, Bill Dudney [EMAIL PROTECTED]:
Hi Enrique,
Have you looked at the comments? Mathias is unable to reproduce the problem
with the nightly build. Any chance you could try a recent
+1
--
Mathias
2005/9/9, Manfred Geiler [EMAIL PROTECTED]:
+1
Thanks Sean,
-Manfred
2005/9/9, Sean Schofield [EMAIL PROTECTED]:
So are we ok to build a release candidate now? If so, I will try and
get one up this weekend.
sean
On 9/8/05, Manfred Geiler [EMAIL PROTECTED] wrote:
I think I have found a fix for the datascroller issue. Take a look at that.
2005/9/7, Bruno Aranda [EMAIL PROTECTED]:
+1 If in this 24-48 hours period this bug has not been resolved, we
can prepare the new release without the last patches...
Bruno
2005/9/7, Sean Schofield [EMAIL
Just a note. JDK1.5 is able to produce 1.4 classes. We could change
the build process to let the user choose which target he needs and
still provide 1.4 classes (or both) in the releases. But let us bring
the next release out before going that way.
2005/9/7, Ed Burns [EMAIL PROTECTED]:
On Wed,
We had the same problem here entering UTF-8 characters.
That´s what we have done:
- define the content type of the page as UTF-8 (as Eric already said)
- define the attribute acceptCharset=UTF-8 for h:form
- the tricky part: the browser uses the charset which you have
specified by the attribute
blame on me.
I thought shared is available in api. But it doesn´t :(
2005/9/2, Oliver Rossmueller [EMAIL PROTECTED]:
The latest HEAD does not build because of the new SelectItemsIterator in
shared used by UISelectOne. Actually I could not find the place where
the shared sources are compiled
Hi Kai,
very nice.
I think you forgot to add the patch for the tomahawk.tld file.
2005/9/1, Kai Heinecke [EMAIL PROTECTED]:
Dear developers.
We had a minor problem using the very nice t:inputDate/: The dates we
are working on have to be in GMT. With h:outputText/ it is easy to use
1 - 100 of 101 matches
Mail list logo
