Re: Retest of Core 1.1.3
>Thanks. I rebuilt the core so please retest as soon as you can. All pass. >Sean Dennis Byrne
Proposal idea for Declarative Ajax project
Hello, MyFaces committers and contributors: I'm writing to this list because I'm about to propose a new project to the Incubator that is related to MyFaces: See http://wiki.apache.org/incubator/XapProposal for the proposal. I wanted to let folks on this list know in case there are any ideas out there on if/how our two projects (should this one be approved) could collaborate. I'd like to do everything possible to share ideas/ code and make the XAP project useful to MyFaces, but if that doesn't make sense, i thought that you should at least know it's about to be proposed so you can voice your opinions on the incubator list before it goes to a vote. And, of course, if you're interested enough to want to be involved at all, please let me know that too! Best regards, Coach K Wei One Van de Graaff Drive, Burlington, MA 01803 (781) 345 5435
RE: Interested in this?
Martin,This seems to be a harmless change. Can it be commited by someone who has commit privileges?Thanks,--MikeMartin Marinschek Fri, 28 Apr 2006 01:27:06 -0700 Hi Claudio,do you think this would be a good addition?http://issues.apache.org/jira/browse/TOMAHAWK-388regards, Martin
[jira] Created: (TOMAHAWK-407) Tomahawk org.apache.myfaces.component.html.ext.HtmlDataTable.findComponent bug (numeric format exception at line 143)
Tomahawk org.apache.myfaces.component.html.ext.HtmlDataTable.findComponent bug (numeric format exception at line 143) - Key: TOMAHAWK-407 URL: http://issues.apache.org/jira/browse/TOMAHAWK-407 Project: MyFaces Tomahawk Type: Bug Versions: 1.1.3-SNAPSHOT Environment: any Reporter: Mikhail Grushinskiy When using forceIdIndexFormula which generates id as astring I'm receiving the following exception. It happens if I have on same form. It should allow to use non numeric indexes too in case of forceIdIndexFormula. I had to use this formula to compensate for missing generated Ids in master/detail table to combine master and detail IDs into single index value. java.lang.NumberFormatException: For input string: "895o2397" at java.lang.NumberFormatException.forInputString(NumberFormatException.jav a:48) at java.lang.Integer.parseInt(Integer.java:456) at java.lang.Integer.valueOf(Integer.java:553) at org.apache.myfaces.component.html.ext.HtmlDataTable.findComponent(HtmlDa taTable.java:143) at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.java :426) at org.apache.myfaces.component.html.ext.HtmlDataTable.findComponent(HtmlDa taTable.java:152) at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.java :426) at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.java :426) at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.java :426) at org.apache.myfaces.renderkit.html.ext.HtmlMessageRenderer.findInputLabel (HtmlMessageRenderer.java:158) -- 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: AJAX functionality in MyFaces
I'll be checking the facelets upgrades in soon, but to handle the
'multiple' case below, I use request/response headers instead of writing
to the body of the response. This allows many components to return many
types of responses without issue of formatting the body-- each
component/clientId gets their own 'container'.
Adam Winer wrote:
On 5/1/06, Travis Reeder <[EMAIL PROTECTED]> wrote:
Great comments Sharath and I agree with all of them.
On 4/28/06, sharath reddy <[EMAIL PROTECTED]> wrote:
> Here are some of the inputs we came up with:
> 1. There are too many special cases in the Phase
> Listener code:
>
> if (component instanceof SuggestAjax) //do something
> if (component instanceof HtmlCommandButtonAjax)
> if (ajaxComponent instanceof UIComponentPerspective)
> ...
>
> In our opinion, all this logic should be moved into
> their respective components. The phase listener should
> not be aware of these distinctions.
Definitely.
I totally agree - the big question is what the contract
is between a phase listener or lifecycle and the individual
components. Adding a specific interface that must
be implemented, especially at the component level, is,
IMO, undesirable - the approach Jacob suggests is more
flexible.
> 2. The responsibility for rendering the response
> should lie entirely with the component. The current
> code does something like this:
>
> out.print("\n");
>
> out.print("\n");
>
> ((AjaxComponent) component).encodeAjax(context);
>
> out.print("");
>
> Due to this approach, the component-writer has 2
> disadvantages:
> a. He is forced to render an xml response. Other
> options are ruled out.
> b. If he wants to use an XML API (say, JDOM) to render
> the response, he is contrained, as the root element
> 'response' has already been rendered in the output
> stream.
Good point, this could easily be moved into AjaxRendererUtils.encodeAjax
since most of the form components just call back to that anyways to
handle
common cases. I was heading in a different direction with the generic
listener update, where it would send the response wrapper and put the
pay
dirt in a cdata section, but it may be easier to just return
different types
of responses depending on the component.
I'm not enthused about that - for one thing, it makes
it essentially impossible to send responses from two different
components in response to one request. And that's so
incredibly useful that you really shouldn't shut the door on it.
IMO, MyFaces should just pick a blessed format for sending
responses that is flexible enough to support multiple responses
per request (and sending back at least both XML and HTML
content, and preferably also embedded JSON), and just tell
people to stick with that.
Regards,
Adam
> 3. The existing component(s) ? that still use
> Prototype library should be converted to use Dojo.
Yes, this is just a matter of getting'er done.
> Obviously the existing components will have to be
> altered concurrently with the changes in the Phase
> Listener, so that they continue working. Anyone have a
> suggestion for the best way to go forward?
>
>
I don't think this would be too difficult. For 1, you would have to
see if
it's possible to just move what's inside the instanceof blocks into the
encodeAjax method of the component. For 2, answered above. For 3, I
*think*
the only real dependency on prototype in the form components is the
Ajax.Request() statement in inputAjax.js. Change that to use dojo
and swap
the addResource in AjaxRendererUtils too. The autoupdatedatatable
might be
a bit trickier though, because it uses the prototype Updater and I'm not
sure if dojo has that.
Travis
--
--
Sent from my FrankenBerry Wireless Handheld
Re: AJAX functionality in MyFaces
On 5/1/06, Travis Reeder <[EMAIL PROTECTED]> wrote:
Great comments Sharath and I agree with all of them.
On 4/28/06, sharath reddy <[EMAIL PROTECTED]> wrote:
> Here are some of the inputs we came up with:
> 1. There are too many special cases in the Phase
> Listener code:
>
> if (component instanceof SuggestAjax) //do something
> if (component instanceof HtmlCommandButtonAjax)
> if (ajaxComponent instanceof UIComponentPerspective)
> ...
>
> In our opinion, all this logic should be moved into
> their respective components. The phase listener should
> not be aware of these distinctions.
Definitely.
I totally agree - the big question is what the contract
is between a phase listener or lifecycle and the individual
components. Adding a specific interface that must
be implemented, especially at the component level, is,
IMO, undesirable - the approach Jacob suggests is more
flexible.
> 2. The responsibility for rendering the response
> should lie entirely with the component. The current
> code does something like this:
>
> out.print("\n");
>
> out.print("\n");
>
> ((AjaxComponent) component).encodeAjax(context);
>
> out.print("");
>
> Due to this approach, the component-writer has 2
> disadvantages:
> a. He is forced to render an xml response. Other
> options are ruled out.
> b. If he wants to use an XML API (say, JDOM) to render
> the response, he is contrained, as the root element
> 'response' has already been rendered in the output
> stream.
Good point, this could easily be moved into AjaxRendererUtils.encodeAjax
since most of the form components just call back to that anyways to handle
common cases. I was heading in a different direction with the generic
listener update, where it would send the response wrapper and put the pay
dirt in a cdata section, but it may be easier to just return different types
of responses depending on the component.
I'm not enthused about that - for one thing, it makes
it essentially impossible to send responses from two different
components in response to one request. And that's so
incredibly useful that you really shouldn't shut the door on it.
IMO, MyFaces should just pick a blessed format for sending
responses that is flexible enough to support multiple responses
per request (and sending back at least both XML and HTML
content, and preferably also embedded JSON), and just tell
people to stick with that.
Regards,
Adam
> 3. The existing component(s) ? that still use
> Prototype library should be converted to use Dojo.
Yes, this is just a matter of getting'er done.
> Obviously the existing components will have to be
> altered concurrently with the changes in the Phase
> Listener, so that they continue working. Anyone have a
> suggestion for the best way to go forward?
>
>
I don't think this would be too difficult. For 1, you would have to see if
it's possible to just move what's inside the instanceof blocks into the
encodeAjax method of the component. For 2, answered above. For 3, I *think*
the only real dependency on prototype in the form components is the
Ajax.Request() statement in inputAjax.js. Change that to use dojo and swap
the addResource in AjaxRendererUtils too. The autoupdatedatatable might be
a bit trickier though, because it uses the prototype Updater and I'm not
sure if dojo has that.
Travis
Re: AJAX functionality in MyFaces
On 5/1/06, Travis Reeder <[EMAIL PROTECTED]> wrote: I've already implemented something like this in the sandbox, it's the tag and it's currently usable on the sandbox inputText and am working on making this usable across the board without being intrusive to the other components (because I want to be able to update a datatable when other form elements change). If you look at the current inputAjax.jsp, you will see the usage and a demo, but looks like this: The reason why I didn't do it the ADF way is because it was limited to updates only and it was intrusive for the components that need to support it (every component would need the partialTriggers attribute). FWIW, it isn't the case that everyone needs partialTriggers; it's just a convenience in lieu of calling APIs on AdfFacesContext (which could be called from a listener tag, if you wanted). Using the Listener tag, any number of listeners can be used, they can do different actions like calling some other javascript, and the components don't necessarily need to know that they are listening or are being listened on (in theory anyways). Where does this listener execute? What sort of events is it listening for, and on which tier? (And perhaps it should be named less generically than "listener"?) Thanks, Adam On 4/29/06, Ernst Fastl <[EMAIL PROTECTED]> wrote: > Although it maybe out of scope of the current discussion, in order > to update more than one component with an ajax-request it would also > be possible to use something like the partialTriggers-Attribute in ADF-Faces > in future approaches. The value of this attribute is the ID or IDs of > other components. When those components are updated trough ajax calls > the component which has their IDs set in the partialTriggers-Attribute > will also be updated. All rendered components in ADF Faces support the > partialTriggers attribute. > > further info is available on: > > http://www.oracle.com/webapps/online-help/jdeveloper/10.1.3/state/content/navId.4/navSetId._/vtTopicFile.jsf_apps|adfcreate|af_appr~html/ > > It maybe to early for that now, but what do you think of this idea in principle. > > regards > > Ernst > > On 4/29/06, Gerald Müllan <[EMAIL PROTECTED]> wrote: > > As far as i know we wanted to update only one component per request > > with our actual approach. > > > > I think we should separate the need of updating the model (like > > anywhere) and having an ajax response to show something special > > (visualisation etc.) on the client. > > > > cheers, > > > > Gerald > > > > On 4/29/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > > > Hi! > > > > If we rely on our "affectedAjaxComponent" approach (seeking comp and > > > > calling methods on it) we are little bit restricted in coding. > > > If this mean that we can update only one component per request, then I > > > would like to see to at least extends this approach. > > > > > > Beside the fact that a component would like to update its own > > > data/layout/etc I would like to be able to update other components too. > > > > > > Say if you have a button "calculate" this should update the model and > > > then update the output of n other components. > > > Something like zones in ajaxanywhere (partial page rendering). > > > > > > Or is this wish out of scope of the current discussion? > > > > > > Ciao, > > > Mario > > > > > > > > > > > > -- > > Gerald Müllan > > Schelleingasse 2/11 > > 1040 Vienna, Austria > > 0043 699 11772506 > > [EMAIL PROTECTED] > > >
Re: AJAX functionality in MyFaces
Great comments Sharath and I agree with all of them. On 4/28/06, sharath reddy <[EMAIL PROTECTED]> wrote:
Here are some of the inputs we came up with:1. There are too many special cases in the Phase
Listener code:if (component instanceof SuggestAjax) //do somethingif (component instanceof HtmlCommandButtonAjax) if (ajaxComponent instanceof UIComponentPerspective)...In our opinion, all this logic should be moved into
their respective components. The phase listener shouldnot be aware of these distinctions.Definitely.
2. The responsibility for rendering the responseshould lie entirely with the component. The currentcode does something like this: out.print("\n");
out.print("\n"); ((AjaxComponent) component).encodeAjax(context); out.print("");Due to this approach, the component-writer has 2
disadvantages:a. He is forced to render an xml response. Otheroptions are ruled out.b. If he wants to use an XML API (say, JDOM) to renderthe response, he is contrained, as the root element'response' has already been rendered in the output
stream.Good point, this could easily be moved into AjaxRendererUtils.encodeAjax since most of the form components just call back to that anyways to handle common cases. I was heading in a different direction with the generic listener update, where it would send the response wrapper and put the pay dirt in a cdata section, but it may be easier to just return different types of responses depending on the component.
3. The existing component(s) ? that still usePrototype library should be converted to use Dojo.
Yes, this is just a matter of getting'er done. Obviously the existing components will have to be
altered concurrently with the changes in the PhaseListener, so that they continue working. Anyone have asuggestion for the best way to go forward?I don't think this would be too difficult. For 1, you would have to see if it's possible to just move what's inside the instanceof blocks into the encodeAjax method of the component. For 2, answered above. For 3, I *think* the only real dependency on prototype in the form components is the
Ajax.Request() statement in inputAjax.js. Change that to use dojo and swap the addResource in AjaxRendererUtils too. The autoupdatedatatable might be a bit trickier though, because it uses the prototype Updater and I'm not sure if dojo has that.
Travis
Re: AJAX functionality in MyFaces
I've already implemented something like this in the sandbox, it's the tag and it's currently usable on the sandbox inputText and am working on making this usable across the board without being intrusive to the other components (because I want to be able to update a datatable when other form elements change). If you look at the current inputAjax.jsp, you will see the usage and a demo, but looks like this: The reason why I didn't do it the ADF way is because it was limited to updates only and it was intrusive for the components that need to support it (every component would need the partialTriggers attribute). Using the Listener tag, any number of listeners can be used, they can do different actions like calling some other _javascript_, and the components don't necessarily need to know that they are listening or are being listened on (in theory anyways). Regards,TravisOn 4/29/06, Ernst Fastl <[EMAIL PROTECTED]> wrote: Although it maybe out of scope of the current discussion, in orderto update more than one component with an ajax-request it would alsobe possible to use something like the partialTriggers-Attribute in ADF-Faces in future approaches. The value of this attribute is the ID or IDs ofother components. When those components are updated trough ajax callsthe component which has their IDs set in the partialTriggers-Attribute will also be updated. All rendered components in ADF Faces support thepartialTriggers attribute.further info is available on: http://www.oracle.com/webapps/online-help/jdeveloper/10.1.3/state/content/navId.4/navSetId._/vtTopicFile.jsf_apps|adfcreate|af_appr~html/It maybe to early for that now, but what do you think of this idea in principle. regardsErnstOn 4/29/06, Gerald Müllan <[EMAIL PROTECTED]> wrote:> As far as i know we wanted to update only one component per request> with our actual approach. >> I think we should separate the need of updating the model (like> anywhere) and having an ajax response to show something special> (visualisation etc.) on the client.>> cheers, >> Gerald>> On 4/29/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:> > Hi!> > > If we rely on our "affectedAjaxComponent" approach (seeking comp and > > > calling methods on it) we are little bit restricted in coding.> > If this mean that we can update only one component per request, then I> > would like to see to at least extends this approach. > >> > Beside the fact that a component would like to update its own> > data/layout/etc I would like to be able to update other components too.> >> > Say if you have a button "calculate" this should update the model and > > then update the output of n other components.> > Something like zones in ajaxanywhere (partial page rendering).> >> > Or is this wish out of scope of the current discussion? > >> > Ciao,> > Mario> >> --> Gerald Müllan> Schelleingasse 2/11> 1040 Vienna, Austria> 0043 699 11772506> [EMAIL PROTECTED]>
[jira] Created: (TOMAHAWK-406) does not allow valueChangeListener
does not allow valueChangeListener --- Key: TOMAHAWK-406 URL: http://issues.apache.org/jira/browse/TOMAHAWK-406 Project: MyFaces Tomahawk Type: Bug Versions: 1.1.3-SNAPSHOT Environment: JBoss, Windows XP Reporter: Dave Fix For: 1.1.3-SNAPSHOT does not allow valueChangeListener. So there is no way to detect the status change of : from close to open, or from open to close. -- 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
sometimes displays an exception instead of the expected page (core 1.1.3 from myfaces-repo)
(Core 1.1.3 from myfaces-repo) The sometimes displays the following exception instead of the expected page exception javax.servlet.ServletException: null values not allowed javax.faces.webapp.FacesServlet.service(FacesServlet.java:152) org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144) root cause javax.faces.FacesException: null values not allowed org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:435) org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234) org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384) javax.faces.webapp.FacesServlet.service(FacesServlet.java:138) org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144) This looks similar to issue MYFACES-595 http://issues.apache.org/jira/browse/MYFACES-595 Any ideas what may be causing this? Paul Spencer
Re: [important] 1.5 in core
Dennis, Based on Sean's earlier post, you are correct Some how this got posted twice, probably my fault. Thank you Paul Spencer Dennis Byrne wrote: I am pretty sure you are looking for myfaces-impl-1.1.3.jar under http://myfaces.zones.apache.org/dist/maven-repository/org/apache/myfaces/core/myfaces-impl/1.1.3/ The api jar is at an equivalent location. Sean, this is right? Thanks for your interest Paul. Dennis Byrne -Original Message- From: Paul Spencer [mailto:[EMAIL PROTECTED] Sent: Monday, May 1, 2006 02:06 PM To: 'MyFaces Development' Subject: Re: [important] 1.5 in core What is the address of the "myfaces repo"? I do not see a version, or snapshot, dated today in http://cvs.apache.org/maven-snapshot-repository/org/apache/myfaces/core/. Paul Spencer Sean Schofield wrote: FYI I put a new RC up on the myfaces repo. TCK testing should begin shortly. Lets get this released by the end of the week! Sean On 5/1/06, Sean Schofield <[EMAIL PROTECTED]> wrote: Yes we should install JDK 1.4 on the zone which is used for nightly builds and release candidates. I think that is the best long term solution. Sean On 5/1/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: Hi! This is holding up the release because of a method not found error. I am running low on time right now so I would appreciate it if others can look into this also. Which package? Shared or core? I agree, this should be fixed ASAP. I will try to find time tomorrow but its better if someone else fix first so I can use my time to rebuild the release candidate. I guess I fixed it, though, not testet but it should do its job. It looks like I become the "last bug before release" fixer ;-) However, the best will be to use a 1.4 JDK to build the release - or at least use the JDK 1.4 libraries (this will be possible by adding them to the bootclasspath I think - I've never done it myself, there are documentations how to do in internet), that way such incompatibilites will come up early. Ciao, Mario
Re: [important] 1.5 in core
I am pretty sure you are looking for myfaces-impl-1.1.3.jar under http://myfaces.zones.apache.org/dist/maven-repository/org/apache/myfaces/core/myfaces-impl/1.1.3/ The api jar is at an equivalent location. Sean, this is right? Thanks for your interest Paul. Dennis Byrne >-Original Message- >From: Paul Spencer [mailto:[EMAIL PROTECTED] >Sent: Monday, May 1, 2006 02:06 PM >To: 'MyFaces Development' >Subject: Re: [important] 1.5 in core > >What is the address of the "myfaces repo"? > >I do not see a version, or snapshot, dated today in >http://cvs.apache.org/maven-snapshot-repository/org/apache/myfaces/core/. > > >Paul Spencer > > > >Sean Schofield wrote: >> FYI I put a new RC up on the myfaces repo. TCK testing should begin >> shortly. Lets get this released by the end of the week! >> >> Sean >> >> On 5/1/06, Sean Schofield <[EMAIL PROTECTED]> wrote: >> >>> Yes we should install JDK 1.4 on the zone which is used for nightly >>> builds and release candidates. I think that is the best long term >>> solution. >>> >>> Sean >>> >>> On 5/1/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: >>> > Hi! >>> > >> This is holding up the release because of a method not found error. >>> > >> I am running low on time right now so I would appreciate it if >>> others >>> > >> can look into this also. >>> > > >>> > > Which package? Shared or core? I agree, this should be fixed >>> ASAP. I >>> > > will try to find time tomorrow but its better if someone else fix >>> > > first so I can use my time to rebuild the release candidate. >>> > I guess I fixed it, though, not testet but it should do its job. >>> > >>> > It looks like I become the "last bug before release" fixer ;-) >>> > >>> > However, the best will be to use a 1.4 JDK to build the release - or at >>> > least use the JDK 1.4 libraries (this will be possible by adding >>> them to >>> > the bootclasspath I think - I've never done it myself, there are >>> > documentations how to do in internet), that way such incompatibilites >>> > will come up early. >>> > >>> > Ciao, >>> > Mario >>> > >>> > >>> >> > >
Re: [important] 1.5 in core
What is the address of the "myfaces repo"? I do not see a version, or snapshot, dated today in http://cvs.apache.org/maven-snapshot-repository/org/apache/myfaces/core/. Paul Spencer Sean Schofield wrote: FYI I put a new RC up on the myfaces repo. TCK testing should begin shortly. Lets get this released by the end of the week! Sean On 5/1/06, Sean Schofield <[EMAIL PROTECTED]> wrote: Yes we should install JDK 1.4 on the zone which is used for nightly builds and release candidates. I think that is the best long term solution. Sean On 5/1/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > >> This is holding up the release because of a method not found error. > >> I am running low on time right now so I would appreciate it if others > >> can look into this also. > > > > Which package? Shared or core? I agree, this should be fixed ASAP. I > > will try to find time tomorrow but its better if someone else fix > > first so I can use my time to rebuild the release candidate. > I guess I fixed it, though, not testet but it should do its job. > > It looks like I become the "last bug before release" fixer ;-) > > However, the best will be to use a 1.4 JDK to build the release - or at > least use the JDK 1.4 libraries (this will be possible by adding them to > the bootclasspath I think - I've never done it myself, there are > documentations how to do in internet), that way such incompatibilites > will come up early. > > Ciao, > Mario > >
Re: [important] 1.5 in core
What is the address of the "myfaces repo"? http://myfaces.zones.apache.org/dist/maven-repository/
Re: [important] 1.5 in core
What is the address of the "myfaces repo"? What is the version number in the repo"? I do not see a version, or snapshot, dated today in http://cvs.apache.org/maven-snapshot-repository/org/apache/myfaces/core/. Paul Spencer Sean Schofield wrote: FYI I put a new RC up on the myfaces repo. TCK testing should begin shortly. Lets get this released by the end of the week! Sean On 5/1/06, Sean Schofield <[EMAIL PROTECTED]> wrote: Yes we should install JDK 1.4 on the zone which is used for nightly builds and release candidates. I think that is the best long term solution. Sean On 5/1/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > >> This is holding up the release because of a method not found error. > >> I am running low on time right now so I would appreciate it if others > >> can look into this also. > > > > Which package? Shared or core? I agree, this should be fixed ASAP. I > > will try to find time tomorrow but its better if someone else fix > > first so I can use my time to rebuild the release candidate. > I guess I fixed it, though, not testet but it should do its job. > > It looks like I become the "last bug before release" fixer ;-) > > However, the best will be to use a 1.4 JDK to build the release - or at > least use the JDK 1.4 libraries (this will be possible by adding them to > the bootclasspath I think - I've never done it myself, there are > documentations how to do in internet), that way such incompatibilites > will come up early. > > Ciao, > Mario > >
Re: [important] 1.5 in core
FYI I put a new RC up on the myfaces repo. TCK testing should begin shortly. Lets get this released by the end of the week! Sean On 5/1/06, Sean Schofield <[EMAIL PROTECTED]> wrote: Yes we should install JDK 1.4 on the zone which is used for nightly builds and release candidates. I think that is the best long term solution. Sean On 5/1/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > >> This is holding up the release because of a method not found error. > >> I am running low on time right now so I would appreciate it if others > >> can look into this also. > > > > Which package? Shared or core? I agree, this should be fixed ASAP. I > > will try to find time tomorrow but its better if someone else fix > > first so I can use my time to rebuild the release candidate. > I guess I fixed it, though, not testet but it should do its job. > > It looks like I become the "last bug before release" fixer ;-) > > However, the best will be to use a 1.4 JDK to build the release - or at > least use the JDK 1.4 libraries (this will be possible by adding them to > the bootclasspath I think - I've never done it myself, there are > documentations how to do in internet), that way such incompatibilites > will come up early. > > Ciao, > Mario > >
[jira] Commented: (TOMAHAWK-390) Scope sanbox component is not working with seam, and will broke aplication.
[
http://issues.apache.org/jira/browse/TOMAHAWK-390?page=comments#action_12377250
]
Werner Punz commented on TOMAHAWK-390:
--
Since the scope component was only a proof of concept and some of its
mechanisms will go into the new component done by mario, I will pull this one,
I see no use in having it in there anymore.
The scopeshop demo can be remodeled for saveState in fact it would be an
excellent demo on how to use saveState.
And the save and restore mechanisms explored by this component already are
recycled by Mario conceptwise, for its own approach.
There is no need to keep that component anymore and its associated phase
listener.
> Scope sanbox component is not working with seam, and will broke aplication.
> ---
>
> Key: TOMAHAWK-390
> URL: http://issues.apache.org/jira/browse/TOMAHAWK-390
> Project: MyFaces Tomahawk
> Type: Bug
> Versions: 1.1.3-SNAPSHOT
> Environment: myfaces last svn version, all seam version.
> Reporter: Grigoras Cristinel
> Assignee: Werner Punz
>
> 11:29:37,141 INFO [org.apache.myfaces.custom.scope.ScopeUtils]
> ScopeContainer not found - has not been initialized.
> javax.faces.el.EvaluationException: Cannot get value for expression
> '#{ScopeContainer}'
> at
> org.apache.myfaces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:402)
> at
> org.apache.myfaces.custom.scope.ScopeUtils.getManagedBean(ScopeUtils.java:78)
> at
> org.apache.myfaces.custom.scope.AfterScopePhaseListener.afterPhase(AfterScopePhaseListener.java:44)
> at
> org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:89)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:391)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:107)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at
> org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at
> org.jboss.seam.servlet.SeamServletFilter.doFilter(SeamServletFilter.java:48)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> at
> org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
> at
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:174)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
> at
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> at
> org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:394)
> at
> org.apache.catalina.valves.FastCommonAccessLogValve.invoke(FastCommonAccessLogValve.java:495)
> at
> org.apache.catalina.valves.RequestDumperValve.invoke(RequestDumperValve.java:150)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868)
> at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663)
> at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> at
> org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.IllegalStateException: No active application scope
> at org.jboss.seam.core.Init.instance(Init.java:89)
> at org.jboss.seam
[jira] Created: (TOMAHAWK-405) Running under ServletExec 5 two TLD attribute elements have the same name
Running under ServletExec 5 two TLD attribute elements have the same name - Key: TOMAHAWK-405 URL: http://issues.apache.org/jira/browse/TOMAHAWK-405 Project: MyFaces Tomahawk Type: Bug Versions: 1.1.1 Environment: Windows Server 2003, ServletExec 5 Reporter: Christopher J. Bowerman Have tried with Tomahawk 1.1.1 as well as 1.1.3-SNAPSHOT. Both run fine under Tomcat 5.5, but while trying under ServletExec 5 I get the following error: [Mon May 01 11:08:45 EDT 2006] JspServlet: two TLD attribute elements have the same name - renderAll [Mon May 01 11:08:45 EDT 2006] JspServlet: the problem occurred around line number 3 in file E:\Program Files\New Atlanta\ServletExec AS\se-pilotdemo\ServletExecData\default\JSFPILOT\WAR\ModelTreeSubview.jspf: [Mon May 01 11:08:45 EDT 2006] JspServlet: [<[EMAIL PROTECTED] uri="http://myfaces.apache.org/tomahawk"; prefix="t"%>] [Mon May 01 11:08:45 EDT 2006] JspServlet: the problem occurred around line number 9 in file E:\Program Files\New Atlanta\ServletExec AS\se-pilotdemo\ServletExecData\default\JSFPILOT\WAR\ModelViewInfo1.jsp: [Mon May 01 11:08:45 EDT 2006] JspServlet: [ ] [Mon May 01 11:08:45 EDT 2006] JspServlet: the problem occurred around line number 2 in file E:\Program Files\New Atlanta\ServletExec AS\se-pilotdemo\ServletExecData\default\JSFPILOT\WAR\ModelViewInfo1.jsp: [Mon May 01 11:08:45 EDT 2006] JspServlet: [] [Mon May 01 11:08:45 EDT 2006] JspServlet: the problem occurred around line number 12 in file E:\Program Files\New Atlanta\ServletExec AS\se-pilotdemo\ServletExecData\default\JSFPILOT\WAR\ModelViewInfo1.jsp: [Mon May 01 11:08:45 EDT 2006] JspServlet: [] I opened the jar(s) and looked at the TLD file. The renderAll attributes appear to be concerned with the panelNavigation2 component. However, I am not trying to use this component (I'm only using Tree2). It appears this kind of problem was encountered in MyFaces (core?) earlier? Thanks. Chris. -- 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: [important] 1.5 in core
Yes we should install JDK 1.4 on the zone which is used for nightly builds and release candidates. I think that is the best long term solution. Sean On 5/1/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: Hi! >> This is holding up the release because of a method not found error. >> I am running low on time right now so I would appreciate it if others >> can look into this also. > > Which package? Shared or core? I agree, this should be fixed ASAP. I > will try to find time tomorrow but its better if someone else fix > first so I can use my time to rebuild the release candidate. I guess I fixed it, though, not testet but it should do its job. It looks like I become the "last bug before release" fixer ;-) However, the best will be to use a 1.4 JDK to build the release - or at least use the JDK 1.4 libraries (this will be possible by adding them to the bootclasspath I think - I've never done it myself, there are documentations how to do in internet), that way such incompatibilites will come up early. Ciao, Mario
Re: [important] 1.5 in core
Hi! >> This is holding up the release because of a method not found error. >> I am running low on time right now so I would appreciate it if others >> can look into this also. > > Which package? Shared or core? I agree, this should be fixed ASAP. I > will try to find time tomorrow but its better if someone else fix > first so I can use my time to rebuild the release candidate. I guess I fixed it, though, not testet but it should do its job. It looks like I become the "last bug before release" fixer ;-) However, the best will be to use a 1.4 JDK to build the release - or at least use the JDK 1.4 libraries (this will be possible by adding them to the bootclasspath I think - I've never done it myself, there are documentations how to do in internet), that way such incompatibilites will come up early. Ciao, Mario
Re: [VOTE] Tobago Release 1.0.7
I checked my two test applications and found no problems up to now. +1 Regards, Arvid
