Oops my bad. I always try to forget about onPassivate ()
That should fix it, thanks!
On Thu, Jul 3, 2014 at 1:46 PM, Geoff Callender <
geoff.callender.jumpst...@gmail.com> wrote:
> What's "t:ac"? In the POST's Form Data, "t:ac" is the key of the field
> that carries the page's activation context
do you have this in your pom file
org.slf4j
slf4j-log4j12
1.7.2
On Wed, Jul 2, 2014 at 8:36 PM, Thiago H de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Wed, 02 Jul 2014 21:29:03 -0300, Manuel Sugawara <
> manuel.sugaw...@gmail.com> wrote:
>
> Hi,
>>
>
> Hello, Manuel!
What's "t:ac"? In the POST's Form Data, "t:ac" is the key of the field that
carries the page's activation context.
On 3 Jul 2014, at 12:41 pm, Geoff Callender
wrote:
> Not a bug. Form bubbles up its context in the PREPARE_FOR_SUBMIT event.
> Here's a typical way to deal with it:
>
> v
Not a bug. Form bubbles up its context in the PREPARE_FOR_SUBMIT event. Here's
a typical way to deal with it:
void onPrepareForSubmit(Long id) {
this.id = id;
entity = retrieveFromDatabase(id);
}
What should you pass in the context? At a minimum I'
I'm not sure if this is a bug or not.
Here's a scenario:
Page.java
public class Page {
@Property
private Entity entity;
void onActivate ( Long id ) {
entity = retrieveFromDatabase ( id );
}
}
Page.tml:
MyComponent.tml:
...
AJAX is NOT used. If I get it right, form c
On Wed, 02 Jul 2014 21:29:03 -0300, Manuel Sugawara
wrote:
Hi,
Hello, Manuel!
I'm trying to play a little bit with 5.4-beta-6 but our application that
runs on tapestry 5.3.7 isn't starting, the error is:
org.apache.tapestry5.ioc.internal.OperationException: No service
implements the in
Hi,
I'm trying to play a little bit with 5.4-beta-6 but our application that
runs on tapestry 5.3.7 isn't starting, the error is:
org.apache.tapestry5.ioc.internal.OperationException: No service implements
the interface org.slf4j.Logger.
Any clues on what I am missing?
Regards,
Manuel.
You're rigth. If multiple threads are scheduling jobs and the pool has reached
a threadcount of maxsize-1, chances are that a RejectedExecutionException
is thrown. The offer-method should use a lock. Like so:
public boolean offer(Runnable inJob) {
_lock.lock();
try {
if (_exec
I'm not convinced this solution is thread-safe.
On 1 Jul 2014 17:21, "Arjan Verstoep"
wrote:
> Yes, the default implementation is very counter-intuitive. I have
> invesigated once, and it was possible to 'repair' the ThreadPoolExecutor if
> you provide the 'right' work-queue.
>
> I don't know if
