On Wed, 23 Jan 2013 13:54:58 -0200, Peter Farkas
wrote:
Thiago H de Paula Figueiredo wrote
I'm sorry, but you're wrong here. It has absolutely nothing to do with
loops. Nothing. The issue, as I've said before, was not passing a
parameter in an later AJAX render. The first render, a full page
Thiago H de Paula Figueiredo wrote
> I'm sorry, but you're wrong here. It has absolutely nothing to do with
> loops. Nothing. The issue, as I've said before, was not passing a
> parameter in an later AJAX render. The first render, a full page one,
> passed the parameter correctly. A second on
On Wed, 23 Jan 2013 06:03:33 -0200, Peter Farkas
wrote:
Thanks a lot, Thiago! Yes, passing the child as a context parameter
fixes it.
;)
I think Tapestry does try to figure out the component parameters for a
partial update, but for loops, it can't.
I'm sorry, but you're wrong here. It
Thanks a lot, Thiago! Yes, passing the child as a context parameter fixes it.
In ExecutableRowPair.java:
I think Tapestry does try to figure out the component parameters for a
partial update, but for loops, it can't.
In the loop, the same instance of 'ExecutableRowPair' is rendered multiple
ti
You said:
When rendering the AJAX response, Tapestry tries to evaluate an
expression on 'child' (*), but 'child' is null.Why does Tapestry need
the value of 'child'? How is it supposed to know?
The stack trace says the problem is elsewhere:
[ERROR] batch.ViewBatch Render queue error in
B
Ok. There are more nested components than necessary, though.
ExecutableRowPair.tml:
ExecutableRowPair.java:
Stack trace (actually the null pointer exception is in ExecutableRowPair):
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Null-pointer-exception-when-updat
Full stack trace and ExecutableRowPair code component please.
On Tue, 22 Jan 2013 16:58:05 -0200, Peter Farkas
wrote:
I'm try to show a list of components with AJAX zones in a table:
An 'ExecutableRowPair' consists of a header row (that's always visible)
and
a details row, that's load
On Wed, 11 Jul 2012 12:34:04 -0300, Norman Franke wrote:
I've got those before as well, and that was the problem. Perhaps
Tapestry could handle that better and just select the first item in this
case?
Pallete is a multiple object selection component, so, in my humble
opinion, this soluti
I've got those before as well, and that was the problem. Perhaps Tapestry could
handle that better and just select the first item in this case?
Norman Franke
Answering Service for Directors, Inc.
www.myasd.com
On Jul 10, 2012, at 8:11 AM, Thiago H de Paula Figueiredo wrote:
> On Tue, 10 Jul 2
Thanks Thiago I'll bear that in mind, next time the problem occurs
On Jul 10, 2012 1:11 PM, "Thiago H de Paula Figueiredo"
wrote:
> On Tue, 10 Jul 2012 08:54:25 -0300, Jabbar wrote:
>
> I think I found the problem, although I'm not 100% sure. I deleted the
>> data which populated the selected p
On Tue, 10 Jul 2012 08:54:25 -0300, Jabbar wrote:
I think I found the problem, although I'm not 100% sure. I deleted the
data which populated the selected property of the palette component and
then
added the data back into the database. The problem has disappeared.
NPEs in Palette happen
I think I found the problem, although I'm not 100% sure. I deleted the data
which populated the selected property of the palette component and then
added the data back into the database. The problem has disappeared.
The strange thing is I couldn't see anything wrong with the original data.
On 10
i am getting this error (NPE in FilterInputStream.close()) when a bot or
crawler tries to access an invalid asset path.
when i have a png like this:
http://www.myhhost.de/assets/59f0e7531f25d4c0/some/subfolder/gfx/logo.png
crawlers often try to crawl the "folders" of this path:
http://www.myhho
I've just taken a look at the 5.2.6 code for ResourceStreamerImpl and it
looks like the input stream is being closed twice via is.close() and
InternalUtils.close(is). This looks like a bug to me
try
{
is = streamble.getStream(compress);
OutputStream os = re
I hastily jumped to the conclusion that it was your code which was calling
close(). It could also be a bug in Tapestry. As I said before, I could be
wrong but this sounds like a strange issue that I have had in the past.
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Null-
Thanks,
But I searched my all project and this is not in my code.
Thanks again,
I"ll keep looking.
Simon
On 5/9/12 2:39 PM, "Lance Java" wrote:
>I think you might be explicitly calling close() on the response
>outputstream somewhere in your code which you shouldn't do. It's the
>servlet c
I think you might be explicitly calling close() on the response
outputstream somewhere in your code which you shouldn't do. It's the
servlet container's responsibility and I think it's failing when tomcat is
trying to close() a stream that has already been closed.
I could be wrong too ;)
17 matches
Mail list logo