Re: character encoding in AJAX requests...suggestions?
Gerald Müllan schrieb: Hi, I like the idea of having an own attribute for the char encoding and putting this value to the ajax request. We can set encoding type in the phaselistener without waiting for the explicit call to the component itself. Can be done right at the beginning and also looks like a more generic solution. Two possible solutions a) make an ajax encoding tag, which sets a javascript global which then the controls can tap in to determine the encoding we would need a javascript globals tag anyway, for other things like having a notifier in the page etc... b) try to get the encoding from the outerlying controls (i had the assumption that ajax uses the encoding anyway, which seems to be a wrong assumption), with an override functionality
[jira] Created: (TOMAHAWK-446) when enter a wrong url or file name, no action are available
when enter a wrong url or file name, no action are available Key: TOMAHAWK-446 URL: http://issues.apache.org/jira/browse/TOMAHAWK-446 Project: MyFaces Tomahawk Type: Bug Components: File Upload Versions: 1.1.1 Environment: windows XP, jdk1.4.2, weblogic 8.1 Reporter: Nguyen Ngoc Hieu Thien Priority: Critical when enter a wrong url or file name, it does not submit and all actions are no longer available. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-438) Schedule Component TLD changes
[ http://issues.apache.org/jira/browse/TOMAHAWK-438?page=comments#action_12413076 ] Jurgen Lust commented on TOMAHAWK-438: -- Hmm, apparently you did not update the sandbox examples, could you test your changes on the provided examples, and then also provide a patch for the examples? Schedule Component TLD changes -- Key: TOMAHAWK-438 URL: http://issues.apache.org/jira/browse/TOMAHAWK-438 Project: MyFaces Tomahawk Type: Improvement Components: Schedule Versions: 1.1.3-SNAPSHOT Environment: All Reporter: Julian Ray Assignee: Jurgen Lust Fix For: 1.1.3-SNAPSHOT Attachments: schedule-patch.txt I would like to propose some changes to the TLD for the sandbox Schedule component as follows: [1] Add a requried mode property (String) with values day workweek week month [2] Add an optional selectedDate property (Date) value binding which sets the current date [3] Change the definition of the entryRenderer property to be an optional value binding. The reasons for [1] and [2] are that it allows better seperation of the model from the view (and backing bean if used) especially for key view properties. These properties must currently be set on the model which propagates their effect to the view. [3] is motivated by a need to subclass ScheduleEntryRenderer and allow additional properties to be used during the rendering. Currently, the property takes a class name and creates an instance using a default constructor. I can submit a patch implementing these changes. Julian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Command Link / Dummy Form: Status Report Please?
Hi Sean! It looks like the key guys are rather busy these days. What is the current plan and what do we do for current users? Do we need an intermediate release that addresses things in a backwards compatible way? The current tomahawk head is fixed in a way, that the dummyForm stuff is disabled by default. So parts of tomahawk again work with JSF-RI. Those using myfaces-impl (and require this feature) can reenable it by put some text in its local faces-config.xml (we have to describe in the release notes) For sure, if we release myfaces with this setup the dummyForm will become unknown in the mid term. I think there is nothing bad with this, but I cant decide this alone, though, others already expressed that we are going to deprecate the dummyForm feature. Would be best to start an official vote about it, no? Ciao, Mario
Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting]
There is no 1.1 compliant way of fixing dummyform - there just isn't. I would have gone with a single branch for 1.2 and checking in TC5.5 compatible stuff only, but Stan has already worked on 1.2, and he has implemented also TC6 depending things, so no chance to go with this, except we want to loose what Stan did, and I wouldn't. I want to do development on the 1.1 branch for bugfixes only anymore. 1.2 is our future, and we should go there! regards, Martin On 5/23/06, Sean Schofield [EMAIL PROTECTED] wrote: Are we talking about the fix for DummyForm? Are we not going to attempt to have a 1.1 compatible fix? What about a single branch for 1.2 and only check in the Tomcat 5.5 compatible stuff? I agree with Craig that you don't want to be actively developing on the trunk plus two branches. Trust me, its difficult enough managing this when we have a short-lived branch for a release. -1 for a long-term double branch strategy. Sean On 5/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: It's just that we need the 1.2 features for several things we want to fix right now - and TC6 is still not released, so we can't work with the full feature set of 1.2. regards, Martin On 5/22/06, Sean Schofield [EMAIL PROTECTED] wrote: Why is there a need to have a separate branch for TC6 vs. TC55. Sorry if I missed the discussion on the need for this ... Sean On 5/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, critical fixes to 1.1. - 1.1 branch major development -- trunk special things for 1.2 under TC6 only -- 1.2 branch With this, it should be albe to merge down the 1.2 branch to the trunk, right? regards, Martin On 5/22/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/21/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok, one more addition to the discussion - I'll want to branches. One for JSF1.2 things which cannot be used together with Tomcat 5.5 and, one for JSF1.2 things which can be used with Tomcat 5.5. I'd love trunk to be the JSF1.2/Tomcat 5.5 branch, and have bug fixes for 1.1 on a real branch. summary: 1.1 -- branch 1.2 Tomcat 6 -- branch 1.2 Tomcat 5.5. -- trunk is that ok? Wouldn't this mean that every change that worked under 5.5 would need to be committed to both branches? That seems like a good way to slow down the effort to achieve 1.2 compliance. regards, Martin Craig On 5/19/06, Stan Silvert [EMAIL PROTECTED] wrote: That would be fine. After I am done we may need some help from Sean. He was talking about putting Tomcat 6 jars in an Apache Maven repository. I've been building with NetBeans and not Maven. So someone who is more Maven savvy will need to update things so it builds correctly. I don't think it will be more complicated than adding and removing some dependencies. Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert -Original Message- From: Manfred Geiler [mailto: [EMAIL PROTECTED] Sent: Thursday, May 18, 2006 8:48 PM To: MyFaces Development Subject: Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting] Sean, Can you please make a copy of the current trunk to /myfaces/core/branches/jsf_1_2 ? After that, Stan can simply (?) merge his stuff inside that. Is that ok, Stan? Manfred On 5/18/06, Sean Schofield [EMAIL PROTECTED] wrote: You want a 1.2 branch for core only using the latest trunk right? I can create it for you if you want ... Sean On 5/18/06, Martin Marinschek [EMAIL PROTECTED] wrote: Manfred, can you go ahead with that 1.2 branch? regards, Martin On 5/18/06, Thomas Spiegl [EMAIL PROTECTED] wrote: I'm having a look at tomahawk 416 +1 for creating a 1.2 branch On 5/18/06, Stan Silvert [EMAIL PROTECTED] wrote: I have implemented most of the new core API's and fixed most of the deprecated ones to be backwards compatible with 1.1 (if you look at the 1.2 javadocs you'll see what I mean). If you look at the section in the spec preface entitled What's Changed Since the Last Release you can get a feel for what I did. I've pretty much done everything in that list. Most of it is covered under this issue, which just says to implement several sections of the spec: http://issues.apache.org/jira/browse/MYFACES-1274 I believe all of 1274
Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting]
So does this mean that our Tomahawk releases are no longer compatible with the RI? That's our current problem right? Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: There is no 1.1 compliant way of fixing dummyform - there just isn't. I would have gone with a single branch for 1.2 and checking in TC5.5 compatible stuff only, but Stan has already worked on 1.2, and he has implemented also TC6 depending things, so no chance to go with this, except we want to loose what Stan did, and I wouldn't. I want to do development on the 1.1 branch for bugfixes only anymore. 1.2 is our future, and we should go there! regards, Martin On 5/23/06, Sean Schofield [EMAIL PROTECTED] wrote: Are we talking about the fix for DummyForm? Are we not going to attempt to have a 1.1 compatible fix? What about a single branch for 1.2 and only check in the Tomcat 5.5 compatible stuff? I agree with Craig that you don't want to be actively developing on the trunk plus two branches. Trust me, its difficult enough managing this when we have a short-lived branch for a release. -1 for a long-term double branch strategy. Sean On 5/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: It's just that we need the 1.2 features for several things we want to fix right now - and TC6 is still not released, so we can't work with the full feature set of 1.2. regards, Martin On 5/22/06, Sean Schofield [EMAIL PROTECTED] wrote: Why is there a need to have a separate branch for TC6 vs. TC55. Sorry if I missed the discussion on the need for this ... Sean On 5/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, critical fixes to 1.1. - 1.1 branch major development -- trunk special things for 1.2 under TC6 only -- 1.2 branch With this, it should be albe to merge down the 1.2 branch to the trunk, right? regards, Martin On 5/22/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/21/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok, one more addition to the discussion - I'll want to branches. One for JSF1.2 things which cannot be used together with Tomcat 5.5 and, one for JSF1.2 things which can be used with Tomcat 5.5. I'd love trunk to be the JSF1.2/Tomcat 5.5 branch, and have bug fixes for 1.1 on a real branch. summary: 1.1 -- branch 1.2 Tomcat 6 -- branch 1.2 Tomcat 5.5. -- trunk is that ok? Wouldn't this mean that every change that worked under 5.5 would need to be committed to both branches? That seems like a good way to slow down the effort to achieve 1.2 compliance. regards, Martin Craig On 5/19/06, Stan Silvert [EMAIL PROTECTED] wrote: That would be fine. After I am done we may need some help from Sean. He was talking about putting Tomcat 6 jars in an Apache Maven repository. I've been building with NetBeans and not Maven. So someone who is more Maven savvy will need to update things so it builds correctly. I don't think it will be more complicated than adding and removing some dependencies. Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert -Original Message- From: Manfred Geiler [mailto: [EMAIL PROTECTED] Sent: Thursday, May 18, 2006 8:48 PM To: MyFaces Development Subject: Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting] Sean, Can you please make a copy of the current trunk to /myfaces/core/branches/jsf_1_2 ? After that, Stan can simply (?) merge his stuff inside that. Is that ok, Stan? Manfred On 5/18/06, Sean Schofield [EMAIL PROTECTED] wrote: You want a 1.2 branch for core only using the latest trunk right? I can create it for you if you want ... Sean On 5/18/06, Martin Marinschek [EMAIL PROTECTED] wrote: Manfred, can you go ahead with that 1.2 branch? regards, Martin On 5/18/06, Thomas Spiegl [EMAIL PROTECTED] wrote: I'm having a look at tomahawk 416 +1 for creating a 1.2 branch On 5/18/06, Stan Silvert [EMAIL PROTECTED] wrote: I have implemented most of the new core API's and fixed most of the deprecated ones to be backwards compatible with 1.1 (if you look at the 1.2 javadocs you'll see what I mean). If you look at the section in the spec preface entitled What's Changed Since the Last Release you can get a feel for what I did.
Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting]
No. The current build should be compatible again - if I don't have old information here... regards, Martin On 5/24/06, Sean Schofield [EMAIL PROTECTED] wrote: So does this mean that our Tomahawk releases are no longer compatible with the RI? That's our current problem right? Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: There is no 1.1 compliant way of fixing dummyform - there just isn't. I would have gone with a single branch for 1.2 and checking in TC5.5 compatible stuff only, but Stan has already worked on 1.2, and he has implemented also TC6 depending things, so no chance to go with this, except we want to loose what Stan did, and I wouldn't. I want to do development on the 1.1 branch for bugfixes only anymore. 1.2 is our future, and we should go there! regards, Martin On 5/23/06, Sean Schofield [EMAIL PROTECTED] wrote: Are we talking about the fix for DummyForm? Are we not going to attempt to have a 1.1 compatible fix? What about a single branch for 1.2 and only check in the Tomcat 5.5 compatible stuff? I agree with Craig that you don't want to be actively developing on the trunk plus two branches. Trust me, its difficult enough managing this when we have a short-lived branch for a release. -1 for a long-term double branch strategy. Sean On 5/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: It's just that we need the 1.2 features for several things we want to fix right now - and TC6 is still not released, so we can't work with the full feature set of 1.2. regards, Martin On 5/22/06, Sean Schofield [EMAIL PROTECTED] wrote: Why is there a need to have a separate branch for TC6 vs. TC55. Sorry if I missed the discussion on the need for this ... Sean On 5/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, critical fixes to 1.1. - 1.1 branch major development -- trunk special things for 1.2 under TC6 only -- 1.2 branch With this, it should be albe to merge down the 1.2 branch to the trunk, right? regards, Martin On 5/22/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/21/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok, one more addition to the discussion - I'll want to branches. One for JSF1.2 things which cannot be used together with Tomcat 5.5 and, one for JSF1.2 things which can be used with Tomcat 5.5. I'd love trunk to be the JSF1.2/Tomcat 5.5 branch, and have bug fixes for 1.1 on a real branch. summary: 1.1 -- branch 1.2 Tomcat 6 -- branch 1.2 Tomcat 5.5. -- trunk is that ok? Wouldn't this mean that every change that worked under 5.5 would need to be committed to both branches? That seems like a good way to slow down the effort to achieve 1.2 compliance. regards, Martin Craig On 5/19/06, Stan Silvert [EMAIL PROTECTED] wrote: That would be fine. After I am done we may need some help from Sean. He was talking about putting Tomcat 6 jars in an Apache Maven repository. I've been building with NetBeans and not Maven. So someone who is more Maven savvy will need to update things so it builds correctly. I don't think it will be more complicated than adding and removing some dependencies. Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert -Original Message- From: Manfred Geiler [mailto: [EMAIL PROTECTED] Sent: Thursday, May 18, 2006 8:48 PM To: MyFaces Development Subject: Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting] Sean, Can you please make a copy of the current trunk to /myfaces/core/branches/jsf_1_2 ? After that, Stan can simply (?) merge his stuff inside that. Is that ok, Stan? Manfred On 5/18/06, Sean Schofield [EMAIL PROTECTED] wrote: You want a 1.2 branch for core only using the latest trunk right? I can create it for you if you want ... Sean On 5/18/06, Martin Marinschek [EMAIL PROTECTED] wrote: Manfred, can you go ahead with that 1.2 branch? regards, Martin On 5/18/06, Thomas Spiegl [EMAIL PROTECTED] wrote: I'm having a look at tomahawk 416 +1 for creating a 1.2 branch On 5/18/06, Stan Silvert [EMAIL PROTECTED] wrote: I have implemented most of the new core API's and fixed most of the deprecated ones to be
Re: Command Link / Dummy Form: Status Report Please?
OK so the only issue with Tomahawk head is that people need to add h:form around there components right? That will be a pain for users who are in production but I guess its the best we can do. Do we need a new core release or is this just tomahawk only? If you think we are ready I will create the tomahawk branch now. Sean On 5/24/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Sean! It looks like the key guys are rather busy these days. What is the current plan and what do we do for current users? Do we need an intermediate release that addresses things in a backwards compatible way? The current tomahawk head is fixed in a way, that the dummyForm stuff is disabled by default. So parts of tomahawk again work with JSF-RI. Those using myfaces-impl (and require this feature) can reenable it by put some text in its local faces-config.xml (we have to describe in the release notes) For sure, if we release myfaces with this setup the dummyForm will become unknown in the mid term. I think there is nothing bad with this, but I cant decide this alone, though, others already expressed that we are going to deprecate the dummyForm feature. Would be best to start an official vote about it, no? Ciao, Mario
Re: Command Link / Dummy Form: Status Report Please?
Hi! OK so the only issue with Tomahawk head is that people need to add h:form around there components right? Or - if they use myfaces-impl too - to add some text to their own faces-config.xml Do we need a new core release or is this just tomahawk only? I wont put my mother on it, but I guess tomahawk only is sufficient. Hmmm I'll test this. If you think we are ready I will create the tomahawk branch now. From my point of view we are ready, I'll test the above and will tell you tomorrow if it works. Ciao, Mario
Re: Command Link / Dummy Form: Status Report Please?
If it's going to be as simple as adding some config to the config file to retain backward compatibility, I'm +1 on releasing with that. If it means adding h:form I'm MOST DEFINITELY -1. We certainly cannot foist this onto our users. On 5/24/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! OK so the only issue with Tomahawk head is that people need to add h:form around there components right?Or - if they use myfaces-impl too - to add some text to their ownfaces-config.xml Do we need a new core release or is this just tomahawk only?I wont put my mother on it, but I guess tomahawk only is sufficient.Hmmm I'll test this. If you think we are ready I will create the tomahawk branch now. From my point of view we are ready, I'll test the above and will tellyou tomorrow if it works.Ciao,Mario-- Grant Smith
Re: Command Link / Dummy Form: Status Report Please?
Or - if they use myfaces-impl too - to add some text to their own faces-config.xml This is to be added to the faces-config.xml in tomahawk right? And we can't add it for them because it will break if they are using myfaces core? Or is this added to faces-config.xml in their own personal webapp? We'll definitely want a clear and concise explanation on the website. Lets come up with a clearly worded email and send it to the user list. Mario Sean
Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting]
OK so Stan is past the TC 5.5 point. Why do we need two branches? Can't we just say that 1.2 depends on TC 6.0 or Glassfish? I still think we need to do everything we can to avoid multiple branches. Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: No. The current build should be compatible again - if I don't have old information here... regards, Martin On 5/24/06, Sean Schofield [EMAIL PROTECTED] wrote: So does this mean that our Tomahawk releases are no longer compatible with the RI? That's our current problem right? Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: There is no 1.1 compliant way of fixing dummyform - there just isn't. I would have gone with a single branch for 1.2 and checking in TC5.5 compatible stuff only, but Stan has already worked on 1.2, and he has implemented also TC6 depending things, so no chance to go with this, except we want to loose what Stan did, and I wouldn't. I want to do development on the 1.1 branch for bugfixes only anymore. 1.2 is our future, and we should go there! regards, Martin On 5/23/06, Sean Schofield [EMAIL PROTECTED] wrote: Are we talking about the fix for DummyForm? Are we not going to attempt to have a 1.1 compatible fix? What about a single branch for 1.2 and only check in the Tomcat 5.5 compatible stuff? I agree with Craig that you don't want to be actively developing on the trunk plus two branches. Trust me, its difficult enough managing this when we have a short-lived branch for a release. -1 for a long-term double branch strategy. Sean On 5/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: It's just that we need the 1.2 features for several things we want to fix right now - and TC6 is still not released, so we can't work with the full feature set of 1.2. regards, Martin On 5/22/06, Sean Schofield [EMAIL PROTECTED] wrote: Why is there a need to have a separate branch for TC6 vs. TC55. Sorry if I missed the discussion on the need for this ... Sean On 5/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, critical fixes to 1.1. - 1.1 branch major development -- trunk special things for 1.2 under TC6 only -- 1.2 branch With this, it should be albe to merge down the 1.2 branch to the trunk, right? regards, Martin On 5/22/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/21/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok, one more addition to the discussion - I'll want to branches. One for JSF1.2 things which cannot be used together with Tomcat 5.5 and, one for JSF1.2 things which can be used with Tomcat 5.5. I'd love trunk to be the JSF1.2/Tomcat 5.5 branch, and have bug fixes for 1.1 on a real branch. summary: 1.1 -- branch 1.2 Tomcat 6 -- branch 1.2 Tomcat 5.5. -- trunk is that ok? Wouldn't this mean that every change that worked under 5.5 would need to be committed to both branches? That seems like a good way to slow down the effort to achieve 1.2 compliance. regards, Martin Craig On 5/19/06, Stan Silvert [EMAIL PROTECTED] wrote: That would be fine. After I am done we may need some help from Sean. He was talking about putting Tomcat 6 jars in an Apache Maven repository. I've been building with NetBeans and not Maven. So someone who is more Maven savvy will need to update things so it builds correctly. I don't think it will be more complicated than adding and removing some dependencies. Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert -Original Message- From: Manfred Geiler [mailto: [EMAIL PROTECTED] Sent: Thursday, May 18, 2006 8:48 PM To: MyFaces Development Subject: Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting] Sean, Can you please make a copy of the current trunk to /myfaces/core/branches/jsf_1_2 ? After that, Stan can simply (?) merge his stuff inside that. Is that ok, Stan? Manfred On 5/18/06, Sean Schofield [EMAIL PROTECTED] wrote: You want a 1.2 branch for core only using the latest trunk right? I can create it for you if you want ... Sean On 5/18/06, Martin Marinschek [EMAIL PROTECTED] wrote: Manfred, can you go ahead with that 1.2 branch? regards,
Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting]
Please no multiple branches. Thanks. Dennis Byrne -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 12:56 PM To: 'MyFaces Development', [EMAIL PROTECTED] Subject: Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting] OK so Stan is past the TC 5.5 point. Why do we need two branches? Can't we just say that 1.2 depends on TC 6.0 or Glassfish? I still think we need to do everything we can to avoid multiple branches. Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: No. The current build should be compatible again - if I don't have old information here... regards, Martin On 5/24/06, Sean Schofield [EMAIL PROTECTED] wrote: So does this mean that our Tomahawk releases are no longer compatible with the RI? That's our current problem right? Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: There is no 1.1 compliant way of fixing dummyform - there just isn't. I would have gone with a single branch for 1.2 and checking in TC5.5 compatible stuff only, but Stan has already worked on 1.2, and he has implemented also TC6 depending things, so no chance to go with this, except we want to loose what Stan did, and I wouldn't. I want to do development on the 1.1 branch for bugfixes only anymore. 1.2 is our future, and we should go there! regards, Martin On 5/23/06, Sean Schofield [EMAIL PROTECTED] wrote: Are we talking about the fix for DummyForm? Are we not going to attempt to have a 1.1 compatible fix? What about a single branch for 1.2 and only check in the Tomcat 5.5 compatible stuff? I agree with Craig that you don't want to be actively developing on the trunk plus two branches. Trust me, its difficult enough managing this when we have a short-lived branch for a release. -1 for a long-term double branch strategy. Sean On 5/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: It's just that we need the 1.2 features for several things we want to fix right now - and TC6 is still not released, so we can't work with the full feature set of 1.2. regards, Martin On 5/22/06, Sean Schofield [EMAIL PROTECTED] wrote: Why is there a need to have a separate branch for TC6 vs. TC55. Sorry if I missed the discussion on the need for this ... Sean On 5/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, critical fixes to 1.1. - 1.1 branch major development -- trunk special things for 1.2 under TC6 only -- 1.2 branch With this, it should be albe to merge down the 1.2 branch to the trunk, right? regards, Martin On 5/22/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/21/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok, one more addition to the discussion - I'll want to branches. One for JSF1.2 things which cannot be used together with Tomcat 5.5 and, one for JSF1.2 things which can be used with Tomcat 5.5. I'd love trunk to be the JSF1.2/Tomcat 5.5 branch, and have bug fixes for 1.1 on a real branch. summary: 1.1 -- branch 1.2 Tomcat 6 -- branch 1.2 Tomcat 5.5. -- trunk is that ok? Wouldn't this mean that every change that worked under 5.5 would need to be committed to both branches? That seems like a good way to slow down the effort to achieve 1.2 compliance. regards, Martin Craig On 5/19/06, Stan Silvert [EMAIL PROTECTED] wrote: That would be fine. After I am done we may need some help from Sean. He was talking about putting Tomcat 6 jars in an Apache Maven repository. I've been building with NetBeans and not Maven. So someone who is more Maven savvy will need to update things so it builds correctly. I don't think it will be more complicated than adding and removing some dependencies. Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert -Original Message- From: Manfred Geiler [mailto: [EMAIL PROTECTED] Sent: Thursday, May 18, 2006 8:48 PM To: MyFaces Development Subject: Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting] Sean, Can you please make a copy of the current trunk to /myfaces/core/branches/jsf_1_2 ?
Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting]
@Sean: It's easy - I won't put in the work to do it if I can't work with the version I have at hand. And I can't work with it when it relies on TC6.0 (and I won't switch over to Glassfish right now). I guess that I'll not be the only one. It's as easy as that. I promise to be the one to do the merging later on. One more thing: there will be one branch only (JSF 1.2 TC 6) - the trunk will JSF 1.2 TC 5.5. The other branch will be our bugfixes-only JSF1.1 branch - no major work being done there. I'd also say that if we want to get a bugfix in this branch, we should get it in in the JSF 1.2 TC 5.5 as well, right when the bugfix is applied. With this we save ourselves the hassle of merging too much here. @Dennis, you don't see the necessities to start with the major features of the 1.2 implementation right now, even when TC 6.0 is not yet available? regards, Martin On 5/24/06, Dennis Byrne [EMAIL PROTECTED] wrote: Please no multiple branches. Thanks. Dennis Byrne -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 12:56 PM To: 'MyFaces Development', [EMAIL PROTECTED] Subject: Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting] OK so Stan is past the TC 5.5 point. Why do we need two branches? Can't we just say that 1.2 depends on TC 6.0 or Glassfish? I still think we need to do everything we can to avoid multiple branches. Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: No. The current build should be compatible again - if I don't have old information here... regards, Martin On 5/24/06, Sean Schofield [EMAIL PROTECTED] wrote: So does this mean that our Tomahawk releases are no longer compatible with the RI? That's our current problem right? Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: There is no 1.1 compliant way of fixing dummyform - there just isn't. I would have gone with a single branch for 1.2 and checking in TC5.5 compatible stuff only, but Stan has already worked on 1.2, and he has implemented also TC6 depending things, so no chance to go with this, except we want to loose what Stan did, and I wouldn't. I want to do development on the 1.1 branch for bugfixes only anymore. 1.2 is our future, and we should go there! regards, Martin On 5/23/06, Sean Schofield [EMAIL PROTECTED] wrote: Are we talking about the fix for DummyForm? Are we not going to attempt to have a 1.1 compatible fix? What about a single branch for 1.2 and only check in the Tomcat 5.5 compatible stuff? I agree with Craig that you don't want to be actively developing on the trunk plus two branches. Trust me, its difficult enough managing this when we have a short-lived branch for a release. -1 for a long-term double branch strategy. Sean On 5/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: It's just that we need the 1.2 features for several things we want to fix right now - and TC6 is still not released, so we can't work with the full feature set of 1.2. regards, Martin On 5/22/06, Sean Schofield [EMAIL PROTECTED] wrote: Why is there a need to have a separate branch for TC6 vs. TC55. Sorry if I missed the discussion on the need for this ... Sean On 5/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, critical fixes to 1.1. - 1.1 branch major development -- trunk special things for 1.2 under TC6 only -- 1.2 branch With this, it should be albe to merge down the 1.2 branch to the trunk, right? regards, Martin On 5/22/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/21/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok, one more addition to the discussion - I'll want to branches. One for JSF1.2 things which cannot be used together with Tomcat 5.5 and, one for JSF1.2 things which can be used with Tomcat 5.5. I'd love trunk to be the JSF1.2/Tomcat 5.5 branch, and have bug fixes for 1.1 on a real branch. summary: 1.1 -- branch 1.2 Tomcat 6 -- branch 1.2 Tomcat 5.5. -- trunk is that ok? Wouldn't this mean that every change that worked under 5.5 would need to be committed to both branches? That seems like a good way to slow down the effort to achieve 1.2 compliance. regards, Martin Craig On 5/19/06, Stan Silvert [EMAIL PROTECTED] wrote: That would be fine. After I am done we may need some help from Sean. He was talking about putting Tomcat 6 jars in an Apache Maven repository.
Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting]
@Dennis, you don't see the necessities to start with the major features of the 1.2 implementation right now, even when TC 6.0 is not yet available? Yes, 1.2 is important. But I am under the impression I can use facelets until TC 6 is released. Besides, most of the work I do in core is in Junit rather than a container. Dennis Byrne regards, Martin On 5/24/06, Dennis Byrne [EMAIL PROTECTED] wrote: Please no multiple branches. Thanks. Dennis Byrne -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 12:56 PM To: 'MyFaces Development', [EMAIL PROTECTED] Subject: Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting] OK so Stan is past the TC 5.5 point. Why do we need two branches? Can't we just say that 1.2 depends on TC 6.0 or Glassfish? I still think we need to do everything we can to avoid multiple branches. Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: No. The current build should be compatible again - if I don't have old information here... regards, Martin On 5/24/06, Sean Schofield [EMAIL PROTECTED] wrote: So does this mean that our Tomahawk releases are no longer compatible with the RI? That's our current problem right? Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: There is no 1.1 compliant way of fixing dummyform - there just isn't. I would have gone with a single branch for 1.2 and checking in TC5.5 compatible stuff only, but Stan has already worked on 1.2, and he has implemented also TC6 depending things, so no chance to go with this, except we want to loose what Stan did, and I wouldn't. I want to do development on the 1.1 branch for bugfixes only anymore. 1.2 is our future, and we should go there! regards, Martin On 5/23/06, Sean Schofield [EMAIL PROTECTED] wrote: Are we talking about the fix for DummyForm? Are we not going to attempt to have a 1.1 compatible fix? What about a single branch for 1.2 and only check in the Tomcat 5.5 compatible stuff? I agree with Craig that you don't want to be actively developing on the trunk plus two branches. Trust me, its difficult enough managing this when we have a short-lived branch for a release. -1 for a long-term double branch strategy. Sean On 5/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: It's just that we need the 1.2 features for several things we want to fix right now - and TC6 is still not released, so we can't work with the full feature set of 1.2. regards, Martin On 5/22/06, Sean Schofield [EMAIL PROTECTED] wrote: Why is there a need to have a separate branch for TC6 vs. TC55. Sorry if I missed the discussion on the need for this ... Sean On 5/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, critical fixes to 1.1. - 1.1 branch major development -- trunk special things for 1.2 under TC6 only -- 1.2 branch With this, it should be albe to merge down the 1.2 branch to the trunk, right? regards, Martin On 5/22/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/21/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok, one more addition to the discussion - I'll want to branches. One for JSF1.2 things which cannot be used together with Tomcat 5.5 and, one for JSF1.2 things which can be used with Tomcat 5.5. I'd love trunk to be the JSF1.2/Tomcat 5.5 branch, and have bug fixes for 1.1 on a real branch. summary: 1.1 -- branch 1.2 Tomcat 6 -- branch 1.2 Tomcat 5.5. -- trunk is that ok? Wouldn't this mean that every change that worked under 5.5 would need to be committed to both branches? That seems like a good way to slow down the effort to achieve 1.2 compliance. regards, Martin Craig On 5/19/06, Stan Silvert [EMAIL PROTECTED] wrote: That would be fine. After I am done we may need some help from Sean. He was talking about putting Tomcat 6 jars in an Apache Maven repository. I've been building with NetBeans and not Maven. So someone who is more Maven savvy will need to update things so it builds correctly. I don't think it will be more complicated than adding and removing some
Multiple SVN Branches (Was -- Re: JSF 1.2)
@Martin, How are you planning to separate the TC 5.5 stuff and TC 6 stuff if Stan has already done the bulk of the JSF 1.2 work necessary? I agree that current Tomcat users will likely stick with Tomcat (I know that's my plan) but to me it seems like the most useful JSF 1.2 stuff is the content interweaving which will require Tomcat 6. My current position is this. If you want JSF 1.2 right now, then you need RI and Glassfish. If you want to stick with MyFaces but still use JSF 1.2 then you will have to wait for MyFaces developers to finish with JSF 1.2 and then use Tomcat 6 if its ready. Otherwise use MyFaces 1.2 with Glassfish or some other server. For development purposes, can't we all be using glassfish, or some other JEE 5.0 app server? This extra branch seems to serve a very narrow purpose. People who want some of the JSF 1.2 features but don't want to use anything else besides Tomcat. Maybe I am missing something but that is how I am reading it. IMO this is a big decision and we should make sure everyone is comfortable. For the record, I'm ok with core 1.2 on the trunk and moving core 1.1 to a branch for bug fixes. In fact I recommended this a while ago but I don't remember hearing a lot of support for that idea. Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: @Sean: It's easy - I won't put in the work to do it if I can't work with the version I have at hand. And I can't work with it when it relies on TC6.0 (and I won't switch over to Glassfish right now). I guess that I'll not be the only one. It's as easy as that. I promise to be the one to do the merging later on. One more thing: there will be one branch only (JSF 1.2 TC 6) - the trunk will JSF 1.2 TC 5.5. The other branch will be our bugfixes-only JSF1.1 branch - no major work being done there. I'd also say that if we want to get a bugfix in this branch, we should get it in in the JSF 1.2 TC 5.5 as well, right when the bugfix is applied. With this we save ourselves the hassle of merging too much here. @Dennis, you don't see the necessities to start with the major features of the 1.2 implementation right now, even when TC 6.0 is not yet available? regards, Martin On 5/24/06, Dennis Byrne [EMAIL PROTECTED] wrote: Please no multiple branches. Thanks. Dennis Byrne -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 12:56 PM To: 'MyFaces Development', [EMAIL PROTECTED] Subject: Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting] OK so Stan is past the TC 5.5 point. Why do we need two branches? Can't we just say that 1.2 depends on TC 6.0 or Glassfish? I still think we need to do everything we can to avoid multiple branches. Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: No. The current build should be compatible again - if I don't have old information here... regards, Martin On 5/24/06, Sean Schofield [EMAIL PROTECTED] wrote: So does this mean that our Tomahawk releases are no longer compatible with the RI? That's our current problem right? Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: There is no 1.1 compliant way of fixing dummyform - there just isn't. I would have gone with a single branch for 1.2 and checking in TC5.5 compatible stuff only, but Stan has already worked on 1.2, and he has implemented also TC6 depending things, so no chance to go with this, except we want to loose what Stan did, and I wouldn't. I want to do development on the 1.1 branch for bugfixes only anymore. 1.2 is our future, and we should go there! regards, Martin On 5/23/06, Sean Schofield [EMAIL PROTECTED] wrote: Are we talking about the fix for DummyForm? Are we not going to attempt to have a 1.1 compatible fix? What about a single branch for 1.2 and only check in the Tomcat 5.5 compatible stuff? I agree with Craig that you don't want to be actively developing on the trunk plus two branches. Trust me, its difficult enough managing this when we have a short-lived branch for a release. -1 for a long-term double branch strategy. Sean On 5/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: It's just that we need the 1.2 features for several things we want to fix right now - and TC6 is still not released, so we can't work with the full feature set of 1.2. regards, Martin On 5/22/06, Sean Schofield [EMAIL PROTECTED] wrote: Why is there a need to have a separate branch for TC6 vs. TC55. Sorry if I missed the discussion on the need for this ... Sean On 5/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, critical fixes to 1.1. - 1.1 branch major development -- trunk special things for 1.2 under
Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting]
until TC 6 is released. Besides, most of the work I do in core is in Junit rather than a container. if it is just the availability of jsp 2.1 jars, the jetty folks have their own (public) maven2 repo -Matthias
Re: Multiple SVN Branches (Was -- Re: JSF 1.2)
For the record, I'm ok with core 1.2 on the trunk and moving core 1.1 to a branch for bug fixes. In fact I recommended this a while ago but I don't remember hearing a lot of support for that idea. Let's split the problem in two. @devs - if you are do not agree with 1.2 on trunk, please speak up or let us focus on the second branch issue. Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: @Sean: It's easy - I won't put in the work to do it if I can't work with the version I have at hand. And I can't work with it when it relies on TC6.0 (and I won't switch over to Glassfish right now). I guess that I'll not be the only one. It's as easy as that. I promise to be the one to do the merging later on. One more thing: there will be one branch only (JSF 1.2 TC 6) - the trunk will JSF 1.2 TC 5.5. The other branch will be our bugfixes-only JSF1.1 branch - no major work being done there. I'd also say that if we want to get a bugfix in this branch, we should get it in in the JSF 1.2 TC 5.5 as well, right when the bugfix is applied. With this we save ourselves the hassle of merging too much here. @Dennis, you don't see the necessities to start with the major features of the 1.2 implementation right now, even when TC 6.0 is not yet available? regards, Martin On 5/24/06, Dennis Byrne [EMAIL PROTECTED] wrote: Please no multiple branches. Thanks. Dennis Byrne -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 12:56 PM To: 'MyFaces Development', [EMAIL PROTECTED] Subject: Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting] OK so Stan is past the TC 5.5 point. Why do we need two branches? Can't we just say that 1.2 depends on TC 6.0 or Glassfish? I still think we need to do everything we can to avoid multiple branches. Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: No. The current build should be compatible again - if I don't have old information here... regards, Martin On 5/24/06, Sean Schofield [EMAIL PROTECTED] wrote: So does this mean that our Tomahawk releases are no longer compatible with the RI? That's our current problem right? Sean On 5/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: There is no 1.1 compliant way of fixing dummyform - there just isn't. I would have gone with a single branch for 1.2 and checking in TC5.5 compatible stuff only, but Stan has already worked on 1.2, and he has implemented also TC6 depending things, so no chance to go with this, except we want to loose what Stan did, and I wouldn't. I want to do development on the 1.1 branch for bugfixes only anymore. 1.2 is our future, and we should go there! regards, Martin On 5/23/06, Sean Schofield [EMAIL PROTECTED] wrote: Are we talking about the fix for DummyForm? Are we not going to attempt to have a 1.1 compatible fix? What about a single branch for 1.2 and only check in the Tomcat 5.5 compatible stuff? I agree with Craig that you don't want to be actively developing on the trunk plus two branches. Trust me, its difficult enough managing this when we have a short-lived branch for a release. -1 for a long-term double branch strategy. Sean On 5/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: It's just that we need the 1.2 features for several things we want to fix right now - and TC6 is still not released, so we can't work with the full feature set of 1.2. regards, Martin On 5/22/06, Sean Schofield [EMAIL PROTECTED] wrote: Why is there a need to have a separate branch for TC6 vs. TC55. Sorry if I missed the discussion on the need for this ... Sean On 5/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, critical fixes to 1.1. - 1.1 branch major development -- trunk special things for 1.2 under TC6 only -- 1.2 branch With this, it should be albe to merge down the 1.2 branch to the trunk, right? regards, Martin On 5/22/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/21/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok, one more addition to the discussion - I'll want to branches. One for JSF1.2 things which cannot be used together with Tomcat 5.5 and, one for JSF1.2 things which can be used with Tomcat 5.5. I'd love trunk to be the JSF1.2/Tomcat 5.5 branch, and have bug fixes for 1.1 on a real
[jira] Created: (TOMAHAWK-447) Calendar should ommit next month, prev month ( and ) when readonly is set to true in non-popup mode.
Calendar should ommit next month, prev month ( and ) when readonly is set to true in non-popup mode. -- Key: TOMAHAWK-447 URL: http://issues.apache.org/jira/browse/TOMAHAWK-447 Project: MyFaces Tomahawk Type: Improvement Components: Calendar Environment: non-popup mode Reporter: Julian Ray Priority: Minor Calendar should ommit next month, prev month ( and ) when readonly is set to true. These controls are superflouous and serve only to confuse the user as it looks like the calandar should be clickable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Multiple SVN Branches (Was -- Re: JSF 1.2)
Hi! +1 for branching the current trunk to a core1.1 +1 for working with jsf 1.2 tc5 on the new trunk +1 to allow Stan to commit its work to a core1.2tc6 branch whatever we do with this branch, we wont loose Stans work and it will be best to have it in svn. Whenever we decide to move our focus from 1.2tc5 to 1.2tc6 (which might be the case after a stable tomcat tc6 release) we can successively merge down Stans work - even if we have to do this manually due to the fact that the trunk moved away from the 1.2tc6 branch. As far as I can see, we never ever try to release a version out of the 1.2tc6 branch. So no need to do any special maintainance with this branch - just an archive. Ciao, Mario
[jira] Created: (MYFACES-1311) MyFaces Portlet at Weblogic 8.1 SP5: Request Parameter weren't submitted
MyFaces Portlet at Weblogic 8.1 SP5: Request Parameter weren't submitted Key: MYFACES-1311 URL: http://issues.apache.org/jira/browse/MYFACES-1311 Project: MyFaces Core Type: Bug Versions: 1.1.1, 1.1.3 Environment: Win XP, jdk 1.4.2, Weblogic 8.1 SP 5 Portal Server, MyFacesPortlet, Tested with MyFaces 1.1.1 and MyFaces 1.1.3 Reporter: Stefan Gesigora Priority: Critical While using MyFaces in a portlet at the Weblogic 8.1 SP5 Portal Server the navigation doesn't work in the right way: per FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap() I can't get the request parameters (submitted via commandlink/commandbutton parameter or another parameter via hidden field f.e.) If I added an actionlistener to the commandlink (additionally) TWO requests were submitted: The first with all the correct params and the second without these params... I've tried the whole thing with client- and server-save-state: no differences. Looking in the internals of the requestParameterMap I saw that my wanted params are only request params but not portlet request params. This problem with the two requests were solved putting my backing-bean into the session. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Multiple SVN Branches (Was -- Re: JSF 1.2)
As far as I can see, we never ever try to release a version out of the 1.2tc6 branch. So no need to do any special maintainance with this branch - just an archive. This part confuses me. I was under the impression that Stan was 90% of the way there. So why would we plan on abandoning this work in favor of a watered down version? I still haven't heard a compelling reason for two different branches for JSF 1.2 supported by two different groups of MyFaces committers. We've got 5 - 6 active committers that work on the core on a regular basis. If what Stan has done independently doesn't suit us, then we can choose to ignore it. (I can't say since I haven't looked at it.) But I don't think we should just throw it in to SVN and then start working on a less complete version that works on Tomcat 5. What features of JSF 1.2 that don't require Tomcat do people think we need right *now*? Ciao, Mario Sean
Re: Multiple SVN Branches (Was -- Re: JSF 1.2)
On 5/24/06, Sean Schofield [EMAIL PROTECTED] wrote: As far as I can see, we never ever try to release a version out of the 1.2tc6 branch. So no need to do any special maintainance with this branch - just an archive.This part confuses me.I was under the impression that Stan was 90% of the way there.So why would we plan on abandoning this work infavor of a watered down version?I still haven't heard a compellingreason for two different branches for JSF 1.2 supported by twodifferent groups of MyFaces committers.We've got 5 - 6 active committers that work on the core on a regular basis.If what Stan has done independently doesn't suit us, then we canchoose to ignore it.(I can't say since I haven't looked at it.)ButI don't think we should just throw it in to SVN and then start working on a less complete version that works on Tomcat 5.What features ofJSF 1.2 that don't require Tomcat do people think we need right *now*?There's a separate issue as well ... a partial implementation of 1.2 couldn't pass the TCK, and therefore couldn't be released, either. Ciao, MarioSeanCraig
Re: Multiple SVN Branches (Was -- Re: JSF 1.2)
Do we have an ETA on Tomcat 6? Sean On 5/24/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/24/06, Sean Schofield [EMAIL PROTECTED] wrote: As far as I can see, we never ever try to release a version out of the 1.2tc6 branch. So no need to do any special maintainance with this branch - just an archive. This part confuses me. I was under the impression that Stan was 90% of the way there. So why would we plan on abandoning this work in favor of a watered down version? I still haven't heard a compelling reason for two different branches for JSF 1.2 supported by two different groups of MyFaces committers. We've got 5 - 6 active committers that work on the core on a regular basis. If what Stan has done independently doesn't suit us, then we can choose to ignore it. (I can't say since I haven't looked at it.) But I don't think we should just throw it in to SVN and then start working on a less complete version that works on Tomcat 5. What features of JSF 1.2 that don't require Tomcat do people think we need right *now*? There's a separate issue as well ... a partial implementation of 1.2 couldn't pass the TCK, and therefore couldn't be released, either. Ciao, Mario Sean Craig
Re: DummyForm and myfaces RI compatibility
What is the code exactly? I want to use it in the ultimate release notes, website and email announcement for the next tomahawk version. Sean On 5/17/06, Mario Ivankovits [EMAIL PROTECTED] wrote: So, for now I removed the renderer override in faces-config.xml so parts of tomahawk should work with RI again. If a user still wants to use the dummyForm he/she can add this [1] code to the faces-config.xml Its still time to rollback this change, else I'll post tomorrow something to the user list about this change. Ciao, Mario
[jira] Created: (MYFACES-1312) dependency injection error with ArrayList
dependency injection error with ArrayList
-
Key: MYFACES-1312
URL: http://issues.apache.org/jira/browse/MYFACES-1312
Project: MyFaces Core
Type: Bug
Components: JSR-127
Versions: 1.1.3
Reporter: Rogério Pereira Araújo
Fix For: 1.1.4-SNAPSHOT
I have 3 beans: beanA, beanB (ArrayList) and beanC, i add some items on beanB
from beanA and i need remove few others from beanC, but when i try remove from
beanC i'm getting a IndexOutOfBounds exception.
beanA and beanC is at request scope and beanB is at session scope.
Look this code:
public beanA
{
private ArrayList beanB;
public beanA()
{
}
public String addItem()
{
if(beanB == null)
setBeanB(new ArrayList());
beanB.add(newItem);
return null;
}
public void setBeanB(ArrayList beanB)
{
this.beanB = beanB;
}
}
public beanC
{
private ArrayList beanB;
public beanC()
{
}
public void removeItem(ActionEvent event)
{
beanB.remove(myDataTable.getRowIndex());
return null;
}
public void setBeanB(ArrayList beanB)
{
this.beanB = beanB;
}
}
i haven't added get/set stuff of myDataTable to keep the example simple.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1312) dependency injection error with ArrayList
[
http://issues.apache.org/jira/browse/MYFACES-1312?page=comments#action_12413200
]
Rogério Pereira Araújo commented on MYFACES-1312:
-
i'm using saveState in beanA
dependency injection error with ArrayList
-
Key: MYFACES-1312
URL: http://issues.apache.org/jira/browse/MYFACES-1312
Project: MyFaces Core
Type: Bug
Components: JSR-127
Versions: 1.1.3
Reporter: Rogério Pereira Araújo
Fix For: 1.1.4-SNAPSHOT
I have 3 beans: beanA, beanB (ArrayList) and beanC, i add some items on beanB
from beanA and i need remove few others from beanC, but when i try remove
from beanC i'm getting a IndexOutOfBounds exception.
beanA and beanC is at request scope and beanB is at session scope.
Look this code:
public beanA
{
private ArrayList beanB;
public beanA()
{
}
public String addItem()
{
if(beanB == null)
setBeanB(new ArrayList());
beanB.add(newItem);
return null;
}
public void setBeanB(ArrayList beanB)
{
this.beanB = beanB;
}
}
public beanC
{
private ArrayList beanB;
public beanC()
{
}
public void removeItem(ActionEvent event)
{
beanB.remove(myDataTable.getRowIndex());
return null;
}
public void setBeanB(ArrayList beanB)
{
this.beanB = beanB;
}
}
i haven't added get/set stuff of myDataTable to keep the example simple.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
how can i dynamically reload data in tree controler
Hi , how can i dynamically add node to my tree when i click on the parent node 1.e parent child1 child2 child3 the node i am bringing it from database table treedata when i inserted child4 in my database table treedata and commited and i clicked on parent parent child1 child2 child3 child4 means when i clicked on parent child nodes are to be refreshed with updated database values please help me and send me mail to [EMAIL PROTECTED] with regards shannu -- View this message in context: http://www.nabble.com/how+can+i+dynamically+reload+data+in+tree+controler-t1679506.html#a4554442 Sent from the My Faces - Dev forum at Nabble.com.
