Hello,
Changes starting rev 572370 gives me this stack trace
java.lang.UnsupportedOperationException
javax.faces.application.Application.getELResolver(Application.java:443)
com.sun.faces.context.FacesContextImpl.getELContext(FacesContextImpl.java:174)
Hi Dan!
Changes starting rev 572370 gives me this stack trace
java.lang.UnsupportedOperationException
I still develop with JSF 1.1 and I think a JSF 1.2 change triggers this
exception - odd.
Please try the latest version which should solve this problem for now by
using a proxy instead of
Hi!
Is the JSF 1.2 API backward compatible?
An application developed with the JSF 1.2 API should run on 1.1 as long
as no 1.2 specific stuff will be used, no?
I ask as I had a UOE in orchestra which seems happened after I override
the ApplicationFactory (and the Application) but still use JSF
h/t:selectOneMenu not working in nested t:dataLists or t:dataTables
---
Key: TOMAHAWK-1106
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1106
Project: MyFaces Tomahawk
[
https://issues.apache.org/jira/browse/TOMAHAWK-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525041
]
Jens Scheidtmann commented on TOMAHAWK-1106:
I tried to rebuild this using two nested dataList s and
[
https://issues.apache.org/jira/browse/TOMAHAWK-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525055
]
Jens Scheidtmann commented on TOMAHAWK-1106:
Sorry: Forgot to mention that the bean has session
[
https://issues.apache.org/jira/browse/TOMAHAWK-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525052
]
scheidtm edited comment on TOMAHAWK-1106 at 9/5/07 3:26 AM:
For the record, I
NumberConverter doesn't work with selectMany
Key: TRINIDAD-690
URL: https://issues.apache.org/jira/browse/TRINIDAD-690
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.1-core,
[
https://issues.apache.org/jira/browse/TOMAHAWK-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Gould updated TOMAHAWK-1104:
-
Status: Patch Available (was: Open)
t:inputCalendar does not completely recover from
[
https://issues.apache.org/jira/browse/TOMAHAWK-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Gould updated TOMAHAWK-1104:
-
Status: Open (was: Patch Available)
t:inputCalendar does not completely recover from
Hello Mario,
It's the opposite, as for any backward compatible system. It means that you
can, theoretically, run a JSF 1.1 application on a 1.2 system. However, if
you did not use any 1.2 specific API, meaning you developed no new
component, because otherwise you would be using unified EL, thus
Hi!
It's the opposite, as for any backward compatible system. It means
that you can, theoretically, run a JSF 1.1 application on a 1.2 system.
I haven't looked at it in very detail, but it seems if you provide your
own javax.faces.application.Application compiled with JSF1.1 the method
Hi Mario, thanks for the quick fix.
However, the proxy solution does not work either, unforturnately my app
crashes at startup
with no provided stacktrace. :(
-D
Mario Ivankovits wrote:
Hi Dan!
Changes starting rev 572370 gives me this stack trace
Hi!
However, the proxy solution does not work either, unforturnately my app
crashes at startup
with no provided stacktrace. :(
Please try again ... hope it works, else I'll have a look at it tomorrow
setting up a JSF 1.2 environment.
Thanks!
Ciao,
Mario
Hello Mario,
On 9/5/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
It's the opposite, as for any backward compatible system. It means
that you can, theoretically, run a JSF 1.1 application on a 1.2 system.
I haven't looked at it in very detail, but it seems if you provide your
own
here is the stack trace at start up with your latest fix
INFO: Initializing Sun's JavaServer Faces implementation (1.2_04-b07-FCS)
for context '/iplocks'
log4j:WARN No appenders could be found for logger
(org.springframework.util.ClassUtils).
log4j:WARN Please initialize the log4j system
It's probably too late to do anything about it, but JSR301 seems like
a poor name for a few reasons. First, it's not obvious to which
apache project the JSR301 issue key belongs, nor is it clear to the
uniformed what JSR301 stands for. It'd be the same as naming MyFaces
JSR127. Second,
I agree on this. I think we were talking about the subproject being
named jsf-portlet-bridge or portlet bridge. Should the Jira issues list
be the same? Also, presumably this project will cover future JSR's on
this same API.
Mike Kienenberger wrote:
It's probably too late to do anything
[
https://issues.apache.org/jira/browse/TRINIDAD-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525126
]
Ryan Slack commented on TRINIDAD-348:
-
Ok, perhaps it was misleading for me to say I have THIS problem, as I
You are right, but:
- many Jira-Keys of Apache sub projects do not correspond to their
umbrella project: TOMAHAWK, TRINIDAD, ...
- of course their could be another Apache project implementing JSR301,
but the same problem applies to the long name: if we name the sub
project Apache JSF Portlet
Mike,
[offtopic]
are you cayenne guys passing the TCK already ?
[/offtopic]
On 9/5/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
It's probably too late to do anything about it, but JSR301 seems like
a poor name for a few reasons. First, it's not obvious to which
apache project the JSR301
Hi Adam,
On 9/4/07, Adam Winer [EMAIL PROTECTED] wrote:
Indeed, this is an issue (Ajax4JSF incompatibilities with
Trinidad) that is present in 1.0.2, 1.0.2, and 1.2.1. It shouldn't
block 1.2.2.
can I count this as a +1 ?
-Matthias
I would really like to get a testcase for the class cast
[
https://issues.apache.org/jira/browse/TOMAHAWK-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525146
]
Todd Gould commented on TOMAHAWK-1104:
--
Some debugging has shown that the restoreState() method in the
[
https://issues.apache.org/jira/browse/TOMAHAWK-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Gould updated TOMAHAWK-1104:
-
Status: Patch Available (was: Open)
t:inputCalendar does not completely recover from
I'm not sure. I haven't been following the JPA implementation for
Cayenne closely.
On 9/5/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Mike,
[offtopic]
are you cayenne guys passing the TCK already ?
[/offtopic]
On 9/5/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
It's probably too
Hitting enter key does not submit the form
--
Key: TRINIDAD-691
URL: https://issues.apache.org/jira/browse/TRINIDAD-691
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Did you try tr:form defaultCommand=theIdOfTheButtonToClickWhenEnterIsHit
Please don't raise issues in JIRA until you've verified via
[EMAIL PROTECTED] that there is indeed a bug.
On 9/5/07, saurabh (JIRA) dev@myfaces.apache.org wrote:
Hitting enter key does not submit the form
Wrong output order when redisplaying a submitted form
-
Key: MYFACES-1718
URL: https://issues.apache.org/jira/browse/MYFACES-1718
Project: MyFaces Core
Issue Type: Bug
[
https://issues.apache.org/jira/browse/MYFACES-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fischer updated MYFACES-1718:
Status: Patch Available (was: Open)
Wrong output order when redisplaying a submitted
OK, so this seems to work for me. No scriptlet required, and less
parameters.
input id=_id22 class=af_inputText_content type=text size=5 onchange
=TrPage._autoSubmit('_id22',event,1);return true; name=_id22/
TrPage._autoSubmit = function(inputId, event, validate)
{
if (_agent.isIE)
{
//
t:inputCalendar component does not handle submission via the enter key in IE6
---
Key: TOMAHAWK-1107
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1107
Project: MyFaces
Out of curiosity, why is TrPage._autoSubmit named with an underscore,
shouldn't it be exposed as an API method? I would think people may
want to call it if they want to submit their own component using an
event other than the default one for the control.
On 9/5/07, Danny Robinson [EMAIL
On 9/4/07, Andrew Robinson [EMAIL PROTECTED] wrote:
663
I'd really like to hear a concrete example of where this is absolutely
necessary. This is a very abstract description that is mostly
I need functionality X because I need to do X, which is a tautology.
It's also very
Adam Winer wrote:
On 9/4/07, *Andrew Robinson* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
663
I'd really like to hear a concrete example of where this is
absolutely
necessary. This is a very abstract description that is mostly
I need functionality X
:-)
Martin, I have an ICLA on file. I think Michael Freedman has submitted
one as well and will hopefully even be on the mailing lists soon,
participating in all the Apache Goodness.
We in the United States were off on Monday for labor-day. Which, for
some reason, means we don't have to
Sorry for the unnecessary comment. Looks like Matthias already handled it.
Scott O'Bryan wrote:
:-)
Martin, I have an ICLA on file. I think Michael Freedman has
submitted one as well and will hopefully even be on the mailing lists
soon, participating in all the Apache Goodness.
We in the
That's not a concrete example. What UI functionality are you
trying to achieve that you cannot achieve today?
Example for using immediate = true for a partial trigger (also shows
usage of the partialRendered component)
seam:decorate id=decorateUsername
tr:inputText id=username required=true
Hi!
This is, indeed, a compatibility issue. However, I assume it's caused
because you did not use the decorator pattern when you applied your
custom Application implementation, so now you're inheriting from the
default implementation method behavior, which is to throw an
Hi
I am trying to use the schedule component, with no luck, I tried redefining
the default classes (headerClass, dayClass), the schedule doesn't change.
Snippet:
=
t:schedule
id=cal
headerClass=mycss
dayClass=mycss2
/
==
Result: (mycss and mycss2 are
MultipartRequestWrapper doesn't handle request parameters correctly in JSF
1.2/JSP 2.1
--
Key: TOMAHAWK-1108
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1108
Mainly because it's not an independently callable method, it requires
validation to be correctly configured behind the scenes. We could consider
something similar as a public api though.
On 9/5/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Out of curiosity, why is TrPage._autoSubmit named with
The really important APIs here are _validateInput()
and _submitPartialChange(). The former is an interesting
one to make public; the latter's really mostly just a cover
for an already-public AdfPage API. This function itself
includes details (like the autosub parameter) that are
specific to
[
https://issues.apache.org/jira/browse/TRINIDAD-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525280
]
Adam Winer commented on TRINIDAD-348:
-
I'd recommend taking this to the e-mail list first to see if we really
43 matches
Mail list logo
