The thing is that it was an error in the spec for jsf 1.1, followed by
the ri and myfaces. This has been fixed in the spec for jsf 1.2 (after
we found the mistake in 1.1).
Regards,
Bruno
On 2/22/06, Adam Winer [EMAIL PROTECTED] wrote:
I'm puzzled here - is the TCK *really* asserting that this
[
http://issues.apache.org/jira/browse/TOMAHAWK-155?page=comments#action_12367480
]
Werner Punz commented on TOMAHAWK-155:
--
The Extensionsfilter is just a web frontend trigger for loading resources.
The extensionsfilter is way too problematic for the
BTW, this is MYFACES-778 [1]
Bruno
[1] http://issues.apache.org/jira/browse/MYFACES-778
On 2/23/06, Bruno Aranda [EMAIL PROTECTED] wrote:
The thing is that it was an error in the spec for jsf 1.1, followed by
the ri and myfaces. This has been fixed in the spec for jsf 1.2 (after
we found the
Mike Kienenberger schrieb:
Sorry, I guess my statement could be interpreted multiple ways.
Currently you have to use a dojo tag, an input, and a piece of inline
javascript to make it work. What I meant was that I'd prefer a
component tag so you'd only have to use the component tag (which
Now that we're using maven2 to build MyFaces, perhaps it's time to take
advantage of some of the more interesting plugins, and specifically the
PMD plugin:
http://pmd.sourceforge.net/
The PMD plugin for maven2 offers 2 report types, a CutPaste Detector
and a problem detector, with
Hi!
Sorry for all my urgent mails, but I address them so only if I really
think it IS urgent. ;-)
Yes, that is true.
This turned out to be a serious problem here.
Not only the java.lang.StringIndexOutOfBoundsException problem, but also
that it might deliver the content of another request
I recollected all the issues, ideas, and feedback and tried to
summarize them (from my personal POV):
==
Here is a management summary of what we could/should end with:
* A myfaces-shared project, housing all MyFaces-specific classes
shared between impl and
[ http://issues.apache.org/jira/browse/TOMAHAWK-155?page=all ]
sean schofield closed TOMAHAWK-155:
---
Resolution: Won't Fix
Move ExtensionsFilter to commons so it can be reused outside Tomahawk
+1
regards,
Martin
On 2/23/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Sorry for all my urgent mails, but I address them so only if I really
think it IS urgent. ;-)
Yes, that is true.
This turned out to be a serious problem here.
Not only the
Hello,
is it intended that the acceptCharset attribute of h:form is written
in mixed case in MyFaces 1.1.1 and lower case in the Sun RI 1.1.01?
Thanks in advance,
Arvid
* myfaces-shared will have sub-modules that represent the custom
dependency libs with private namespace for each MyFaces subproject
that needs shared classes (only impl and tomahawk so far). All (=both)
artifacts will automatically be created from the same source that sits
in the Maven
Interesting idea. I think for the next few days we will have our
hands full with the commons refactor but I'm open to trying it out.
Not sure if the license matters since we are not actually distributing
the plugin. Maven is the one downloading it.
Sean
On 2/23/06, Jurgen Lust [EMAIL
[ http://issues.apache.org/jira/browse/TOMAHAWK-83?page=all ]
Darlan Oliveira updated TOMAHAWK-83:
Changes in navigationMenuItem jsf component to make it work with
HtmlCommandJSCookMenu (action) or any simple URL
[ http://issues.apache.org/jira/browse/TOMAHAWK-82?page=all ]
Mathias Stein updated TOMAHAWK-82:
--
t:commandNavigation2 rendering ignores static text of its value attribute,
iff layout=list
On 2/23/06, Sean Schofield [EMAIL PROTECTED] wrote:
* myfaces-shared will have sub-modules that represent the custom
dependency libs with private namespace for each MyFaces subproject
that needs shared classes (only impl and tomahawk so far). All (=both)
artifacts will automatically be
I don't understand this; don't the component APIs matter? Do
you truly believe that MyFaces should feel free to make any change
at any time?
The component API's matter but I don't hold the components to the same
standard as I would a language or framework. I think its unrealistic
for a user
On 2/23/06, Sean Schofield [EMAIL PROTECTED] wrote:
I don't understand this; don't the component APIs matter? Do
you truly believe that MyFaces should feel free to make any change
at any time?
The component API's matter but I don't hold the components to the same
standard as I would a
On 2/23/06, Sean Schofield [EMAIL PROTECTED] wrote:
I don't understand this;don't the component APIs matter?Do you truly believe that MyFaces should feel free to make any change at any time?The component API's matter but I don't hold the components to the same
standard as I would a language or
[ http://issues.apache.org/jira/browse/TOMAHAWK-155?page=all ]
Mike Kienenberger reopened TOMAHAWK-155:
I don't think you should have closed this issue, especially on such short
notice.
Currently the extension filter *IS* the defacto way to do
On 2/22/06, Sean Schofield [EMAIL PROTECTED] wrote:
In response to #1 I would say we do not need to be in the business of
ensuring developers can rely on our public API's. From my perspective
we are in the business of providing a JSF implementation and a series
of components and addons for
To this point. I would really like to see some of the faces rendering
implementation technologies getting together and making child standard APIS.
Let me explain: If you look at the RI, they have a set of utils for
handling the creation of Javascript, hidden fields, etc. MyFaces has it's
own.
Hi Arvid,
There is a bug for this and a rather large set of other differences w/ the RI.
I think HTML and TLD are somewhere in the name of the issue.
Dennis Byrne
-Original Message-
From: Arvid Hülsebus [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 23, 2006 09:06 AM
To: 'MyFaces
[
http://issues.apache.org/jira/browse/TOMAHAWK-2?page=comments#action_12367535 ]
Mike Kienenberger commented on TOMAHAWK-2:
--
The concensus at the time was to remove it.
No one has been sufficiently motivated to do that yet.
Adding
Hi!
This is what I get if I try to build myfaces with tests enabled:
[ stacktrace ] ---
java.lang.IllegalArgumentException: HTML_BASIC
at
org.apache.shale.test.mock.MockRenderKitFactory.addRenderKit(MockRenderKitFactory.java:69)
Try deleting struts/shale/shale-test.jar in your local repo and running the
tests again.
Dennis Byrne
-Original Message-
From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 23, 2006 12:15 PM
To: 'MyFaces Development'
Subject: tomahawk test failed in
HTTP Accept header not properly processed
-
Key: MYFACES-1152
URL: http://issues.apache.org/jira/browse/MYFACES-1152
Project: MyFaces Core
Type: Bug
Components: General
Versions: 1.1.1
Reporter: Chris
[ http://issues.apache.org/jira/browse/MYFACES-1152?page=all ]
Chris Paulson-Ellis updated MYFACES-1152:
-
HTTP Accept header not properly processed
-
Key: MYFACES-1152
URL:
Hi Dennis!
Try deleting struts/shale/shale-test.jar in your local repo and running the
tests again.
I already used mvn -U to update the repository, but it looks like you
have to delete it.
Now it works.
Thanks!
Ciao,
Mario
Hi!
new tomahawk branch
Added:
myfaces/tomahawk/branches/1_1_2/
- copied from r380160, myfaces/tomahawk/trunk/
I am already working on a fix for the treading problem with AddResource.
Even in myfaces-commons this will influence tomahawk too (testCase and
extensionFilter)
Without
That's ok we can work your fix in later. Right now I am refactoring
the commons stuff so we need a branch to do that. We can merge this
branch down and then create a new one again (so we will capture your
fix at that point.)
Just make your fix on the trunk.
Sean
On 2/23/06, Mario Ivankovits
+1 for creating a jira component to JSF component mapping.
Don't really care if we use * or sbx or sandbox or just leave them all the same.
The sandbox/tomahawk division is just an indication of
stability/support. I don't see it as an important distinction in the
context of reporting JIRA
On 2/21/06, Sean Schofield [EMAIL PROTECTED] wrote:
I made another improvement to our JIRA setup. I added a Patch
Available state. There is now an operation called Provide Patch
that users can click once they have attached a patch. It will then
place the issue in the Patch Available state.
The sandbox/tomahawk division is just an indication of
stability/support. I don't see it as an important distinction in the
context of reporting JIRA issues.
Exactly.
[ http://issues.apache.org/jira/browse/TOMAHAWK-146?page=all ]
Jurgen Lust resolved TOMAHAWK-146:
--
Resolution: Fixed
This problem occurred in the old example jsps, it no longer applies for the new
examples
Schedule renders duplicate ids in
34 matches
Mail list logo
