Hi,
using Tomahawk I experimented some problems with the ExtensionFilter, in
particular some errors occur when the MyFaces javascript is written
inside the body of the response.
This is the typical error message:
java.lang.StringIndexOutOfBoundsException
at
Ok a deeper glance, I did not check the inputsuggest code extensively
but having coded for hours dojo now, the error is typical
for sending a null object into dojo, especially into code
which then checks for some css properties and cannot find them.
Sorry for my ajax guess, but that one is closer
Yes, that is true.
Bruno?
regards,
Martin
On 2/19/06, Claudio Tasso [EMAIL PROTECTED] wrote:
Hi,
using Tomahawk I experimented some problems with the ExtensionFilter, in
particular some errors occur when the MyFaces javascript is written
inside the body of the response.
This is the
ok - so that means we'll need to drop static?
won't that cause performance problems?
regards,
Martin
On 2/19/06, Simon Kitching [EMAIL PROTECTED] wrote:
On Sun, 2006-02-19 at 00:46 +, [EMAIL PROTECTED] wrote:
Author: mmarinschek
Date: Sat Feb 18 16:46:18 2006
New Revision: 378805
ExtensionsFilter is not THREAD SAFE
---
Key: MYFACES-1137
URL: http://issues.apache.org/jira/browse/MYFACES-1137
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: Nightly
Environment: JDK 1.5, OC4J
Reporter:
added displayValueOnly Attribute to - input-Calender
-
Key: MYFACES-1138
URL: http://issues.apache.org/jira/browse/MYFACES-1138
Project: MyFaces
Type: Improvement
Reporter: Ernst Fastl
Priority: Trivial
[ http://issues.apache.org/jira/browse/MYFACES-1138?page=all ]
Ernst Fastl updated MYFACES-1138:
-
Attachment: inputCalender_displayValueOnly.patch
added displayValueOnly Attribute to - input-Calender
[
http://issues.apache.org/jira/browse/MYFACES-924?page=comments#action_12366980
]
Bernd Bohmann commented on MYFACES-924:
---
Can we get a version of the Intalio|BPMS 4.0?
When I see the use case it is easier to think about it :-)
REST Support
On 2/19/06, Simon Kitching [EMAIL PROTECTED] wrote:
On Sun, 2006-02-19 at 00:46 +, [EMAIL PROTECTED] wrote:
Author: mmarinschek
Date: Sat Feb 18 16:46:18 2006
New Revision: 378805
URL: http://svn.apache.org/viewcvs?rev=378805view=rev
Log:
minor changes in application-factory,
[
http://issues.apache.org/jira/browse/MYFACES-754?page=comments#action_12366981
]
Bernd Bohmann commented on MYFACES-754:
---
This should be solved with maven migration.
Can you confirm it?
Please look at the nightly build.
Version within jar-names
On Sun, 2006-02-19 at 11:36 +0100, Martin Marinschek wrote:
ok - so that means we'll need to drop static?
Yes. In fact, because MyFaces libs are often placed in a shared
classpath, static should be avoided in almost all cases I expect.
won't that cause performance problems?
Calling
[
http://issues.apache.org/jira/browse/MYFACES-652?page=comments#action_12366984
]
Bernd Bohmann commented on MYFACES-652:
---
The findbugs-maven-plugin is in the mojo sandbox.
We should wait until the plugin is released on a public repository.
On Sun, 2006-02-19 at 20:27 +0100, Manfred Geiler wrote:
On 2/19/06, Simon Kitching [EMAIL PROTECTED] wrote:
Just a warning to all developers: when using commons-logging in a
library, STATIC fields must **NOT** be used to store Log objects.
The problem is that the class may be called with
[ http://issues.apache.org/jira/browse/MYFACES-1127?page=all ]
Dennis Byrne closed MYFACES-1127:
-
Fix Version: Nightly
Resolution: Fixed
Fixed for valueChangeListener as well
Non-null return types allowed for @actionListener
Manfred,
I think you have to send this to [EMAIL PROTECTED]
regards,
Martin
On 2/19/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Dear Incubator PMC,
We, the sponsoring members listed below, ask that you accept the
following proposal for a new project at Apache, an effort centered on
Sure!
chair lead, I shouldn't confuse them of course ;)
regards,
Martin
On 2/19/06, Manfred Geiler [EMAIL PROTECTED] wrote:
On 2/18/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Bernd,
We just have to send a mail to the incubator mailing list officially
declaring your sign-off.
Remove or.apache.myfaces.tobago.el.VariableResolverImpl from faces-config and
rename it to UserVariableResolverImpl
---
Key: MYFACES-1139
URL:
[ http://issues.apache.org/jira/browse/MYFACES-1139?page=all ]
Bernd Bohmann updated MYFACES-1139:
---
Summary: Remove org.apache.myfaces.tobago.el.VariableResolverImpl from
faces-config and rename it to UserVariableResolverImpl (was: Remove
[ http://issues.apache.org/jira/browse/MYFACES-1138?page=all ]
Martin Marinschek closed MYFACES-1138:
--
Resolution: Fixed
thanks to Ernst Fastl for adding this.
added displayValueOnly Attribute to - input-Calender
Hmm ... then this is a good candidate for the most often used anti-pattern. Is
there anything in checkstyle for it?
Dennis Byrne
-Original Message-
From: Martin Marinschek [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 19, 2006 04:57 PM
To: 'MyFaces Development', [EMAIL PROTECTED]
Replace ID for messages by adding replaceIdForMessage attribute
-
Key: MYFACES-1140
URL: http://issues.apache.org/jira/browse/MYFACES-1140
Project: MyFaces
Type: New Feature
Components: Tomahawk
Some fixes to inputSuggestAjax component
Key: MYFACES-1141
URL: http://issues.apache.org/jira/browse/MYFACES-1141
Project: MyFaces
Type: Improvement
Components: Sandbox
Versions: Nightly
Reporter: Gerald
[ http://issues.apache.org/jira/browse/MYFACES-1141?page=all ]
Gerald Müllan updated MYFACES-1141:
---
Attachment: new_features.patch
the corresponding patch to this issue
Some fixes to inputSuggestAjax component
On Sun, 2006-02-19 at 17:56 -0800, Craig McClanahan wrote:
Simon,
Could you do me a favor and publicize this in the Struts community as
well? The framework code there is littered with static log instances
to.
Will do.
You might also want to add some notes related to using Log
On 2/19/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Online report :
http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/34/buildId/511
Build statistics:
State: Failed
...
[INFO] snapshot struts:shale-test:1.0.1-SNAPSHOT: checking
He he ;) Not sure yet.
The new failure is in FactoryFinderTest, but the only change to the code was in
UIComponentTestCase, which is now a child of AbstractJsfTestCase.
Inside the failing test of FactoryFinder, the test calls
FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY) and is
I updated the Shale snapshots about half an hour ago... coincidence?
Wendy
This would have happened w/ or w/out your update.
The fix for this was to put FactoryFinder.releaseFactories() in setup() and in
tearDown() . This setup() call is to clear configured Factory info from
previous tests (
On 2/19/06, Simon Kitching [EMAIL PROTECTED] wrote:
On Sun, 2006-02-19 at 17:56 -0800, Craig McClanahan wrote: Simon, Could you do me a favor and publicize this in the Struts community as well?The framework code there is littered with static log instances
to.Will do.You might also want to add
On 2/19/06, Dennis Byrne [EMAIL PROTECTED] wrote:
I updated the Shale snapshots about half an hour ago... coincidence?WendyThis would have happened w/ or w/out your update.The fix for this was to put FactoryFinder.releaseFactories() in setup() and in tearDown() .This setup() call is to clear
Purely speaking, FactoryFinder.releaseFactories() should
only be necessary in tearDown() - which is where it makes
the most sense, since releasing factories is cleanup, which
is the job of tearDown().
Practically speaking, it's simplest and safest to call it
in both methods - which means that
On 2/19/06, Adam Winer [EMAIL PROTECTED] wrote:
Purely speaking, FactoryFinder.releaseFactories() shouldonly be necessary in tearDown() - which is where it makesthe most sense, since releasing factories is cleanup, whichis the job of tearDown().Practically speaking, it's simplest and safest to
Weee if you implement StateHolder, this isn't an issue.
The public no-arg constructor will be used, variable initializer
expressions will run, etc.
If you implement Serializable instead, then Craig's totally right -
transient variables will not be re-initialized. You can deal with
this
On Sun, 2006-02-19 at 22:33 -0800, Adam Winer wrote:
Weee if you implement StateHolder, this isn't an issue.
The public no-arg constructor will be used, variable initializer
expressions will run, etc.
If you implement Serializable instead, then Craig's totally right -
transient
On 2/19/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Indeed.this really means I'd be willing to switch to JDK logging. What wasthe reason again we couldn't do that?If we are willing to live with a JDK 1.4 or later restriction, no reason at all. That, however, would seem to be an issue for some
Hmm... didn't we settle on JDK 1.4 a while ago?
Simon has some other arguments on not using JDK logging, see above.
regards,
Martin
On 2/20/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 2/19/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Indeed.
this really means I'd be willing to
35 matches
Mail list logo
