Please welcome Werner Punz as a new committer. Werner has been active
in the MyFaces community for a while now. We actually invited Werner
to become a committer several weeks ago but it took a while for him to
sign his CLA and for the ASF infrastructure pepople to create his
account.
Each new co
Yes that's correct. Lets just make sure Manfred and the other
committers don't have any last minute objections or alternative plans.
Lets figure anytime past 12:00 EST is ok to do the branch. Let me
know when you are starting the branch and I will start the JIRA
change.
Should only take about 1
Hi Sean,
I can and will help tomorrow. I have some stuff to do in my day job
but I'll make time for the branch.
If I understand things correctly we are going to delete the 1.1.0.1
branch I created the other day and create another branch set from the
current trunk and turn that into the re
Yes, you're right, but I was looking for a way to use the same code with a get request instead of a post request.
So, I think this will work.
I'll post this soon so that you can check it.
Thanks,
Sylvain.
On Mon, 2005-09-26 at 23:24 +0200, Martin Marinschek wrote:
The snippet you posted i
Martin Marinschek wrote:
> Congratulations to the team!
>
> We have had a 100.000 hits a day first time on Sept 21.
>
> regards,
>
> Martin
>
was there someone load testing ;-)
no seriously, congratulations.
On 9/26/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> That approach makes sense if you decide not to include the sandbox> components. But, my basic advice still stands ... if you ever *do* combine> two component tag libraries into a single JAR file, go ahead and merge the
> faces-config.xml ent
> That approach makes sense if you decide not to include the sandbox
> components. But, my basic advice still stands ... if you ever *do* combine
> two component tag libraries into a single JAR file, go ahead and merge the
> faces-config.xml entries, but *don't* combine the TLDs. That only creat
On 9/26/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
Well,we came from this merging approach, and decided differently now.the question is - do a a merge of faces-config.xml - or force theusers to have myfaces-all.jar and sandbox.jar in his librarydirectory.
The second option seems to be more si
Yes, a separate subproject is ok,
+1
Bruno
2005/9/27, Thomas Spiegl <[EMAIL PROTECTED]>:
> sounds reasonable
> +1 for separate subproject
>
>
> On 9/26/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > +1
> >
> > for separate subproject just like tomahawk
> >
> > regards,
> >
> > Martin
> >
sounds reasonable
+1 for separate subprojectOn 9/26/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
+1for separate subproject just like tomahawkregards,MartinOn 9/26/05, Sean Schofield <
[EMAIL PROTECTED]> wrote:> For now everything should be more or less separate. Tobago is an> incubator project
We'll need to coordinate the creation of the branch with the version
change in JIRA. Bill are you available to create the branch tomorrow?
If so, please touch base with me tomorrow and we will begin together
(assuming no major objections overnight.) For now keep marking things
fixed in "nightly"
Well,
we came from this merging approach, and decided differently now.
the question is - do a a merge of faces-config.xml - or force the
users to have myfaces-all.jar and sandbox.jar in his library
directory.
The second option seems to be more simple!
regards,
Martin
On 9/27/05, Craig McClana
+1 I like option #3. Thus the show stoppers will also be fixed, and
let's test thoroughly this time :-) ...
Regards,
Bruno
2005/9/27, Sean Schofield <[EMAIL PROTECTED]>:
> The trunk does not have my fix to the build but it does have yours.
> My changes don't matter anymore since we settled on a
The trunk does not have my fix to the build but it does have yours.
My changes don't matter anymore since we settled on a different option
for the sandbox problem. So we are fine to drop the old branch once
we are in agreement.
Lets wait until tomorrow and give some of the Europeans a chance to
It's me the responsible of the 100.000 hits...
... just kidding :D
Good news!
Bruno
2005/9/26, Martin Marinschek <[EMAIL PROTECTED]>:
> Congratulations to the team!
>
> We have had a 100.000 hits a day first time on Sept 21.
>
> regards,
>
> Martin
>
On 9/26/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
You're right, this is how it is right now :
http://myfaces.apache.org/tomahawk, with recommended prefix t: for Tomahawk
http://myfaces.apache.org/sandbox, with recommended prefix s: for Sandbox
http://myfaces.apache.or
I'd like to get the branch 'closed' as soon as possible so I'm in
favor of either 1.1.0.1 as a patch release (option 1) to get the
myfaces-all problem resolved then start rolling on a 1.1.1 release
(option 3).
If we don't do the maintenance release then the branch IMO should be
deleted, w
I suggest you reverse the issue XP way:
choose option 2/3, but set a release schedule:
1.1.1 will be released, let's say, 30/9 17h, with whatever showstopper fixes are ready
1.1.2 will be released 7/10, with whatever showstopper fixes are ready, etc.,
...
and no cheating: what isn't ready 30/9 20
Congratulations to the team!
We have had a 100.000 hits a day first time on Sept 21.
regards,
Martin
With the documentation in place I don't see it necessary to
immediately pull a release.
So let's take option three and roll it slowly!
regards,
Martin
On 9/26/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> We seemed to have settled on doing a 1.1.0 patch release. The one fix
> we know for sur
We seemed to have settled on doing a 1.1.0 patch release. The one fix
we know for sure that is going to be in it is the fix to the TLD and
faces-config.xml regarding the sandbox stuff.
Bill has created a branch for us off the release point. There are one
or two "urgent" bugs being described on t
selectOneMenu calls converter getAsString() with String value instead of object
---
Key: MYFACES-624
URL: http://issues.apache.org/jira/browse/MYFACES-624
Project: MyFaces
Type: Bug
Compone
[
http://issues.apache.org/jira/browse/MYFACES-623?page=comments#action_12330518
]
sean schofield commented on MYFACES-623:
Here is my expression ...
value="#{dialog.data['foo']}"
PropertyResolverImpl is correctly checking for instanceof Map. I b
The snippet you posted is just about remembering the state of the
application client side - it doesn't have to do anything with dynamic
loading of images...
Or do I get you completely wrong?
regards,
Martin
On 9/26/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> You're right, Ajax isn't the p
setValue() method of ValueBindingImpl does not behave properly
--
Key: MYFACES-623
URL: http://issues.apache.org/jira/browse/MYFACES-623
Project: MyFaces
Type: Bug
Components: JSR-127
Versions: 1.1.0
You're right, Ajax isn't the perfect term for this, as the result won't be XML.
But maybe it can work using something similar to that :
" callback: function(element,entry) {return entry+'&jsf_tree_64='+encodeURIComponent(document.getElementById('jsf_tree_64').value)+'&jsf_state_64='+encod
OK thanks for the compromise Sylvain. I will start tweaking the build
file shortly.
sean
On 9/26/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> I agree.
>
>
> On Mon, 2005-09-26 at 14:47 -0600, Bill Dudney wrote:
> Martin's point seals it for me.
>
> Lets keep sandbox, tobago separate. The
I agree.
On Mon, 2005-09-26 at 14:47 -0600, Bill Dudney wrote:
Martin's point seals it for me.
Lets keep sandbox, tobago separate. The last thing we want is
clashing tag names :-)
I am also against a 'special target'. I'd prefer if we could address
this during the move to maven2 (when/
Martin's point seals it for me.
Lets keep sandbox, tobago separate. The last thing we want is
clashing tag names :-)
I am also against a 'special target'. I'd prefer if we could address
this during the move to maven2 (when/if that ever happens).
TTFN,
-bd-
On Sep 26, 2005, at 2:40 PM, S
Sylvain,
We wouldn't keep things in sandbox forever. I was just making the
point that you could download the latest myfaces version and still use
whatever version of sandbox you are using in your
development/production system.
You eventually have to do the "search and replace" as Martin is sayin
This is indeed a very good argument ... even if it make some other thing more complex
On Mon, 2005-09-26 at 22:26 +0200, Martin Marinschek wrote:
One more reason against the one-for-all tld file:
imagine we get in the tobago, adffaces, etc. subprojects - what if
they both include a tag nam
The XMLHttpRequest object (or the equivalent ActiveX control)'s open
method takes as its first argument the request method you want to
use. So you could make a get request simply by saying:
xHR.open("GET", url[, asyncflag][, username][, password]);
I believe that answers your question, but I'm n
One more reason against the one-for-all tld file:
imagine we get in the tobago, adffaces, etc. subprojects - what if
they both include a tag named xxx...
If we lump all the tld files together (and if we follow our reasoning
so far, we should include those subprojects in the common tld file as
wel
Sean,
If you strongly believe in this, couldn't we have 2 "dist-all" ?
One that would drop the sandbox stuffs, and another one (whatever the name) that would be just a copy of the current one.
I don't want to get in the way of the release process, but I still believe that this all in one jar w
[
http://issues.apache.org/jira/browse/MYFACES-611?page=comments#action_12330506
]
Adam Winer commented on MYFACES-611:
When a ConverterException is thrown during Apply Request Values or Process
Validations, the component (not the renderer) should be c
Hello,
I'm trying to make a new component that would display an image, but without the need to have a dedicated servlet.
It would make applications that use images from a lot of different sources (i.e. servlets) much simpler.
Basically, it would be a component like :
As the only way I found
+1 and amen to that. IMHO, sandbox is a separate component lib not yet
part of MyFaces, if you want to use, include its lib and declare a
separate TLD. If you don't want to do that, wait till the components are
accepted as part of official MyFaces.
My 2 cents,
Kalle
> -Original Message-
>
[ http://issues.apache.org/jira/browse/MYFACES-622?page=all ]
Ken Weiner updated MYFACES-622:
---
Attachment: HtmlCheckboxRenderer.java-patch.txt
Patch to HtmlCheckboxRenderer that fixes rendering issues. Appy to top level
project.
> HtmlSelectManyCheckbox
HtmlSelectManyCheckbox rendering is flawed
--
Key: MYFACES-622
URL: http://issues.apache.org/jira/browse/MYFACES-622
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: Nightly Build
Reporter: Ken Weiner
Bill,
We need to get it it out of myfaces-all.jar if we don't want to mix
the faces-config.xml with tomahawk and sandbox stuff (which IMO we
don't want to do.)
sean
On 9/26/05, Bill Dudney <[EMAIL PROTECTED]> wrote:
> +1 on the proposal as outlined by Sean here.
>
> I don't agree that its that
+1 on the proposal as outlined by Sean here.
I don't agree that its that important to get sandbox out of myfaces-
all people would know the difference with a separate tld but I'm also
fine with leaving it as a separate jar file.
TTFN,
-bd-
On Sep 26, 2005, at 1:28 PM, Sean Schofield wrote:
+1
for separate subproject just like tomahawk
regards,
Martin
On 9/26/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> For now everything should be more or less separate. Tobago is an
> incubator project so its not going to be part of myfaces for some
> time. I'm not sure if they are planning
For now everything should be more or less separate. Tobago is an
incubator project so its not going to be part of myfaces for some
time. I'm not sure if they are planning to use the "share" subproject
but they should definitely have their own jar, TLD and
faces-config.xml (same as my position on
Let's make sure we are on the same page here (some stuff I read in
Sylvain's reply leads me to believe we are interpreting Martin's
suggestion differently.)
Here is a new proposal ...
1.) Remove any reference to sandbox from myfaces-all.jar. Zero traces
of sandbox in myfaces-all.jar. This means
Matthias Wessendorf wrote:
> Hi all.
>
> Since the Tobago guys have sent their CLA paperworks to the ASF,
> we now have to decide how that thing will really work :-)
>
> We discussed in an older thread that they are olny committing into the
> "tobago" source code base and not into myfaces (api|co
For now lets keep tobago as its own subproject. I still don't
understand a lot about it but it looks promising. It seems like
tobago is concerned with layout and a bunch of other stuff that's
conceptually different then tomahawk.
But that is what the incubator is for. Let's let it incubate and
One more thing about those TLDs.
I find that having one big tld for each project is quite bad, as it's hard to read and to maintain. It also promotes commit conflicts when 2 developer are working concurrently on different components.
Maybe a better approach would be to have tld snipsets in eac
On 9/26/05, Bill Dudney <[EMAIL PROTECTED]> wrote:
> I like the tobago subproject.
>
> If I'm remembering correctly the idea is that eventually the tobago
> components will be moved to tomahawk. Is that correct or will this
> always be the tobago component set?
Well, I am doing fine with an own co
I too think it makes sens to release the sandbox into the myfaces-all.jar.
But if we do that, then this jar needs to contain a faces-config.xml that merges the ones from tomahawk & from the sandbox (build file, merge-sandbox target).
The process for merging the faces-config.xml files & the tld
I like the tobago subproject.
If I'm remembering correctly the idea is that eventually the tobago
components will be moved to tomahawk. Is that correct or will this
always be the tobago component set?
TTFN,
-bd-
On Sep 26, 2005, at 12:32 PM, Matthias Wessendorf wrote:
Hi all.
Since the
It also seems ok to me, I think that it is a good consensus and having
the tld separated is enough to me...
Bruno
2005/9/26, Bill Dudney <[EMAIL PROTECTED]>:
> I like this approach too. sandbox.jar is separate but part of the
> release.
>
> I'm equally OK with putting the sandbox stuff into the m
Tree2 commandLink not firing until second click
---
Key: MYFACES-621
URL: http://issues.apache.org/jira/browse/MYFACES-621
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: Nightly Build
Environment: Wi
Hi all.
Since the Tobago guys have sent their CLA paperworks to the ASF,
we now have to decide how that thing will really work :-)
We discussed in an older thread that they are olny committing into the
"tobago" source code base and not into myfaces (api|core|tomahawk)
(remember the "gentlement's
I like this approach too. sandbox.jar is separate but part of the
release.
I'm equally OK with putting the sandbox stuff into the myfaces-
all.jar with a separate tld (i.e. don't do the 'all' tld). Users wont
be confused because its in a separate tld.
I don't agree that its a lazy/not lazy
> Issue 2: making an exception for sandbox in the build:
>
> @Sean: Still, I think we shouldn't make an exception to the build for
> the sandbox.jar when releasing - I'd say we just release it as well,
> clearly indicating that this is experimental stuff.
I might be persuaded to accept this route.
Issue 1: creating a one tld comprises them all tld file:
@Sylvain: Sean is right here! we can keep the sandbox component in the
sandbox tld, but move it over to tomahawk.
So you won't have any issues with moving the components over, right?
Issue 2: making an exception for sandbox in the build:
Laziness might be a little bit strong of a word but that's basically
what we're talking about here. When a sandbox component is promoted
you have to change your to .
Including the sandbox in myfaces-all.jar and providing an "all" TLD
allows you to not change your code at all when a component is
ff
And the generation of the myfaces-all TLD is confusing for several
reasons. This adds yet another way to reference a tomahawk component
from the already dizzying array of choices.
So tomahawk can be referenced using:
http://myfaces.apache.org/extensions
http://myfaces.apache.org/tomahawk
http://
> Having multiple jar files increases the chance of one of the jar files
> being out of sync with another one of the files. I'd imagine that
> the sandbox components are often dependent on a specific tomahawk
> version.
Its not possible for them to be out of sync during the build and in
the rele
[
http://issues.apache.org/jira/browse/MYFACES-547?page=comments#action_12330488
]
Sh Ma commented on MYFACES-547:
---
One more thing... the autoUpdateDataTable element doesn't seem to evaluate
value binding expressions. For example, if I have an initializati
I demoed using modes at JavaOne. You can
find my slides on Sun’s site. Also, I wrote up some stuff on the MyFaces
wiki and my JBoss blog:
http://wiki.apache.org/myfaces/UsingPortletModes
http://jboss.org/jbossBlog/blog/Stan%20Silvert/
Because the JSF spec doesn’t cover
modes, it
You're right, this is how it is right now :
http://myfaces.apache.org/tomahawk, with recommended prefix t: for Tomahawk
http://myfaces.apache.org/sandbox, with recommended prefix s: for Sandbox
http://myfaces.apache.org/all, with recommended prefix x: for All components (Toma
I don't use the sandbox stuff (yet), but I think that it should be
included in the myfaces-all jar, provided it has a different tld file
(ie, sandbox:component rather than t:component"), and I believe that
this is already the case. If it requires a different prefix, no one
is going to accidentall
[ http://issues.apache.org/jira/browse/MYFACES-564?page=all ]
Mathias Broekelmann closed MYFACES-564:
---
Resolution: Fixed
fixed in r291646
showRootNode=false was the problem. If the root node is not rendered (simply
skipped) it was also not e
[ http://issues.apache.org/jira/browse/MYFACES-564?page=all ]
Martin Marinschek reopened MYFACES-564:
---
Reopen as per request of Mathias
> tree2 node toggle is alway immediate if server side toggle is used.
> --
[
http://issues.apache.org/jira/browse/MYFACES-564?page=comments#action_12330474
]
Mathias Werlitz commented on MYFACES-564:
-
Above comment includes a test case (cannot upload a file on a closed issue)
The actionlistener and the action method are N
[
http://issues.apache.org/jira/browse/MYFACES-564?page=comments#action_12330473
]
Mathias Werlitz commented on MYFACES-564:
-
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<[EMAIL PROTECTED]
[ http://issues.apache.org/jira/browse/MYFACES-617?page=all ]
sean schofield closed MYFACES-617:
--
Resolution: Duplicate
> tree2 invalid bit mask
> --
>
> Key: MYFACES-617
> URL: http://issues.apache.org/jira/br
no, no special reasons ;)
go ahead and provide a patch to up the version number!
regards,
Martin
On 9/26/05, Werner Punz <[EMAIL PROTECTED]> wrote:
> I just have a minor question, is there any reason why the jsf examples
> use an older common codecs version than 1.3? (1.2 I assume)
>
> 1.3 has
[
http://issues.apache.org/jira/browse/MYFACES-618?page=comments#action_12330469
]
Alexandr Smirnov commented on MYFACES-618:
--
All true, tree2 don't working with RI and server-side state saving. But work
with MyFaces and RI with client-side saving
Hello Sean,
It's not a question of laziness.
As said before, having one common jar is very useful when you develop a component there, and when it's moved in production later.
I don't agree excluding it just because there was an unfortunate bug that hasn't been fixed in time for an important re
[
http://issues.apache.org/jira/browse/MYFACES-618?page=comments#action_12330465
]
Julien Gomez commented on MYFACES-618:
--
I found how to use tree2 in "Expand/Collapse Handled By Server" mode, i check
the sample faces-config.xml and the difference wit
[ http://issues.apache.org/jira/browse/MYFACES-588?page=all ]
Bruno Aranda reopened MYFACES-588:
--
Assign To: Bruno Aranda
Doh! My fault there, now I don't have access to the code source till tomorrow.
Can someone revert it? Only the class
org.ap
[
http://issues.apache.org/jira/browse/MYFACES-588?page=comments#action_12330460
]
Keijo Nurmes commented on MYFACES-588:
--
Auts! This fix has nasty side effects.
All menuitems (and childItems) where split=true disappear.
So either this patch should
I just have a minor question, is there any reason why the jsf examples
use an older common codecs version than 1.3? (1.2 I assume)
1.3 has been around since ages, and probably the version can be bumped
up a little bit.
Hi,
Effectively the simple.war WebApp with JSF RI works fine, I'll try to
figure out what's going wrong with my code, sorry to submit a wrong bug,
Regards, Julien
-Original Message-
From: sean schofield (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 24, 2005 8:09 PM
To: Jul
-Original Message-
I don't see how excluding sandbox stuff from myfaces-all.jar will take
anything away from our users. If you want to use the sandbox stuff
you just need two jars: myfaces-all.jar and sandbox.jar.
-/Original Message-
true
-Original Message-
I like Sylvain'
[
http://issues.apache.org/jira/browse/MYFACES-617?page=comments#action_12330457
]
Mathias Werlitz commented on MYFACES-617:
-
This is a known issue ... see MYFACES-568.
> tree2 invalid bit mask
> --
>
> Key: MYFACES-61
[
http://issues.apache.org/jira/browse/MYFACES-546?page=comments#action_12330454
]
Thomas Huber commented on MYFACES-546:
--
The Problem is this line "receiver.innerHTML = response;" in the prototype.js
file.
the IE cannot assign response to receiver.in
[
http://issues.apache.org/jira/browse/MYFACES-552?page=comments#action_12330453
]
Thomas Huber commented on MYFACES-552:
--
"irreproducible" mean i cannot reproduce the problem. i tested it with J2SE 5.0
and Tomcat 5.0.28 without tiles!
there are no pr
81 matches
Mail list logo
