I actually saw this today as well. Looks like it is (was) a bug in
the ResponseBuilder logic associated with a recent flush() call change
I made..
It's been fixed but only in a branch that no one can access yet. The
real fix should come out within a week. (assuming that this is your
problem, it
There should be nothing overly different between an ajax / non ajax
request. They all go through the same resource paths as everyone else.
I guess we'd have to know more about this filter and how it is/isn't
getting associated with all requests for some reason?
On 1/12/07, Stephane Decleire <[EM
Probably doesn't help you very much right now as it's still very
"alpha", but the demos hosted here:
http://tapestry.apache.org/tapestry4.1/demos.html
are all running the next version of ognl, which includes the same kind
of javassist enhancements Howard does with tapestry-prop/T5. In
addition t
One difference with ognl is that ognl allows the first letter of a binding
to be capitalized:
ognl:article.Type_Garantie would map to
*public* java.lang.String getType_Garantie () {
*return* *this*.Type_Garantie;
}
whereas with prop it fails. With prop only prop:article.type_Garantie is
valid.
Dear Tapestry Users,
The first version of the "Tapestry Namespace Utilities" is available at
http://www.erinors.com/developer/project/tapestry-nsutils/.
Its main feature is the implementation of "global namespace" for Tapestry.
Comments and ideas are welcome!
With best regards:
Norbert Sándor
A Tapestry-Spring-Hibernate stack is good - although it may take some
time to get it right (depending on the complexity of your app).
We use this stack in our project and one of the prime factors for
including Spring here is its convenient transaction-management
support. It gets much better
Here it will surely be worse, everyone seems to have some scamming
scheme. As I am concerned I don't want to have anything to do with such
projects, infinite paperwork, bribes, it's just a swamp, bleah.
Len
On Sat, 2007-01-13 at 04:19 +0200, andyhot wrote:
> Marilen Corciovei wrote:
> > Maybe w
Ok, I found SpecificationParser.java and saw how it's done.
Now I just need to figure out how to register an EntityResolver globally
so that I can override the location of my non-Tapestry DTDs...
On Sat, 13 Jan 2007 10:37:37 +0100, Martin Strand
<[EMAIL PROTECTED]> wrote:
Oh, ok... great!
Oh, ok... great! :)
But how does Tapestry make sure they're loaded from the jar? I'm pretty
sure I'll get the same problem with a couple of other (non-Tapestry) DTDs.
Martin
On Sat, 13 Jan 2007 03:05:29 +0100, andyhot <[EMAIL PROTECTED]> wrote:
Tapestry's DTD are already in the tapestry jar
Did find this in the end of the stack trace
Caused by: java.util.MissingResourceException: Can't find bundle for base
name com.javaforge.tapestry.prop.PropStrings, locale en_CA
at java.util.ResourceBundle.throwMissingResourceException(
ResourceBundle.java:1508)
at java.util.ResourceBundle.getBund
10 matches
Mail list logo
