Re: Wicket design incompatible with Web 2.0 ?

[Sebastian]

wicket-push also does update queueing.

Regards,

Seb

On 12.11.2010 20:47, Igor Vaynberg wrote:

not a bad idea. we already have a concept of "channels", but right now
they can only queue or drop requests. with some work it should be
possible to add an "aggregate" mode and process multiple callbacks
within the same request. please file a jira issue.

-igor

On Fri, Nov 12, 2010 at 11:44 AM, John Armstrong  wrote:

EXT-JS does a nice queueing model where you can set a queue timer (say
100ms) and any AJAX requests get bundled up into a single package that
goes across the wire at once, returning and then being sent back to
their callers.

This lets a page update many components at once in what appears to be
real-time without blocking.

Might be an interesting model for wicket at some point in the future.

Yes, I know, EST-JS is a client-side framework. I am only using it as
an example of how some stacks are resolving these sorts of issues.

John-

On Fri, Nov 12, 2010 at 9:36 AM, Josh Kamau  wrote:

AjaxSelfUpdatingTimerBehavior works perfectly for notifications. I guess it
wouldnt work very well for a chat-like scenario. I have set mine to 30
seconds and it works perfectly. Long polling would hold  a request with
nothing to report back in most of the times.

regards.

On Fri, Nov 12, 2010 at 12:17 PM, Igor Vaynbergwrote:


why would you need a request every few milliseconds. what is so urgent
about a notification that you cant poll every ten seconds?

what your long polling thread can do is access the page, render a part
of it, and send it back to the client - but, only when it has
something to say. which instead of many very quick requests to the
page is many very quick accesses to the page.

-igor

On Fri, Nov 12, 2010 at 9:13 AM, José Monzón  wrote:

AjaxSelfUpdatingTimerBehavior is cool for simple repetitive requests.
But if you try to do long polling with that (comet, retain the request
in the server as long as you can while there's nothing to send back)
you will see how your other ajax requests are queued and your page
freezes.

I've seen many people using AjaxSelfUpdatingTimerBehavior to replace
long poling. Performing very quick requests to the server (every few
millisecons). I believe that abusing  AjaxSelfUpdatingTimerBehavior
leads you to scalability issues. Not to mention that the browser gets
choppy in slow computers.


On Fri, Nov 12, 2010 at 4:42 PM, Josh Kamau

wrote:

I have implemented an application that alerts the user on various

events. I

created a notification's bar at the top of my page. This bar has a panel

on

which i added AjaxSelfUpdatingTimerBehavior.  The Panel is available in

all

pages. whatever the page the use is, as long as the panel is rendered,

it

polls the server on regular intervals and displays notifications for

various

events - the facebook style.  This is one of the features that has made

me

stick with wicket.

regards.
Josh


1.


http://wicket.apache.org/apidocs/1.4/org/apache/wicket/ajax/AjaxSelfUpdatingTimerBehavior.html


On Fri, Nov 12, 2010 at 10:37 AM, Frank van Lankvelt<
f.vanlankv...@onehippo.com>  wrote:


On Fri, Nov 12, 2010 at 3:55 PM, José Monzón

wrote:

I recently run into a problem that has make me consider whether
continuing using Wicket or not for a project. I hope guys you can
throw some light into it.

I need to create a web application that uses ajax to keep itself
udpated while still allows the user interact with it also using Ajax.
Imagine something as GMail, Documents, Facebook, Twitter, etc.

On this pages, is very common to have some ajax COMMET, long polling
or also known as inverse AJAX to keep the page updated. But that
doesn't prevent the user to click here and there and update the page
also using AJAX. They are independent XMLHttpRequest with a browser
can handle perfectly.

I was thinking about doing this on Wicket, but apparently it's
impossible by design:
https://issues.apache.org/jira/browse/WICKET-2437

Page objects aren't thread-safe and wicket will block any other

thread

(AJAX call) that tries to access the page while another request (for
instance our long poll) is there.

Have you ever find yourself into this kind of problem? What's the
workaround if any?


the comet-like functionality is useful for things like chatting, but
you wouldn't
need access to the page for that as you're unlikely to change the
component tree.

The alternative to long polling is, of course, regular polling.  Queue
the events
and process them when a request is processed.  Then you can access the
page,
update the component tree and rerender the relevant parts.
Maintaining the queue
is a bit tricky, as one has to make sure that it doesn't grow too
large and it must be
disposed of properly.

We've used this method to implement a single-page-application that

updates

exclusively with ajax.  It's not in the facebook/google/... range, but
it works well
enough for our purposes.

cheers, Frank

download link in abstractTab

[fachhoch]

I have a link in a AbstractTab , on click I start download a file ,
any time I click on this  link whole tab is reloaded , please tell me is
this normal? , is there any way I can control this ?
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/download-link-in-abstractTab-tp3040311p3040311.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket design incompatible with Web 2.0 ?

[Rodolfo Hansen]

There are several long polling implementations around wicket. 

wicketstuff-push for example was designed for continuous communication
between client and server.

There are a couple of details to working with it, and you seem to be
worried on the general ability to do long-polling 
with wicket. 

The short answer I would say is: you're perception is incorrect. 

With wicket you would be able to isolate your long-polling or "web 2.0"
to the appropriate components you create, and just include them in your
pages.



On Fri, 2010-11-12 at 15:55 +0100, José Monzón wrote:

> I recently run into a problem that has make me consider whether
> continuing using Wicket or not for a project. I hope guys you can
> throw some light into it.
> 
> I need to create a web application that uses ajax to keep itself
> udpated while still allows the user interact with it also using Ajax.
> Imagine something as GMail, Documents, Facebook, Twitter, etc.
> 
> On this pages, is very common to have some ajax COMMET, long polling
> or also known as inverse AJAX to keep the page updated. But that
> doesn't prevent the user to click here and there and update the page
> also using AJAX. They are independent XMLHttpRequest with a browser
> can handle perfectly.
> 
> I was thinking about doing this on Wicket, but apparently it's
> impossible by design:
> https://issues.apache.org/jira/browse/WICKET-2437
> 
> Page objects aren't thread-safe and wicket will block any other thread
> (AJAX call) that tries to access the page while another request (for
> instance our long poll) is there.
> 
> Have you ever find yourself into this kind of problem? What's the
> workaround if any?
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 

Re: Wicket design incompatible with Web 2.0 ?

[John Armstrong]

Filed

https://issues.apache.org/jira/browse/WICKET-3165

Thanks Igor
John-

On Fri, Nov 12, 2010 at 11:47 AM, Igor Vaynberg  wrote:
> not a bad idea. we already have a concept of "channels", but right now
> they can only queue or drop requests. with some work it should be
> possible to add an "aggregate" mode and process multiple callbacks
> within the same request. please file a jira issue.
>
> -igor
>
> On Fri, Nov 12, 2010 at 11:44 AM, John Armstrong  
> wrote:
>> EXT-JS does a nice queueing model where you can set a queue timer (say
>> 100ms) and any AJAX requests get bundled up into a single package that
>> goes across the wire at once, returning and then being sent back to
>> their callers.
>>
>> This lets a page update many components at once in what appears to be
>> real-time without blocking.
>>
>> Might be an interesting model for wicket at some point in the future.
>>
>> Yes, I know, EST-JS is a client-side framework. I am only using it as
>> an example of how some stacks are resolving these sorts of issues.
>>
>> John-
>>
>> On Fri, Nov 12, 2010 at 9:36 AM, Josh Kamau  wrote:
>>> AjaxSelfUpdatingTimerBehavior works perfectly for notifications. I guess it
>>> wouldnt work very well for a chat-like scenario. I have set mine to 30
>>> seconds and it works perfectly. Long polling would hold  a request with
>>> nothing to report back in most of the times.
>>>
>>> regards.
>>>
>>> On Fri, Nov 12, 2010 at 12:17 PM, Igor Vaynberg 
>>> wrote:
>>>
 why would you need a request every few milliseconds. what is so urgent
 about a notification that you cant poll every ten seconds?

 what your long polling thread can do is access the page, render a part
 of it, and send it back to the client - but, only when it has
 something to say. which instead of many very quick requests to the
 page is many very quick accesses to the page.

 -igor

 On Fri, Nov 12, 2010 at 9:13 AM, José Monzón  wrote:
 > AjaxSelfUpdatingTimerBehavior is cool for simple repetitive requests.
 > But if you try to do long polling with that (comet, retain the request
 > in the server as long as you can while there's nothing to send back)
 > you will see how your other ajax requests are queued and your page
 > freezes.
 >
 > I've seen many people using AjaxSelfUpdatingTimerBehavior to replace
 > long poling. Performing very quick requests to the server (every few
 > millisecons). I believe that abusing  AjaxSelfUpdatingTimerBehavior
 > leads you to scalability issues. Not to mention that the browser gets
 > choppy in slow computers.
 >
 >
 > On Fri, Nov 12, 2010 at 4:42 PM, Josh Kamau 
 wrote:
 >> I have implemented an application that alerts the user on various
 events. I
 >> created a notification's bar at the top of my page. This bar has a panel
 on
 >> which i added AjaxSelfUpdatingTimerBehavior.  The Panel is available in
 all
 >> pages. whatever the page the use is, as long as the panel is rendered,
 it
 >> polls the server on regular intervals and displays notifications for
 various
 >> events - the facebook style.  This is one of the features that has made
 me
 >> stick with wicket.
 >>
 >> regards.
 >> Josh
 >>
 >>
 >> 1.
 >>
 http://wicket.apache.org/apidocs/1.4/org/apache/wicket/ajax/AjaxSelfUpdatingTimerBehavior.html
 >>
 >> On Fri, Nov 12, 2010 at 10:37 AM, Frank van Lankvelt <
 >> f.vanlankv...@onehippo.com> wrote:
 >>
 >>> On Fri, Nov 12, 2010 at 3:55 PM, José Monzón 
 wrote:
 >>> > I recently run into a problem that has make me consider whether
 >>> > continuing using Wicket or not for a project. I hope guys you can
 >>> > throw some light into it.
 >>> >
 >>> > I need to create a web application that uses ajax to keep itself
 >>> > udpated while still allows the user interact with it also using Ajax.
 >>> > Imagine something as GMail, Documents, Facebook, Twitter, etc.
 >>> >
 >>> > On this pages, is very common to have some ajax COMMET, long polling
 >>> > or also known as inverse AJAX to keep the page updated. But that
 >>> > doesn't prevent the user to click here and there and update the page
 >>> > also using AJAX. They are independent XMLHttpRequest with a browser
 >>> > can handle perfectly.
 >>> >
 >>> > I was thinking about doing this on Wicket, but apparently it's
 >>> > impossible by design:
 >>> > https://issues.apache.org/jira/browse/WICKET-2437
 >>> >
 >>> > Page objects aren't thread-safe and wicket will block any other
 thread
 >>> > (AJAX call) that tries to access the page while another request (for
 >>> > instance our long poll) is there.
 >>> >
 >>> > Have you ever find yourself into this kind of problem? What's the
 >>> > workaround if any?
 >>> >
 >>> the comet-like functionality is useful f

Re: Wicket + GAE

[Martin Grigorov]

Hi Alex,

Can you try with Wicket 1.5-SNAPSHOT ?
Yesterday I closed your ticket.

I read all blogs about the topic and no one complains about this problem,
but in the appengine ticket I mentioned in my first mail there are 30 users
having this problem and the ticket is still not resolved.

On Fri, Nov 12, 2010 at 8:46 PM, Alex Objelean wrote:

>
> Martin, are you sure you deployed the application using DEPLOYMENT mode and
> resourcePollFrequency is null?
>
Yes, for both.

> At least these are the only configurations needs to be updated (in wicket
> 1.4) in order to work with GAE.
>
> Alex
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Wicket-GAE-tp3039886p3040226.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Wicket design incompatible with Web 2.0 ?

[Igor Vaynberg]

not a bad idea. we already have a concept of "channels", but right now
they can only queue or drop requests. with some work it should be
possible to add an "aggregate" mode and process multiple callbacks
within the same request. please file a jira issue.

-igor

On Fri, Nov 12, 2010 at 11:44 AM, John Armstrong  wrote:
> EXT-JS does a nice queueing model where you can set a queue timer (say
> 100ms) and any AJAX requests get bundled up into a single package that
> goes across the wire at once, returning and then being sent back to
> their callers.
>
> This lets a page update many components at once in what appears to be
> real-time without blocking.
>
> Might be an interesting model for wicket at some point in the future.
>
> Yes, I know, EST-JS is a client-side framework. I am only using it as
> an example of how some stacks are resolving these sorts of issues.
>
> John-
>
> On Fri, Nov 12, 2010 at 9:36 AM, Josh Kamau  wrote:
>> AjaxSelfUpdatingTimerBehavior works perfectly for notifications. I guess it
>> wouldnt work very well for a chat-like scenario. I have set mine to 30
>> seconds and it works perfectly. Long polling would hold  a request with
>> nothing to report back in most of the times.
>>
>> regards.
>>
>> On Fri, Nov 12, 2010 at 12:17 PM, Igor Vaynberg 
>> wrote:
>>
>>> why would you need a request every few milliseconds. what is so urgent
>>> about a notification that you cant poll every ten seconds?
>>>
>>> what your long polling thread can do is access the page, render a part
>>> of it, and send it back to the client - but, only when it has
>>> something to say. which instead of many very quick requests to the
>>> page is many very quick accesses to the page.
>>>
>>> -igor
>>>
>>> On Fri, Nov 12, 2010 at 9:13 AM, José Monzón  wrote:
>>> > AjaxSelfUpdatingTimerBehavior is cool for simple repetitive requests.
>>> > But if you try to do long polling with that (comet, retain the request
>>> > in the server as long as you can while there's nothing to send back)
>>> > you will see how your other ajax requests are queued and your page
>>> > freezes.
>>> >
>>> > I've seen many people using AjaxSelfUpdatingTimerBehavior to replace
>>> > long poling. Performing very quick requests to the server (every few
>>> > millisecons). I believe that abusing  AjaxSelfUpdatingTimerBehavior
>>> > leads you to scalability issues. Not to mention that the browser gets
>>> > choppy in slow computers.
>>> >
>>> >
>>> > On Fri, Nov 12, 2010 at 4:42 PM, Josh Kamau 
>>> wrote:
>>> >> I have implemented an application that alerts the user on various
>>> events. I
>>> >> created a notification's bar at the top of my page. This bar has a panel
>>> on
>>> >> which i added AjaxSelfUpdatingTimerBehavior.  The Panel is available in
>>> all
>>> >> pages. whatever the page the use is, as long as the panel is rendered,
>>> it
>>> >> polls the server on regular intervals and displays notifications for
>>> various
>>> >> events - the facebook style.  This is one of the features that has made
>>> me
>>> >> stick with wicket.
>>> >>
>>> >> regards.
>>> >> Josh
>>> >>
>>> >>
>>> >> 1.
>>> >>
>>> http://wicket.apache.org/apidocs/1.4/org/apache/wicket/ajax/AjaxSelfUpdatingTimerBehavior.html
>>> >>
>>> >> On Fri, Nov 12, 2010 at 10:37 AM, Frank van Lankvelt <
>>> >> f.vanlankv...@onehippo.com> wrote:
>>> >>
>>> >>> On Fri, Nov 12, 2010 at 3:55 PM, José Monzón 
>>> wrote:
>>> >>> > I recently run into a problem that has make me consider whether
>>> >>> > continuing using Wicket or not for a project. I hope guys you can
>>> >>> > throw some light into it.
>>> >>> >
>>> >>> > I need to create a web application that uses ajax to keep itself
>>> >>> > udpated while still allows the user interact with it also using Ajax.
>>> >>> > Imagine something as GMail, Documents, Facebook, Twitter, etc.
>>> >>> >
>>> >>> > On this pages, is very common to have some ajax COMMET, long polling
>>> >>> > or also known as inverse AJAX to keep the page updated. But that
>>> >>> > doesn't prevent the user to click here and there and update the page
>>> >>> > also using AJAX. They are independent XMLHttpRequest with a browser
>>> >>> > can handle perfectly.
>>> >>> >
>>> >>> > I was thinking about doing this on Wicket, but apparently it's
>>> >>> > impossible by design:
>>> >>> > https://issues.apache.org/jira/browse/WICKET-2437
>>> >>> >
>>> >>> > Page objects aren't thread-safe and wicket will block any other
>>> thread
>>> >>> > (AJAX call) that tries to access the page while another request (for
>>> >>> > instance our long poll) is there.
>>> >>> >
>>> >>> > Have you ever find yourself into this kind of problem? What's the
>>> >>> > workaround if any?
>>> >>> >
>>> >>> the comet-like functionality is useful for things like chatting, but
>>> >>> you wouldn't
>>> >>> need access to the page for that as you're unlikely to change the
>>> >>> component tree.
>>> >>>
>>> >>> The alternative to long polling is, of course, regular polling.  Queue
>>> >>> the events
>>

Re: Wicket + GAE

[Alex Objelean]

Martin, are you sure you deployed the application using DEPLOYMENT mode and
resourcePollFrequency is null?
At least these are the only configurations needs to be updated (in wicket
1.4) in order to work with GAE. 

Alex
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-GAE-tp3039886p3040226.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket design incompatible with Web 2.0 ?

[John Armstrong]

EXT-JS does a nice queueing model where you can set a queue timer (say
100ms) and any AJAX requests get bundled up into a single package that
goes across the wire at once, returning and then being sent back to
their callers.

This lets a page update many components at once in what appears to be
real-time without blocking.

Might be an interesting model for wicket at some point in the future.

Yes, I know, EST-JS is a client-side framework. I am only using it as
an example of how some stacks are resolving these sorts of issues.

John-

On Fri, Nov 12, 2010 at 9:36 AM, Josh Kamau  wrote:
> AjaxSelfUpdatingTimerBehavior works perfectly for notifications. I guess it
> wouldnt work very well for a chat-like scenario. I have set mine to 30
> seconds and it works perfectly. Long polling would hold  a request with
> nothing to report back in most of the times.
>
> regards.
>
> On Fri, Nov 12, 2010 at 12:17 PM, Igor Vaynberg 
> wrote:
>
>> why would you need a request every few milliseconds. what is so urgent
>> about a notification that you cant poll every ten seconds?
>>
>> what your long polling thread can do is access the page, render a part
>> of it, and send it back to the client - but, only when it has
>> something to say. which instead of many very quick requests to the
>> page is many very quick accesses to the page.
>>
>> -igor
>>
>> On Fri, Nov 12, 2010 at 9:13 AM, José Monzón  wrote:
>> > AjaxSelfUpdatingTimerBehavior is cool for simple repetitive requests.
>> > But if you try to do long polling with that (comet, retain the request
>> > in the server as long as you can while there's nothing to send back)
>> > you will see how your other ajax requests are queued and your page
>> > freezes.
>> >
>> > I've seen many people using AjaxSelfUpdatingTimerBehavior to replace
>> > long poling. Performing very quick requests to the server (every few
>> > millisecons). I believe that abusing  AjaxSelfUpdatingTimerBehavior
>> > leads you to scalability issues. Not to mention that the browser gets
>> > choppy in slow computers.
>> >
>> >
>> > On Fri, Nov 12, 2010 at 4:42 PM, Josh Kamau 
>> wrote:
>> >> I have implemented an application that alerts the user on various
>> events. I
>> >> created a notification's bar at the top of my page. This bar has a panel
>> on
>> >> which i added AjaxSelfUpdatingTimerBehavior.  The Panel is available in
>> all
>> >> pages. whatever the page the use is, as long as the panel is rendered,
>> it
>> >> polls the server on regular intervals and displays notifications for
>> various
>> >> events - the facebook style.  This is one of the features that has made
>> me
>> >> stick with wicket.
>> >>
>> >> regards.
>> >> Josh
>> >>
>> >>
>> >> 1.
>> >>
>> http://wicket.apache.org/apidocs/1.4/org/apache/wicket/ajax/AjaxSelfUpdatingTimerBehavior.html
>> >>
>> >> On Fri, Nov 12, 2010 at 10:37 AM, Frank van Lankvelt <
>> >> f.vanlankv...@onehippo.com> wrote:
>> >>
>> >>> On Fri, Nov 12, 2010 at 3:55 PM, José Monzón 
>> wrote:
>> >>> > I recently run into a problem that has make me consider whether
>> >>> > continuing using Wicket or not for a project. I hope guys you can
>> >>> > throw some light into it.
>> >>> >
>> >>> > I need to create a web application that uses ajax to keep itself
>> >>> > udpated while still allows the user interact with it also using Ajax.
>> >>> > Imagine something as GMail, Documents, Facebook, Twitter, etc.
>> >>> >
>> >>> > On this pages, is very common to have some ajax COMMET, long polling
>> >>> > or also known as inverse AJAX to keep the page updated. But that
>> >>> > doesn't prevent the user to click here and there and update the page
>> >>> > also using AJAX. They are independent XMLHttpRequest with a browser
>> >>> > can handle perfectly.
>> >>> >
>> >>> > I was thinking about doing this on Wicket, but apparently it's
>> >>> > impossible by design:
>> >>> > https://issues.apache.org/jira/browse/WICKET-2437
>> >>> >
>> >>> > Page objects aren't thread-safe and wicket will block any other
>> thread
>> >>> > (AJAX call) that tries to access the page while another request (for
>> >>> > instance our long poll) is there.
>> >>> >
>> >>> > Have you ever find yourself into this kind of problem? What's the
>> >>> > workaround if any?
>> >>> >
>> >>> the comet-like functionality is useful for things like chatting, but
>> >>> you wouldn't
>> >>> need access to the page for that as you're unlikely to change the
>> >>> component tree.
>> >>>
>> >>> The alternative to long polling is, of course, regular polling.  Queue
>> >>> the events
>> >>> and process them when a request is processed.  Then you can access the
>> >>> page,
>> >>> update the component tree and rerender the relevant parts.
>> >>> Maintaining the queue
>> >>> is a bit tricky, as one has to make sure that it doesn't grow too
>> >>> large and it must be
>> >>> disposed of properly.
>> >>>
>> >>> We've used this method to implement a single-page-application that
>> updates
>> >>> exclusively with ajax.  It's n

Re: Wicket design incompatible with Web 2.0 ?

[Arjun Dhar]

Hi,
 so I learn wicket as I go along right, dont mind me. :)

I implemented an alerting system using JSONP and WebServices (i prefer
REST). In my opinion that would scale well for multiple servers also. ..why
would one even require Wicket in this picture?

..Also, am interested to know how would this scale for a federated system
and clustered environment. I'd assume wicket would have some overhead in its
case?!
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-design-incompatible-with-Web-2-0-tp3039707p3040040.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket design incompatible with Web 2.0 ?

[Josh Kamau]

AjaxSelfUpdatingTimerBehavior works perfectly for notifications. I guess it
wouldnt work very well for a chat-like scenario. I have set mine to 30
seconds and it works perfectly. Long polling would hold  a request with
nothing to report back in most of the times.

regards.

On Fri, Nov 12, 2010 at 12:17 PM, Igor Vaynberg wrote:

> why would you need a request every few milliseconds. what is so urgent
> about a notification that you cant poll every ten seconds?
>
> what your long polling thread can do is access the page, render a part
> of it, and send it back to the client - but, only when it has
> something to say. which instead of many very quick requests to the
> page is many very quick accesses to the page.
>
> -igor
>
> On Fri, Nov 12, 2010 at 9:13 AM, José Monzón  wrote:
> > AjaxSelfUpdatingTimerBehavior is cool for simple repetitive requests.
> > But if you try to do long polling with that (comet, retain the request
> > in the server as long as you can while there's nothing to send back)
> > you will see how your other ajax requests are queued and your page
> > freezes.
> >
> > I've seen many people using AjaxSelfUpdatingTimerBehavior to replace
> > long poling. Performing very quick requests to the server (every few
> > millisecons). I believe that abusing  AjaxSelfUpdatingTimerBehavior
> > leads you to scalability issues. Not to mention that the browser gets
> > choppy in slow computers.
> >
> >
> > On Fri, Nov 12, 2010 at 4:42 PM, Josh Kamau 
> wrote:
> >> I have implemented an application that alerts the user on various
> events. I
> >> created a notification's bar at the top of my page. This bar has a panel
> on
> >> which i added AjaxSelfUpdatingTimerBehavior.  The Panel is available in
> all
> >> pages. whatever the page the use is, as long as the panel is rendered,
> it
> >> polls the server on regular intervals and displays notifications for
> various
> >> events - the facebook style.  This is one of the features that has made
> me
> >> stick with wicket.
> >>
> >> regards.
> >> Josh
> >>
> >>
> >> 1.
> >>
> http://wicket.apache.org/apidocs/1.4/org/apache/wicket/ajax/AjaxSelfUpdatingTimerBehavior.html
> >>
> >> On Fri, Nov 12, 2010 at 10:37 AM, Frank van Lankvelt <
> >> f.vanlankv...@onehippo.com> wrote:
> >>
> >>> On Fri, Nov 12, 2010 at 3:55 PM, José Monzón 
> wrote:
> >>> > I recently run into a problem that has make me consider whether
> >>> > continuing using Wicket or not for a project. I hope guys you can
> >>> > throw some light into it.
> >>> >
> >>> > I need to create a web application that uses ajax to keep itself
> >>> > udpated while still allows the user interact with it also using Ajax.
> >>> > Imagine something as GMail, Documents, Facebook, Twitter, etc.
> >>> >
> >>> > On this pages, is very common to have some ajax COMMET, long polling
> >>> > or also known as inverse AJAX to keep the page updated. But that
> >>> > doesn't prevent the user to click here and there and update the page
> >>> > also using AJAX. They are independent XMLHttpRequest with a browser
> >>> > can handle perfectly.
> >>> >
> >>> > I was thinking about doing this on Wicket, but apparently it's
> >>> > impossible by design:
> >>> > https://issues.apache.org/jira/browse/WICKET-2437
> >>> >
> >>> > Page objects aren't thread-safe and wicket will block any other
> thread
> >>> > (AJAX call) that tries to access the page while another request (for
> >>> > instance our long poll) is there.
> >>> >
> >>> > Have you ever find yourself into this kind of problem? What's the
> >>> > workaround if any?
> >>> >
> >>> the comet-like functionality is useful for things like chatting, but
> >>> you wouldn't
> >>> need access to the page for that as you're unlikely to change the
> >>> component tree.
> >>>
> >>> The alternative to long polling is, of course, regular polling.  Queue
> >>> the events
> >>> and process them when a request is processed.  Then you can access the
> >>> page,
> >>> update the component tree and rerender the relevant parts.
> >>> Maintaining the queue
> >>> is a bit tricky, as one has to make sure that it doesn't grow too
> >>> large and it must be
> >>> disposed of properly.
> >>>
> >>> We've used this method to implement a single-page-application that
> updates
> >>> exclusively with ajax.  It's not in the facebook/google/... range, but
> >>> it works well
> >>> enough for our purposes.
> >>>
> >>> cheers, Frank
> >>>
> >>> > -
> >>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> > For additional commands, e-mail: users-h...@wicket.apache.org
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Hippo
> >>> Europe  •  Amsterdam  Oosteinde 11  •  1017 WT Amsterdam  •  +31 (0)20
> 522
> >>> 4466
> >>> USA  • San Francisco  185 H Street Suite B  •  Petaluma CA 94952-5100
> >>> •  +1 (707) 773 4646
> >>> Canada•   Montréal  5369 Boulevard St-Laurent #430 •  Montréal QC
> >>> H2T 1S5  •  +1 (514) 316 8966
> >>

Re: Wicket design incompatible with Web 2.0 ?

[Igor Vaynberg]

why would you need a request every few milliseconds. what is so urgent
about a notification that you cant poll every ten seconds?

what your long polling thread can do is access the page, render a part
of it, and send it back to the client - but, only when it has
something to say. which instead of many very quick requests to the
page is many very quick accesses to the page.

-igor

On Fri, Nov 12, 2010 at 9:13 AM, José Monzón  wrote:
> AjaxSelfUpdatingTimerBehavior is cool for simple repetitive requests.
> But if you try to do long polling with that (comet, retain the request
> in the server as long as you can while there's nothing to send back)
> you will see how your other ajax requests are queued and your page
> freezes.
>
> I've seen many people using AjaxSelfUpdatingTimerBehavior to replace
> long poling. Performing very quick requests to the server (every few
> millisecons). I believe that abusing  AjaxSelfUpdatingTimerBehavior
> leads you to scalability issues. Not to mention that the browser gets
> choppy in slow computers.
>
>
> On Fri, Nov 12, 2010 at 4:42 PM, Josh Kamau  wrote:
>> I have implemented an application that alerts the user on various events. I
>> created a notification's bar at the top of my page. This bar has a panel on
>> which i added AjaxSelfUpdatingTimerBehavior.  The Panel is available in all
>> pages. whatever the page the use is, as long as the panel is rendered, it
>> polls the server on regular intervals and displays notifications for various
>> events - the facebook style.  This is one of the features that has made me
>> stick with wicket.
>>
>> regards.
>> Josh
>>
>>
>> 1.
>> http://wicket.apache.org/apidocs/1.4/org/apache/wicket/ajax/AjaxSelfUpdatingTimerBehavior.html
>>
>> On Fri, Nov 12, 2010 at 10:37 AM, Frank van Lankvelt <
>> f.vanlankv...@onehippo.com> wrote:
>>
>>> On Fri, Nov 12, 2010 at 3:55 PM, José Monzón  wrote:
>>> > I recently run into a problem that has make me consider whether
>>> > continuing using Wicket or not for a project. I hope guys you can
>>> > throw some light into it.
>>> >
>>> > I need to create a web application that uses ajax to keep itself
>>> > udpated while still allows the user interact with it also using Ajax.
>>> > Imagine something as GMail, Documents, Facebook, Twitter, etc.
>>> >
>>> > On this pages, is very common to have some ajax COMMET, long polling
>>> > or also known as inverse AJAX to keep the page updated. But that
>>> > doesn't prevent the user to click here and there and update the page
>>> > also using AJAX. They are independent XMLHttpRequest with a browser
>>> > can handle perfectly.
>>> >
>>> > I was thinking about doing this on Wicket, but apparently it's
>>> > impossible by design:
>>> > https://issues.apache.org/jira/browse/WICKET-2437
>>> >
>>> > Page objects aren't thread-safe and wicket will block any other thread
>>> > (AJAX call) that tries to access the page while another request (for
>>> > instance our long poll) is there.
>>> >
>>> > Have you ever find yourself into this kind of problem? What's the
>>> > workaround if any?
>>> >
>>> the comet-like functionality is useful for things like chatting, but
>>> you wouldn't
>>> need access to the page for that as you're unlikely to change the
>>> component tree.
>>>
>>> The alternative to long polling is, of course, regular polling.  Queue
>>> the events
>>> and process them when a request is processed.  Then you can access the
>>> page,
>>> update the component tree and rerender the relevant parts.
>>> Maintaining the queue
>>> is a bit tricky, as one has to make sure that it doesn't grow too
>>> large and it must be
>>> disposed of properly.
>>>
>>> We've used this method to implement a single-page-application that updates
>>> exclusively with ajax.  It's not in the facebook/google/... range, but
>>> it works well
>>> enough for our purposes.
>>>
>>> cheers, Frank
>>>
>>> > -
>>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> > For additional commands, e-mail: users-h...@wicket.apache.org
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Hippo
>>> Europe  •  Amsterdam  Oosteinde 11  •  1017 WT Amsterdam  •  +31 (0)20 522
>>> 4466
>>> USA  • San Francisco  185 H Street Suite B  •  Petaluma CA 94952-5100
>>> •  +1 (707) 773 4646
>>> Canada    •   Montréal  5369 Boulevard St-Laurent #430 •  Montréal QC
>>> H2T 1S5  •  +1 (514) 316 8966
>>> www.onehippo.com  •  www.onehippo.org  •  i...@onehippo.com
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscri

Re: Wicket design incompatible with Web 2.0 ?

[José Monzón]

Hi Sebastian,
Thanks for the hint. I'll have a look to wicket-push. Hope it works :)


On Fri, Nov 12, 2010 at 4:46 PM, Sebastian  wrote:
> You can use the wicketstuff wicket-push project. It should work for your
> case. It either uses a stateful cometd channel to receive update requests or
> alternatively a timer-based polling approach. It does not block the UI, you
> can continue using AJAX requests.
>
> Regards,
>
> Seb
>
> On 12.11.2010 15:55, José Monzón wrote:
>>
>> I recently run into a problem that has make me consider whether
>> continuing using Wicket or not for a project. I hope guys you can
>> throw some light into it.
>>
>> I need to create a web application that uses ajax to keep itself
>> udpated while still allows the user interact with it also using Ajax.
>> Imagine something as GMail, Documents, Facebook, Twitter, etc.
>>
>> On this pages, is very common to have some ajax COMMET, long polling
>> or also known as inverse AJAX to keep the page updated. But that
>> doesn't prevent the user to click here and there and update the page
>> also using AJAX. They are independent XMLHttpRequest with a browser
>> can handle perfectly.
>>
>> I was thinking about doing this on Wicket, but apparently it's
>> impossible by design:
>> https://issues.apache.org/jira/browse/WICKET-2437
>>
>> Page objects aren't thread-safe and wicket will block any other thread
>> (AJAX call) that tries to access the page while another request (for
>> instance our long poll) is there.
>>
>> Have you ever find yourself into this kind of problem? What's the
>> workaround if any?
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket design incompatible with Web 2.0 ?

[José Monzón]

AjaxSelfUpdatingTimerBehavior is cool for simple repetitive requests.
But if you try to do long polling with that (comet, retain the request
in the server as long as you can while there's nothing to send back)
you will see how your other ajax requests are queued and your page
freezes.

I've seen many people using AjaxSelfUpdatingTimerBehavior to replace
long poling. Performing very quick requests to the server (every few
millisecons). I believe that abusing  AjaxSelfUpdatingTimerBehavior
leads you to scalability issues. Not to mention that the browser gets
choppy in slow computers.


On Fri, Nov 12, 2010 at 4:42 PM, Josh Kamau  wrote:
> I have implemented an application that alerts the user on various events. I
> created a notification's bar at the top of my page. This bar has a panel on
> which i added AjaxSelfUpdatingTimerBehavior.  The Panel is available in all
> pages. whatever the page the use is, as long as the panel is rendered, it
> polls the server on regular intervals and displays notifications for various
> events - the facebook style.  This is one of the features that has made me
> stick with wicket.
>
> regards.
> Josh
>
>
> 1.
> http://wicket.apache.org/apidocs/1.4/org/apache/wicket/ajax/AjaxSelfUpdatingTimerBehavior.html
>
> On Fri, Nov 12, 2010 at 10:37 AM, Frank van Lankvelt <
> f.vanlankv...@onehippo.com> wrote:
>
>> On Fri, Nov 12, 2010 at 3:55 PM, José Monzón  wrote:
>> > I recently run into a problem that has make me consider whether
>> > continuing using Wicket or not for a project. I hope guys you can
>> > throw some light into it.
>> >
>> > I need to create a web application that uses ajax to keep itself
>> > udpated while still allows the user interact with it also using Ajax.
>> > Imagine something as GMail, Documents, Facebook, Twitter, etc.
>> >
>> > On this pages, is very common to have some ajax COMMET, long polling
>> > or also known as inverse AJAX to keep the page updated. But that
>> > doesn't prevent the user to click here and there and update the page
>> > also using AJAX. They are independent XMLHttpRequest with a browser
>> > can handle perfectly.
>> >
>> > I was thinking about doing this on Wicket, but apparently it's
>> > impossible by design:
>> > https://issues.apache.org/jira/browse/WICKET-2437
>> >
>> > Page objects aren't thread-safe and wicket will block any other thread
>> > (AJAX call) that tries to access the page while another request (for
>> > instance our long poll) is there.
>> >
>> > Have you ever find yourself into this kind of problem? What's the
>> > workaround if any?
>> >
>> the comet-like functionality is useful for things like chatting, but
>> you wouldn't
>> need access to the page for that as you're unlikely to change the
>> component tree.
>>
>> The alternative to long polling is, of course, regular polling.  Queue
>> the events
>> and process them when a request is processed.  Then you can access the
>> page,
>> update the component tree and rerender the relevant parts.
>> Maintaining the queue
>> is a bit tricky, as one has to make sure that it doesn't grow too
>> large and it must be
>> disposed of properly.
>>
>> We've used this method to implement a single-page-application that updates
>> exclusively with ajax.  It's not in the facebook/google/... range, but
>> it works well
>> enough for our purposes.
>>
>> cheers, Frank
>>
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >
>> >
>>
>>
>>
>> --
>> Hippo
>> Europe  •  Amsterdam  Oosteinde 11  •  1017 WT Amsterdam  •  +31 (0)20 522
>> 4466
>> USA  • San Francisco  185 H Street Suite B  •  Petaluma CA 94952-5100
>> •  +1 (707) 773 4646
>> Canada    •   Montréal  5369 Boulevard St-Laurent #430 •  Montréal QC
>> H2T 1S5  •  +1 (514) 316 8966
>> www.onehippo.com  •  www.onehippo.org  •  i...@onehippo.com
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Everything serializable (and a Java general question)

[Igor Vaynberg]

the models have to be serializable, not the model objects they point to.

for example if you are accessing a hibernate entity then the model
that accesses it has to be serializable, not the entity itself. this
is why we have LoadableDetachableModels.

-igor

On Fri, Nov 12, 2010 at 8:18 AM, Brown, Berlin [GCG-PFS]
 wrote:
> I haven't entirely researched this.  But I know wicket recommends
> declaring your model objects as serializable so that if the page
> serializes than so do the objects.
>
> With this approach, I tend to define all or most of my beans and service
> objects as serializable.  Do you have to define an object serializable
> if it is accessed from Wicket (say on an event method)?
>
> Also, aren't there issues with declaring objects as serializable?  Is it
> insecure to put data in a serializable object?  Where by the security
> mechanisms for that object can be bypassed?
>
> For example.
>
> Some Panel.java:
>
> final Serializable x = new Serializable() {}
>
> final Component z = new Link() {
>  onClick {
>      x???  <--- does X have to be serializable in this case?
>  }
> }
>
> Berlin Brown (POL)
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Everything serializable (and a Java general question)

[James Carman]

Service objects should be injected via proxies, thus they would be
serializable already.


On Fri, Nov 12, 2010 at 11:18 AM, Brown, Berlin [GCG-PFS]
 wrote:
> I haven't entirely researched this.  But I know wicket recommends
> declaring your model objects as serializable so that if the page
> serializes than so do the objects.
>
> With this approach, I tend to define all or most of my beans and service
> objects as serializable.  Do you have to define an object serializable
> if it is accessed from Wicket (say on an event method)?
>
> Also, aren't there issues with declaring objects as serializable?  Is it
> insecure to put data in a serializable object?  Where by the security
> mechanisms for that object can be bypassed?
>
> For example.
>
> Some Panel.java:
>
> final Serializable x = new Serializable() {}
>
> final Component z = new Link() {
>  onClick {
>      x???  <--- does X have to be serializable in this case?
>  }
> }
>
> Berlin Brown (POL)
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket + GAE

[Martin Grigorov]

I hope there is some appengine setting
Otherwise https://issues.apache.org/jira/browse/WICKET-3138 is useless for
GAE :-)

On Fri, Nov 12, 2010 at 5:34 PM, Pedro Santos  wrote:

> If I correctly remember, I had the same problem, solved by calling
> page.setVersioned(false)
>
> On Fri, Nov 12, 2010 at 2:30 PM, Martin Grigorov  >wrote:
>
> > Hi GAE users,
> >
> > I'm trying to run Wicket 1.5 application in Google AppEngine and I'm
> > experiencing problem for which I cannot find a solution so far:
> >
> > SEVERE: Error serializing object class org.wicketstuff.gae.HomePage
> > [object=[Page class = org.wicketstuff.gae.HomePage, id = 0, render count
> =
> > 1]]
> > java.security.AccessControlException: access denied
> > (java.io.SerializablePermission enableSubclassImplementation)
> > at
> >
> >
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
> > at
> > java.security.AccessController.checkPermission(AccessController.java:546)
> > at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> > at
> >
> >
> com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:166)
> > at java.io.ObjectOutputStream.(ObjectOutputStream.java:253)
> > at
> >
> >
> org.apache.wicket.util.io.WicketObjectOutputStream.(WicketObjectOutputStream.java:437)
> > at
> >
> >
> org.apache.wicket.util.io.WicketObjectStreamFactory.newObjectOutputStream(WicketObjectStreamFactory.java:49)
> > at
> >
> >
> org.apache.wicket.util.lang.WicketObjects.objectToByteArray(WicketObjects.java:475)
> > at
> >
> >
> org.apache.wicket.pageStore.DefaultPageStore.serializePage(DefaultPageStore.java:364)
> > at
> >
> >
> org.apache.wicket.pageStore.DefaultPageStore.storePage(DefaultPageStore.java:153)
> > 
> >
> > The problem is described at
> > http://code.google.com/p/googleappengine/issues/detail?id=2500
> >
> > Basically GAE doesn't allow "new ObjectOutputStream()" which is necessary
> > to
> > convert Page object to byte[].
> > I tried:
> > - both IObjectStreamFactories - DefaultOSF and WicketOSF
> > - added true in appengine-web.xml
> > - add
> > 
> >  > value="Production"
> > />
> > 
> >
> > What I miss to be able to run Wicket app in GAE ?
> > I know there are some users of Wicket 1.4 out there - please advice!
> >
> > martin-g
> >
>
>
>
> --
> Pedro Henrique Oliveira dos Santos
>

Re: Wicket + GAE

[Pedro Santos]

If I correctly remember, I had the same problem, solved by calling
page.setVersioned(false)

On Fri, Nov 12, 2010 at 2:30 PM, Martin Grigorov wrote:

> Hi GAE users,
>
> I'm trying to run Wicket 1.5 application in Google AppEngine and I'm
> experiencing problem for which I cannot find a solution so far:
>
> SEVERE: Error serializing object class org.wicketstuff.gae.HomePage
> [object=[Page class = org.wicketstuff.gae.HomePage, id = 0, render count =
> 1]]
> java.security.AccessControlException: access denied
> (java.io.SerializablePermission enableSubclassImplementation)
> at
>
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
> at
> java.security.AccessController.checkPermission(AccessController.java:546)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> at
>
> com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:166)
> at java.io.ObjectOutputStream.(ObjectOutputStream.java:253)
> at
>
> org.apache.wicket.util.io.WicketObjectOutputStream.(WicketObjectOutputStream.java:437)
> at
>
> org.apache.wicket.util.io.WicketObjectStreamFactory.newObjectOutputStream(WicketObjectStreamFactory.java:49)
> at
>
> org.apache.wicket.util.lang.WicketObjects.objectToByteArray(WicketObjects.java:475)
> at
>
> org.apache.wicket.pageStore.DefaultPageStore.serializePage(DefaultPageStore.java:364)
> at
>
> org.apache.wicket.pageStore.DefaultPageStore.storePage(DefaultPageStore.java:153)
> 
>
> The problem is described at
> http://code.google.com/p/googleappengine/issues/detail?id=2500
>
> Basically GAE doesn't allow "new ObjectOutputStream()" which is necessary
> to
> convert Page object to byte[].
> I tried:
> - both IObjectStreamFactories - DefaultOSF and WicketOSF
> - added true in appengine-web.xml
> - add
> 
>  value="Production"
> />
> 
>
> What I miss to be able to run Wicket app in GAE ?
> I know there are some users of Wicket 1.4 out there - please advice!
>
> martin-g
>



-- 
Pedro Henrique Oliveira dos Santos

Wicket + GAE

[Martin Grigorov]

Hi GAE users,

I'm trying to run Wicket 1.5 application in Google AppEngine and I'm
experiencing problem for which I cannot find a solution so far:

SEVERE: Error serializing object class org.wicketstuff.gae.HomePage
[object=[Page class = org.wicketstuff.gae.HomePage, id = 0, render count =
1]]
java.security.AccessControlException: access denied
(java.io.SerializablePermission enableSubclassImplementation)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:166)
at java.io.ObjectOutputStream.(ObjectOutputStream.java:253)
at
org.apache.wicket.util.io.WicketObjectOutputStream.(WicketObjectOutputStream.java:437)
at
org.apache.wicket.util.io.WicketObjectStreamFactory.newObjectOutputStream(WicketObjectStreamFactory.java:49)
at
org.apache.wicket.util.lang.WicketObjects.objectToByteArray(WicketObjects.java:475)
at
org.apache.wicket.pageStore.DefaultPageStore.serializePage(DefaultPageStore.java:364)
at
org.apache.wicket.pageStore.DefaultPageStore.storePage(DefaultPageStore.java:153)


The problem is described at
http://code.google.com/p/googleappengine/issues/detail?id=2500

Basically GAE doesn't allow "new ObjectOutputStream()" which is necessary to
convert Page object to byte[].
I tried:
- both IObjectStreamFactories - DefaultOSF and WicketOSF
- added true in appengine-web.xml
- add




What I miss to be able to run Wicket app in GAE ?
I know there are some users of Wicket 1.4 out there - please advice!

martin-g

Everything serializable (and a Java general question)

[Brown, Berlin [GCG-PFS]]

I haven't entirely researched this.  But I know wicket recommends
declaring your model objects as serializable so that if the page
serializes than so do the objects.
 
With this approach, I tend to define all or most of my beans and service
objects as serializable.  Do you have to define an object serializable
if it is accessed from Wicket (say on an event method)?
 
Also, aren't there issues with declaring objects as serializable?  Is it
insecure to put data in a serializable object?  Where by the security
mechanisms for that object can be bypassed?
 
For example.
 
Some Panel.java:
 
final Serializable x = new Serializable() {}
 
final Component z = new Link() {
  onClick {
  x???  <--- does X have to be serializable in this case?
  }
}
 
Berlin Brown (POL)
 

Re: Wicket design incompatible with Web 2.0 ?

[Sebastian]

...and in case you are trying wicket-push, please use the latest version 
1.4.13. We did some substantial improvements there.


Regards,

Seb

On 12.11.2010 15:55, José Monzón wrote:

I recently run into a problem that has make me consider whether
continuing using Wicket or not for a project. I hope guys you can
throw some light into it.

I need to create a web application that uses ajax to keep itself
udpated while still allows the user interact with it also using Ajax.
Imagine something as GMail, Documents, Facebook, Twitter, etc.

On this pages, is very common to have some ajax COMMET, long polling
or also known as inverse AJAX to keep the page updated. But that
doesn't prevent the user to click here and there and update the page
also using AJAX. They are independent XMLHttpRequest with a browser
can handle perfectly.

I was thinking about doing this on Wicket, but apparently it's
impossible by design:
https://issues.apache.org/jira/browse/WICKET-2437

Page objects aren't thread-safe and wicket will block any other thread
(AJAX call) that tries to access the page while another request (for
instance our long poll) is there.

Have you ever find yourself into this kind of problem? What's the
workaround if any?

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket design incompatible with Web 2.0 ?

[Martin Grigorov]

Also take a look at:
http://jfarcand.wordpress.com/2010/10/07/writing-websocket-application-using-apache-wicket/
https://github.com/jfarcand/atmosphere/tree/master/samples/wicket-clock/

https://github.com/martin-g/wicket-atmosphere-tests


On Fri, Nov 12, 2010 at 4:49 PM, jcgarciam  wrote:

>
> Josh, what monzonj saids is valid.
>
> When doing ajax operation in wicket, you can't trigger other ajax operation
> in parallel that change the component tree because it will get block until
> the first operation finishes.
>
> But having said that, you need to consider that web browser limits the
> amount of http request you can make to a single host (vary from 2 to 8 i
> believe) which mean you can't have either a lot of ajax component doing
> poll
> at the same time.
>
> On Fri, Nov 12, 2010 at 12:43 PM, Josh Kamau [via Apache Wicket] <
> ml-node+3039773-1741461412-65...@n4.nabble.com
> 
> >
> > wrote:
>
> > I have implemented an application that alerts the user on various events.
> I
> >
> > created a notification's bar at the top of my page. This bar has a panel
> on
> >
> > which i added AjaxSelfUpdatingTimerBehavior.  The Panel is available in
> all
> >
> > pages. whatever the page the use is, as long as the panel is rendered, it
> > polls the server on regular intervals and displays notifications for
> > various
> > events - the facebook style.  This is one of the features that has made
> me
> > stick with wicket.
> >
> > regards.
> > Josh
> >
> >
> > 1.
> >
> >
> http://wicket.apache.org/apidocs/1.4/org/apache/wicket/ajax/AjaxSelfUpdatingTimerBehavior.html
> >
> >
> > On Fri, Nov 12, 2010 at 10:37 AM, Frank van Lankvelt <
> > [hidden email] >
> > wrote:
> >
> > > On Fri, Nov 12, 2010 at 3:55 PM, José Monzón <[hidden email]<
> http://user/SendEmail.jtp?type=node&node=3039773&i=1>>
> > wrote:
> > > > I recently run into a problem that has make me consider whether
> > > > continuing using Wicket or not for a project. I hope guys you can
> > > > throw some light into it.
> > > >
> > > > I need to create a web application that uses ajax to keep itself
> > > > udpated while still allows the user interact with it also using Ajax.
> > > > Imagine something as GMail, Documents, Facebook, Twitter, etc.
> > > >
> > > > On this pages, is very common to have some ajax COMMET, long polling
> > > > or also known as inverse AJAX to keep the page updated. But that
> > > > doesn't prevent the user to click here and there and update the page
> > > > also using AJAX. They are independent XMLHttpRequest with a browser
> > > > can handle perfectly.
> > > >
> > > > I was thinking about doing this on Wicket, but apparently it's
> > > > impossible by design:
> > > > https://issues.apache.org/jira/browse/WICKET-2437
> > > >
> > > > Page objects aren't thread-safe and wicket will block any other
> thread
> > > > (AJAX call) that tries to access the page while another request (for
> > > > instance our long poll) is there.
> > > >
> > > > Have you ever find yourself into this kind of problem? What's the
> > > > workaround if any?
> > > >
> > > the comet-like functionality is useful for things like chatting, but
> > > you wouldn't
> > > need access to the page for that as you're unlikely to change the
> > > component tree.
> > >
> > > The alternative to long polling is, of course, regular polling.  Queue
> > > the events
> > > and process them when a request is processed.  Then you can access the
> > > page,
> > > update the component tree and rerender the relevant parts.
> > > Maintaining the queue
> > > is a bit tricky, as one has to make sure that it doesn't grow too
> > > large and it must be
> > > disposed of properly.
> > >
> > > We've used this method to implement a single-page-application that
> > updates
> > > exclusively with ajax.  It's not in the facebook/google/... range, but
> > > it works well
> > > enough for our purposes.
> > >
> > > cheers, Frank
> > >
> > > > -
> > > > To unsubscribe, e-mail: [hidden email]<
> http://user/SendEmail.jtp?type=node&node=3039773&i=2>
> > > > For additional commands, e-mail: [hidden email]<
> http://user/SendEmail.jtp?type=node&node=3039773&i=3>
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Hippo
> > > Europe  •  Amsterdam  Oosteinde 11  •  1017 WT Amsterdam  •  +31 (0)20
> > 522
> > > 4466
> > > USA  • San Francisco  185 H Street Suite B  •  Petaluma CA 94952-5100
> > > •  +1 (707) 773 4646
> > > Canada•   Montréal  5369 Boulevard St-Laurent #430 •  Montréal QC
> > > H2T 1S5  •  +1 (514) 316 8966
> > > www.onehippo.com  •  www.onehippo.org  •  [hidden email]<
> http://user/SendEmail.jtp?type=node&node=3039773&i=4>
> > >
> > > -
> > > To unsubscribe, e-mail: [hidden email]<
> http://user/SendEmail.jtp?ty

Re: Wicket design incompatible with Web 2.0 ?

[jcgarciam]

Thanks Sebastian, i was going to suggest the same thing. I haven't tried
myself but should be the way to  go.

On Fri, Nov 12, 2010 at 12:47 PM, Sebastian-61 [via Apache Wicket] <
ml-node+3039789-309873457-65...@n4.nabble.com
> wrote:

> You can use the wicketstuff wicket-push project. It should work for your
> case. It either uses a stateful cometd channel to receive update
> requests or alternatively a timer-based polling approach. It does not
> block the UI, you can continue using AJAX requests.
>
> Regards,
>
> Seb
>
> On 12.11.2010 15:55, José Monzón wrote:
>
> > I recently run into a problem that has make me consider whether
> > continuing using Wicket or not for a project. I hope guys you can
> > throw some light into it.
> >
> > I need to create a web application that uses ajax to keep itself
> > udpated while still allows the user interact with it also using Ajax.
> > Imagine something as GMail, Documents, Facebook, Twitter, etc.
> >
> > On this pages, is very common to have some ajax COMMET, long polling
> > or also known as inverse AJAX to keep the page updated. But that
> > doesn't prevent the user to click here and there and update the page
> > also using AJAX. They are independent XMLHttpRequest with a browser
> > can handle perfectly.
> >
> > I was thinking about doing this on Wicket, but apparently it's
> > impossible by design:
> > https://issues.apache.org/jira/browse/WICKET-2437
> >
> > Page objects aren't thread-safe and wicket will block any other thread
> > (AJAX call) that tries to access the page while another request (for
> > instance our long poll) is there.
> >
> > Have you ever find yourself into this kind of problem? What's the
> > workaround if any?
> >
> > -
> > To unsubscribe, e-mail: [hidden 
> > email]
> > For additional commands, e-mail: [hidden 
> > email]
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: [hidden 
> email]
> For additional commands, e-mail: [hidden 
> email]
>
>
>
> --
>  View message @
> http://apache-wicket.1842946.n4.nabble.com/Wicket-design-incompatible-with-Web-2-0-tp3039707p3039789.html
> To start a new topic under Apache Wicket, email
> ml-node+1842946-398011874-65...@n4.nabble.com
> To unsubscribe from Apache Wicket, click 
> here.
>
>
>


-- 
Sincerely,
JC (http://www.linkedin.com/in/jcgarciam)
Work smarter, not harder!.

-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-design-incompatible-with-Web-2-0-tp3039707p3039796.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket design incompatible with Web 2.0 ?

[jcgarciam]

Josh, what monzonj saids is valid.

When doing ajax operation in wicket, you can't trigger other ajax operation
in parallel that change the component tree because it will get block until
the first operation finishes.

But having said that, you need to consider that web browser limits the
amount of http request you can make to a single host (vary from 2 to 8 i
believe) which mean you can't have either a lot of ajax component doing poll
at the same time.

On Fri, Nov 12, 2010 at 12:43 PM, Josh Kamau [via Apache Wicket] <
ml-node+3039773-1741461412-65...@n4.nabble.com
> wrote:

> I have implemented an application that alerts the user on various events. I
>
> created a notification's bar at the top of my page. This bar has a panel on
>
> which i added AjaxSelfUpdatingTimerBehavior.  The Panel is available in all
>
> pages. whatever the page the use is, as long as the panel is rendered, it
> polls the server on regular intervals and displays notifications for
> various
> events - the facebook style.  This is one of the features that has made me
> stick with wicket.
>
> regards.
> Josh
>
>
> 1.
>
> http://wicket.apache.org/apidocs/1.4/org/apache/wicket/ajax/AjaxSelfUpdatingTimerBehavior.html
>
>
> On Fri, Nov 12, 2010 at 10:37 AM, Frank van Lankvelt <
> [hidden email] >
> wrote:
>
> > On Fri, Nov 12, 2010 at 3:55 PM, José Monzón <[hidden 
> > email]>
> wrote:
> > > I recently run into a problem that has make me consider whether
> > > continuing using Wicket or not for a project. I hope guys you can
> > > throw some light into it.
> > >
> > > I need to create a web application that uses ajax to keep itself
> > > udpated while still allows the user interact with it also using Ajax.
> > > Imagine something as GMail, Documents, Facebook, Twitter, etc.
> > >
> > > On this pages, is very common to have some ajax COMMET, long polling
> > > or also known as inverse AJAX to keep the page updated. But that
> > > doesn't prevent the user to click here and there and update the page
> > > also using AJAX. They are independent XMLHttpRequest with a browser
> > > can handle perfectly.
> > >
> > > I was thinking about doing this on Wicket, but apparently it's
> > > impossible by design:
> > > https://issues.apache.org/jira/browse/WICKET-2437
> > >
> > > Page objects aren't thread-safe and wicket will block any other thread
> > > (AJAX call) that tries to access the page while another request (for
> > > instance our long poll) is there.
> > >
> > > Have you ever find yourself into this kind of problem? What's the
> > > workaround if any?
> > >
> > the comet-like functionality is useful for things like chatting, but
> > you wouldn't
> > need access to the page for that as you're unlikely to change the
> > component tree.
> >
> > The alternative to long polling is, of course, regular polling.  Queue
> > the events
> > and process them when a request is processed.  Then you can access the
> > page,
> > update the component tree and rerender the relevant parts.
> > Maintaining the queue
> > is a bit tricky, as one has to make sure that it doesn't grow too
> > large and it must be
> > disposed of properly.
> >
> > We've used this method to implement a single-page-application that
> updates
> > exclusively with ajax.  It's not in the facebook/google/... range, but
> > it works well
> > enough for our purposes.
> >
> > cheers, Frank
> >
> > > -
> > > To unsubscribe, e-mail: [hidden 
> > > email]
> > > For additional commands, e-mail: [hidden 
> > > email]
> > >
> > >
> >
> >
> >
> > --
> > Hippo
> > Europe  •  Amsterdam  Oosteinde 11  •  1017 WT Amsterdam  •  +31 (0)20
> 522
> > 4466
> > USA  • San Francisco  185 H Street Suite B  •  Petaluma CA 94952-5100
> > •  +1 (707) 773 4646
> > Canada•   Montréal  5369 Boulevard St-Laurent #430 •  Montréal QC
> > H2T 1S5  •  +1 (514) 316 8966
> > www.onehippo.com  •  www.onehippo.org  •  [hidden 
> > email]
> >
> > -
> > To unsubscribe, e-mail: [hidden 
> > email]
> > For additional commands, e-mail: [hidden 
> > email]
> >
> >
>
>
> --
>  View message @
> http://apache-wicket.1842946.n4.nabble.com/Wicket-design-incompatible-with-Web-2-0-tp3039707p3039773.html
> To start a new topic under Apache Wicket, email
> ml-node+1842946-398011874-65...@n4.nabble.com
> To unsubscribe from Apache Wicket, click 
> here

Re: Wicket design incompatible with Web 2.0 ?

[Sebastian]

You can use the wicketstuff wicket-push project. It should work for your 
case. It either uses a stateful cometd channel to receive update 
requests or alternatively a timer-based polling approach. It does not 
block the UI, you can continue using AJAX requests.


Regards,

Seb

On 12.11.2010 15:55, José Monzón wrote:

I recently run into a problem that has make me consider whether
continuing using Wicket or not for a project. I hope guys you can
throw some light into it.

I need to create a web application that uses ajax to keep itself
udpated while still allows the user interact with it also using Ajax.
Imagine something as GMail, Documents, Facebook, Twitter, etc.

On this pages, is very common to have some ajax COMMET, long polling
or also known as inverse AJAX to keep the page updated. But that
doesn't prevent the user to click here and there and update the page
also using AJAX. They are independent XMLHttpRequest with a browser
can handle perfectly.

I was thinking about doing this on Wicket, but apparently it's
impossible by design:
https://issues.apache.org/jira/browse/WICKET-2437

Page objects aren't thread-safe and wicket will block any other thread
(AJAX call) that tries to access the page while another request (for
instance our long poll) is there.

Have you ever find yourself into this kind of problem? What's the
workaround if any?

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Need Wicket Book

[dhar_ar]

I agree with you; the idea of a book should really be to clarify concepts. 
Because technology keeps moving on and that's where the code and user forums 
come is. But a foundation ;..specially on architecture and life cycles is best 
explained bya book. That's what I"m searching for . But each one to their own!

:)

Sent from BlackBerry® on Airtel

-Original Message-
From: "Frank Silbermann" 
Date: Fri, 12 Nov 2010 09:40:42 
To: 
Reply-To: users@wicket.apache.org
Subject: RE: Need Wicket Book

When I coded my application originally based on Wicket 1.2, I after looking at 
the DataTable example, I had to peruse the DataTable (and, for 1.2, 
DefaultDataTable) code to figure out what I needed to do for my task.

Even if I had had_Wicket_in_Action_ at my disposal back then, I think I still 
would have had to look at the DataTable implementation.

Perhaps with open source it is expected that users will have to look at the 
implementation code now and then, but I think for many people it is a 
psychological hurdle.  /Frank

-Original Message-
From: Martijn Dashorst [mailto:martijn.dasho...@gmail.com] 
Sent: Friday, November 12, 2010 8:57 AM
To: users@wicket.apache.org
Subject: Re: Need Wicket Book

On Fri, Nov 12, 2010 at 3:24 PM, Frank Silbermann
 wrote:
> Does any Wicket book describe the use of Wicket Extensions, such as
> DataTable?  I didn't see anything on that subject in _Wicket_in_Action_.

In order to keep the book manageable (in thickness) and to be able to
publish it on some derailed schedule, datatable and extensions friends
were not included. It would probably have costed another 20 pages or
so to properly discuss datatable, and another 20 to quickly summarize
each component in extensions.

We believe that the explanations offered in Wicket in Action should
provide anyone to fully grasp Wicket concepts and that should suffice
to have a really quick understanding of anything wicket extensions
throws at you (unless you look at modal window, or the tree components
;-)

Martijn

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket design incompatible with Web 2.0 ?

[Josh Kamau]

I have implemented an application that alerts the user on various events. I
created a notification's bar at the top of my page. This bar has a panel on
which i added AjaxSelfUpdatingTimerBehavior.  The Panel is available in all
pages. whatever the page the use is, as long as the panel is rendered, it
polls the server on regular intervals and displays notifications for various
events - the facebook style.  This is one of the features that has made me
stick with wicket.

regards.
Josh


1.
http://wicket.apache.org/apidocs/1.4/org/apache/wicket/ajax/AjaxSelfUpdatingTimerBehavior.html

On Fri, Nov 12, 2010 at 10:37 AM, Frank van Lankvelt <
f.vanlankv...@onehippo.com> wrote:

> On Fri, Nov 12, 2010 at 3:55 PM, José Monzón  wrote:
> > I recently run into a problem that has make me consider whether
> > continuing using Wicket or not for a project. I hope guys you can
> > throw some light into it.
> >
> > I need to create a web application that uses ajax to keep itself
> > udpated while still allows the user interact with it also using Ajax.
> > Imagine something as GMail, Documents, Facebook, Twitter, etc.
> >
> > On this pages, is very common to have some ajax COMMET, long polling
> > or also known as inverse AJAX to keep the page updated. But that
> > doesn't prevent the user to click here and there and update the page
> > also using AJAX. They are independent XMLHttpRequest with a browser
> > can handle perfectly.
> >
> > I was thinking about doing this on Wicket, but apparently it's
> > impossible by design:
> > https://issues.apache.org/jira/browse/WICKET-2437
> >
> > Page objects aren't thread-safe and wicket will block any other thread
> > (AJAX call) that tries to access the page while another request (for
> > instance our long poll) is there.
> >
> > Have you ever find yourself into this kind of problem? What's the
> > workaround if any?
> >
> the comet-like functionality is useful for things like chatting, but
> you wouldn't
> need access to the page for that as you're unlikely to change the
> component tree.
>
> The alternative to long polling is, of course, regular polling.  Queue
> the events
> and process them when a request is processed.  Then you can access the
> page,
> update the component tree and rerender the relevant parts.
> Maintaining the queue
> is a bit tricky, as one has to make sure that it doesn't grow too
> large and it must be
> disposed of properly.
>
> We've used this method to implement a single-page-application that updates
> exclusively with ajax.  It's not in the facebook/google/... range, but
> it works well
> enough for our purposes.
>
> cheers, Frank
>
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>
>
>
> --
> Hippo
> Europe  •  Amsterdam  Oosteinde 11  •  1017 WT Amsterdam  •  +31 (0)20 522
> 4466
> USA  • San Francisco  185 H Street Suite B  •  Petaluma CA 94952-5100
> •  +1 (707) 773 4646
> Canada•   Montréal  5369 Boulevard St-Laurent #430 •  Montréal QC
> H2T 1S5  •  +1 (514) 316 8966
> www.onehippo.com  •  www.onehippo.org  •  i...@onehippo.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

RE: Need Wicket Book

[Frank Silbermann]

When I coded my application originally based on Wicket 1.2, I after looking at 
the DataTable example, I had to peruse the DataTable (and, for 1.2, 
DefaultDataTable) code to figure out what I needed to do for my task.

Even if I had had _Wicket_in_Action_ at my disposal back then, I think I still 
would have had to look at the DataTable implementation.

Perhaps with open source it is expected that users will have to look at the 
implementation code now and then, but I think for many people it is a 
psychological hurdle.  /Frank

-Original Message-
From: Martijn Dashorst [mailto:martijn.dasho...@gmail.com] 
Sent: Friday, November 12, 2010 8:57 AM
To: users@wicket.apache.org
Subject: Re: Need Wicket Book

On Fri, Nov 12, 2010 at 3:24 PM, Frank Silbermann
 wrote:
> Does any Wicket book describe the use of Wicket Extensions, such as
> DataTable?  I didn't see anything on that subject in _Wicket_in_Action_.

In order to keep the book manageable (in thickness) and to be able to
publish it on some derailed schedule, datatable and extensions friends
were not included. It would probably have costed another 20 pages or
so to properly discuss datatable, and another 20 to quickly summarize
each component in extensions.

We believe that the explanations offered in Wicket in Action should
provide anyone to fully grasp Wicket concepts and that should suffice
to have a really quick understanding of anything wicket extensions
throws at you (unless you look at modal window, or the tree components
;-)

Martijn

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket design incompatible with Web 2.0 ?

[Frank van Lankvelt]

On Fri, Nov 12, 2010 at 3:55 PM, José Monzón  wrote:
> I recently run into a problem that has make me consider whether
> continuing using Wicket or not for a project. I hope guys you can
> throw some light into it.
>
> I need to create a web application that uses ajax to keep itself
> udpated while still allows the user interact with it also using Ajax.
> Imagine something as GMail, Documents, Facebook, Twitter, etc.
>
> On this pages, is very common to have some ajax COMMET, long polling
> or also known as inverse AJAX to keep the page updated. But that
> doesn't prevent the user to click here and there and update the page
> also using AJAX. They are independent XMLHttpRequest with a browser
> can handle perfectly.
>
> I was thinking about doing this on Wicket, but apparently it's
> impossible by design:
> https://issues.apache.org/jira/browse/WICKET-2437
>
> Page objects aren't thread-safe and wicket will block any other thread
> (AJAX call) that tries to access the page while another request (for
> instance our long poll) is there.
>
> Have you ever find yourself into this kind of problem? What's the
> workaround if any?
>
the comet-like functionality is useful for things like chatting, but
you wouldn't
need access to the page for that as you're unlikely to change the
component tree.

The alternative to long polling is, of course, regular polling.  Queue
the events
and process them when a request is processed.  Then you can access the page,
update the component tree and rerender the relevant parts.
Maintaining the queue
is a bit tricky, as one has to make sure that it doesn't grow too
large and it must be
disposed of properly.

We've used this method to implement a single-page-application that updates
exclusively with ajax.  It's not in the facebook/google/... range, but
it works well
enough for our purposes.

cheers, Frank

> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



-- 
Hippo
Europe  •  Amsterdam  Oosteinde 11  •  1017 WT Amsterdam  •  +31 (0)20 522 4466
USA  • San Francisco  185 H Street Suite B  •  Petaluma CA 94952-5100
•  +1 (707) 773 4646
Canada    •   Montréal  5369 Boulevard St-Laurent #430 •  Montréal QC
H2T 1S5  •  +1 (514) 316 8966
www.onehippo.com  •  www.onehippo.org  •  i...@onehippo.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Ajax response render as source in the browser

[Dan Retzlaff]

We're running 2.2.15 with the AJP connector. Before we'd pinpointed
our problem, we were considering using the HTTP connector instead.
That affects the requestor's IP in Tomcat though, so I'm glad we
didn't have to.

On Fri, Nov 12, 2010 at 12:31 AM, Wayne W  wrote:
> Thanks Dan,
>
> I thought I'd foudn my answer then! However we're using:
> Server version: Apache/2.2.9 (Unix)
> Server built:   Dec 10 2008 18:22:18
>
>
> So it looks like we already have that fix.
>
> Which version are you running?
>
>
>
> On Fri, Nov 12, 2010 at 5:19 AM, Dan Retzlaff  wrote:
>> We had this issue with Apache HTTPD in front of Tomcat. "Random" pages
>> would be rendered as text/plain instead of text/html.
>>
>> Bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=43478
>> Discussion: 
>> http://markmail.org/message/btwcnbl2i7ftwj4n#query:mod_proxy_ajp%20plain+page:1+mid:btwcnbl2i7ftwj4n+state:results
>>
>> Patch against Apache 2.3.0:
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?view=markup&pathrev=579707
>> Backport into Apache 2.2.7: 
>> http://archive.apache.org/dist/httpd/CHANGES_2.2.8
>>
>> Upgrading Apache solved the problem for us. So, what version of Apache
>> HTTPD are you using?
>>
>> Dan
>>
>> On Mon, Nov 8, 2010 at 8:30 AM, Igor Vaynberg  
>> wrote:
>>> well, you do have apache infront of tomcats, which *is* a proxy. i
>>> would write a jmeter script that tried to reproduce this and when you
>>> can run it against tomcat (not going through apache) and see if you
>>> can repro it that way. im guessing its something in your apache config
>>> since you are the only one having this issue.
>>>
>>> -igor
>>>
>>> On Sun, Nov 7, 2010 at 11:59 PM, Wayne W  
>>> wrote:
> the browser. do you have a proxy between the servlet container and the
> outside? maybe something is injecting a redirect or something weird.

 I did wonder if there was weird redirect issue, but after doing a lot
 of reading yesterday it seems the xmlrequest object *should* handle
 redirects fine. However either way we're not doing anything like that.
 We've got a couple of tomcat instances load balanced through apache,
 routed via a hardware firewall and out of the datacenter, so no
 proxies or anything at least I'm aware of.

 Its very frustrating.



 On Sun, Nov 7, 2010 at 9:41 PM, Igor Vaynberg  
 wrote:
> the only way i can see that happenning if the url is no longer
> processed by wicket's ajax support and so the response just ends up in
> the browser. do you have a proxy between the servlet container and the
> outside? maybe something is injecting a redirect or something weird.
>
> -igor
>
> On Sun, Nov 7, 2010 at 8:26 AM, Wayne W  
> wrote:
>> thanks Igor,
>>
>> I've just spent a few hours stepping though the code and I cannot see
>> anyway the content type could be set wrong - I see the content type is
>> set in the final respond(requestCycle) method, so I'm now thinking
>> this is not a content type issue.
>>
>> However we just got another user email with a screen shot showing the
>> wicket ajax-response in the browser so something is up.
>>
>> My javascript knowledge is weak at best so I've not been able to tell
>> much from the js .
>>
>> Any ideas on how we can resolve this or at least get more info?
>> many thanks
>>
>>
>>
>>
>> On Sat, Nov 6, 2010 at 6:40 PM, Igor Vaynberg  
>> wrote:
>>> see AjaxRequestTarget class, this is where the response is generated
>>> on the serverside
>>>
>>> wicket-ajax.js is where it is processed on the client side.
>>>
>>> -igor
>>>
>>> On Sat, Nov 6, 2010 at 2:49 AM, Wayne W  
>>> wrote:
 Hi Igor,

 Whats odd is that one guy was getting it on his iPad consistently and
 when we asked him to try his desktop he's got the same problem on
 Firefox on Mac. We initially though it might have been a browser
 issue. We then got another user who got it only once on Chrome on
 windows - all in the space of 1 day. We're worried that's it happening
 more often but users are not reporting the issue.

 Of course we cannot reproduce the issue, but its definitely happening.

 So you don;t think the shared resource could effect the threads in any 
 way?

 Where can I start looking in the wicket code to understand where ajax
 requests are serviced etc? Is there any where/docs I can find to get
 started at looking at this? -  at least to complete more my
 understanding of how it all works.

 thanks
 Wayne

 On Fri, Nov 5, 2010 at 10:05 PM, Igor Vaynberg 
  wrote:
> it may be a content type issue, but it is still weird because the
> response is received by the xml http request object, not the bro

Re: Need Wicket Book

[dhar_ar]

Yes I did see one mention it; see my post. The other book . On my phone so 
can't remember the name.

They don't have a paypal option and I can't remember the name so that's bad 
marketing for them. But looks like a good book (I read the sample chapters)
Sent from BlackBerry® on Airtel

-Original Message-
From: "Frank Silbermann" 
Date: Fri, 12 Nov 2010 08:24:36 
To: 
Reply-To: users@wicket.apache.org
Subject: RE: Need Wicket Book

Does any Wicket book describe the use of Wicket Extensions, such as
DataTable?  I didn't see anything on that subject in_Wicket_in_Action_.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Need Wicket Book

[Martijn Dashorst]

On Fri, Nov 12, 2010 at 3:24 PM, Frank Silbermann
 wrote:
> Does any Wicket book describe the use of Wicket Extensions, such as
> DataTable?  I didn't see anything on that subject in _Wicket_in_Action_.

In order to keep the book manageable (in thickness) and to be able to
publish it on some derailed schedule, datatable and extensions friends
were not included. It would probably have costed another 20 pages or
so to properly discuss datatable, and another 20 to quickly summarize
each component in extensions.

We believe that the explanations offered in Wicket in Action should
provide anyone to fully grasp Wicket concepts and that should suffice
to have a really quick understanding of anything wicket extensions
throws at you (unless you look at modal window, or the tree components
;-)

Martijn

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Wicket design incompatible with Web 2.0 ?

[José Monzón]

I recently run into a problem that has make me consider whether
continuing using Wicket or not for a project. I hope guys you can
throw some light into it.

I need to create a web application that uses ajax to keep itself
udpated while still allows the user interact with it also using Ajax.
Imagine something as GMail, Documents, Facebook, Twitter, etc.

On this pages, is very common to have some ajax COMMET, long polling
or also known as inverse AJAX to keep the page updated. But that
doesn't prevent the user to click here and there and update the page
also using AJAX. They are independent XMLHttpRequest with a browser
can handle perfectly.

I was thinking about doing this on Wicket, but apparently it's
impossible by design:
https://issues.apache.org/jira/browse/WICKET-2437

Page objects aren't thread-safe and wicket will block any other thread
(AJAX call) that tries to access the page while another request (for
instance our long poll) is there.

Have you ever find yourself into this kind of problem? What's the
workaround if any?

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Need Wicket Book

[Frank Silbermann]

Does any Wicket book describe the use of Wicket Extensions, such as
DataTable?  I didn't see anything on that subject in _Wicket_in_Action_.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Memory Leak in 1.4.13?

[James Carman]

I believe the original posters said he used a profiler
On Nov 12, 2010 1:46 AM, "Nico Guba"  wrote:
> Wouldn't a profiler help pinpoint the culprit?
>
> Sent from my iPhone
>
> On 12 Nov 2010, at 00:06, Mark Doyle  wrote:
>
>> I don't have any details to add except I say I saw this today too.
>>
>> I have a page with a lot of ajax panels on that are switched in and out.
If
>> I refreshed the page without doing anything the session size would grow
>> continuously.
>>
>> I also noticed some odd memory size (2.1MB +) related to the
>> AutoCompleteBehaviour.
>>
>> I switched back to 1.4.12 and it seems to have disappeared.
>>
>>
>> EDIT: I still get the large sizes related to the AutoCompleteBehavior
>> (although not as large) so that's probably something stupid I have done
:)
>>
>> From session inspector:
>>
>> -
Interface[target:SolrSearchFormPanel$SolrQueryForm$1(basicSearch:searchForm:solrSearchForm:searchKeyword),
>> page: org.esa.huginn.webapp.HuginnHomePageV2(32), interface:
>> IActivePageBehaviorListener.onRequest]
>> -
>>
org.apache.wicket.extensions.ajax.markup.html.autocomplete.autocompletebehavio...@191ac0df
>> - Session updatedPageMap updated, name: DEFAULT
>> - 1.2M
>>
>>
>> On Thu, Nov 11, 2010 at 7:44 PM, Pedro Santos 
wrote:
>>
>>> Hi guys, can you give a try?
>>>
>>>
>>>
https://issues.apache.org/jira/browse/WICKET-3108?focusedCommentId=12931123&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12931123
>>>
>>> On Thu, Nov 11, 2010 at 10:05 AM, Martijn Dashorst <
>>> martijn.dasho...@gmail.com> wrote:
>>>
 It is real, in our application we encountered this as well, but
 thought it was something we did wrong. Switching to httpsessionstore
 solved our immediate problem, so we didn't think to investigate
 further.

 The culprit might be the commits related to
 https://issues.apache.org/jira/browse/WICKET-3108

 If you could, revert those changes in a local wicket copy and see if
 the problem still persists.

 Initial investigation shows that it is not easy to reproduce.

 Martijn

 On Thu, Nov 11, 2010 at 6:00 AM, Brad Grier 
 wrote:
> Hopefully I can recreate in a quickstart. The pages in our app are
> dynamically created. If this leak is somehow related to how the layout
> engine works it might be difficult. I'll see what I can do.
>
> -Original Message- From: Jeremy Thomerson
> Sent: Wednesday, November 10, 2010 5:23 PM
> To: users@wicket.apache.org
> Subject: Re: Memory Leak in 1.4.13?
>
> On Wed, Nov 10, 2010 at 5:57 PM, Brad Grier
> wrote:
>
>> I recently upgraded our app from 1.4.12 to 1.4.13. Our app has an
>>> admin
>> screen that shows the current session size using Session’s
 getSizeInBytes
>> method. This screen is just a panel that gets replaced/refreshed via
 Ajax
>> when a link is clicked. Today I noticed that every time I clicked the
 link
>> to reload the panel the session size grows by around 3000 KB and
never
>> does
>> a gc. If I roll back to 1.4.12 and the problem goes away.
>>
>> In the Netbeans profiler, the only thing I see spiraling out of
>>> control
>> are
>> byte[] objects (serialized objects?). Nothing unusual appears with
the
>> size
>> or number of my application specific objects. For now I’m rolling
back
 to
>> 1.4.12 as I’m not sure how this is affecting things outside this
 specific
>> screen.
>>
>> Thanks.
>
>
> Please create a quickstart and see if you can reproduce this. If you
 can,
> attach it to a JIRA. We'll fix it.
>
> --
> Jeremy Thomerson
> http://wickettraining.com
> *Need a CMS for Wicket? Use Brix! http://brixcms.org*
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


>>>
>>>
>>> --
>>> Pedro Henrique Oliveira dos Santos
>>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>

Re: Edit whole ListItem via Ajax

[Martin Grigorov]

See http://wicketstuff.org/grid-examples/data-grid/editable.1


https://oss.sonatype.org/content/repositories/snapshots/org/wicketstuff/inmethod-grid/

On Fri, Nov 12, 2010 at 12:41 PM, Patrick Petermair <
patrick.peterm...@openforce.com> wrote:

> Hey list!
>
> I have a ListView and each ListItem has multiple labels. I want to add an
> "edit" button at the end of each line so that the user can switch into an
> edit mode, edit every label and then save them all at once.
>
> So far, I've used AjaxEditableLabel for a single label and it works great.
> Is there something similar for a whole ListItem so that multiple labels can
> be changed into TextFields?
>
> If there are no existing components with this feature, what would be the
> best way to implement it myself?
>
> Thanks & Cheers,
> Patrick
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Edit whole ListItem via Ajax

[Patrick Petermair]

Hey list!

I have a ListView and each ListItem has multiple labels. I want to add 
an "edit" button at the end of each line so that the user can switch 
into an edit mode, edit every label and then save them all at once.


So far, I've used AjaxEditableLabel for a single label and it works 
great. Is there something similar for a whole ListItem so that multiple 
labels can be changed into TextFields?


If there are no existing components with this feature, what would be the 
best way to implement it myself?


Thanks & Cheers,
Patrick

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Need Wicket Book

[Mark Doyle]

You don't get royalties? :o


It's a great book by the way, in fact I think it's the perfect book to start
your Wicket career with.

On Thu, Nov 11, 2010 at 2:53 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:

> On Thu, Nov 11, 2010 at 2:15 PM, Nico Guba  wrote:
> > Wouldn't the imminent release of Wicket 1.5 warrant a second edition?
> > It would be most welcome indeed :)
>
> Writing the second edition would not be on the scale of 'imminent'.
> The first edition took 2 guys roughly 2 years of personal time. Not
> something
> I'd like to repeat soon... If someone would pay me to write the book
> full time... that would be a whole different discussion :)
>
> Martijn
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Configuration of AbstractCalendar

[Jan Ferko]

Is there any other component to use instead of AbstractCalendar for 
plain calendar without DatePicker?


Jan



2010/11/9 Igor Vaynberg >


the value should be available in the formcomponent's model the
datepicker is attached to.

-igor


On Tue, Nov 9, 2010 at 2:27 AM, Jan Ferko mailto:julyl...@gmail.com>> wrote:
> Thanks,
>
> I figured it out. I have one more question ... can i use wicket
behaviour to
> retrieve selected date from calendar or i have to write some JS
hacks to do
> it?
>
>
> On 11/06/2010 06:38 PM, Igor Vaynberg wrote:
>>
>> i think its whatever format the yui component expects.
>>
>> -igor
>>
>> On Fri, Nov 5, 2010 at 9:25 AM, Jan Ferkomailto:julyl...@gmail.com>>  wrote:
>>
>>>
>>> Hi,
>>>
>>> Can anyone tell me what is format of map for
>>> AbstractCalendar.configureWidgetProperties(Map map) ? For
example I want
>>> to
>>> set navigator property to true, but map.put("navigator", true)
doesn't
>>> work.
>>>
>>> thanks for answer
>>> Jan
>>>
>>>
>>
>>
-
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org

>> For additional commands, e-mail: users-h...@wicket.apache.org

>>
>>
>
>
>
-
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org

> For additional commands, e-mail: users-h...@wicket.apache.org

>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org

For additional commands, e-mail: users-h...@wicket.apache.org





--
Jan Ferko,
julyl...@gmail.com 

Re: Ajax response render as source in the browser

[Wayne W]

Thanks Dan,

I thought I'd foudn my answer then! However we're using:
Server version: Apache/2.2.9 (Unix)
Server built:   Dec 10 2008 18:22:18


So it looks like we already have that fix.

Which version are you running?



On Fri, Nov 12, 2010 at 5:19 AM, Dan Retzlaff  wrote:
> We had this issue with Apache HTTPD in front of Tomcat. "Random" pages
> would be rendered as text/plain instead of text/html.
>
> Bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=43478
> Discussion: 
> http://markmail.org/message/btwcnbl2i7ftwj4n#query:mod_proxy_ajp%20plain+page:1+mid:btwcnbl2i7ftwj4n+state:results
>
> Patch against Apache 2.3.0:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?view=markup&pathrev=579707
> Backport into Apache 2.2.7: http://archive.apache.org/dist/httpd/CHANGES_2.2.8
>
> Upgrading Apache solved the problem for us. So, what version of Apache
> HTTPD are you using?
>
> Dan
>
> On Mon, Nov 8, 2010 at 8:30 AM, Igor Vaynberg  wrote:
>> well, you do have apache infront of tomcats, which *is* a proxy. i
>> would write a jmeter script that tried to reproduce this and when you
>> can run it against tomcat (not going through apache) and see if you
>> can repro it that way. im guessing its something in your apache config
>> since you are the only one having this issue.
>>
>> -igor
>>
>> On Sun, Nov 7, 2010 at 11:59 PM, Wayne W  wrote:
 the browser. do you have a proxy between the servlet container and the
 outside? maybe something is injecting a redirect or something weird.
>>>
>>> I did wonder if there was weird redirect issue, but after doing a lot
>>> of reading yesterday it seems the xmlrequest object *should* handle
>>> redirects fine. However either way we're not doing anything like that.
>>> We've got a couple of tomcat instances load balanced through apache,
>>> routed via a hardware firewall and out of the datacenter, so no
>>> proxies or anything at least I'm aware of.
>>>
>>> Its very frustrating.
>>>
>>>
>>>
>>> On Sun, Nov 7, 2010 at 9:41 PM, Igor Vaynberg  
>>> wrote:
 the only way i can see that happenning if the url is no longer
 processed by wicket's ajax support and so the response just ends up in
 the browser. do you have a proxy between the servlet container and the
 outside? maybe something is injecting a redirect or something weird.

 -igor

 On Sun, Nov 7, 2010 at 8:26 AM, Wayne W  
 wrote:
> thanks Igor,
>
> I've just spent a few hours stepping though the code and I cannot see
> anyway the content type could be set wrong - I see the content type is
> set in the final respond(requestCycle) method, so I'm now thinking
> this is not a content type issue.
>
> However we just got another user email with a screen shot showing the
> wicket ajax-response in the browser so something is up.
>
> My javascript knowledge is weak at best so I've not been able to tell
> much from the js .
>
> Any ideas on how we can resolve this or at least get more info?
> many thanks
>
>
>
>
> On Sat, Nov 6, 2010 at 6:40 PM, Igor Vaynberg  
> wrote:
>> see AjaxRequestTarget class, this is where the response is generated
>> on the serverside
>>
>> wicket-ajax.js is where it is processed on the client side.
>>
>> -igor
>>
>> On Sat, Nov 6, 2010 at 2:49 AM, Wayne W  
>> wrote:
>>> Hi Igor,
>>>
>>> Whats odd is that one guy was getting it on his iPad consistently and
>>> when we asked him to try his desktop he's got the same problem on
>>> Firefox on Mac. We initially though it might have been a browser
>>> issue. We then got another user who got it only once on Chrome on
>>> windows - all in the space of 1 day. We're worried that's it happening
>>> more often but users are not reporting the issue.
>>>
>>> Of course we cannot reproduce the issue, but its definitely happening.
>>>
>>> So you don;t think the shared resource could effect the threads in any 
>>> way?
>>>
>>> Where can I start looking in the wicket code to understand where ajax
>>> requests are serviced etc? Is there any where/docs I can find to get
>>> started at looking at this? -  at least to complete more my
>>> understanding of how it all works.
>>>
>>> thanks
>>> Wayne
>>>
>>> On Fri, Nov 5, 2010 at 10:05 PM, Igor Vaynberg 
>>>  wrote:
 it may be a content type issue, but it is still weird because the
 response is received by the xml http request object, not the browser
 directly. strange indeed.

 -igor

 On Fri, Nov 5, 2010 at 7:51 AM, Wayne W  
 wrote:
> Hi,
>
> has anyone had this issue? We're getting emails from our users that
> sometime when clicking on an ajax link the raw wicket ajax response is
> being rendered on the browser - ie the just see all the html source
>>>

Re: Guice 3 / Guice persist 3 and wicket 1.5 M3 filter issue

[Josh Kamau]

Thanks Martin

Am posting the same to Guice mailing list



On Fri, Nov 12, 2010 at 3:25 AM, Martin Grigorov wrote:

> Looks like a question for Guice Persist folks.
>
> The error message doesn't say what exactly is the problem but for some
> reason PersistFilter cannot be instantiated.
>
> On Fri, Nov 12, 2010 at 9:16 AM, Josh Kamau  wrote:
>
> > Hi there;
> >
> > Has anyone tried working with the wicket 1.5-m3 and the new guice/guice
> > persist 3 snapshots?
> >
> > am getting the below error:
> >
> > java.lang.InstantiationException: com.google.inject.persist.PersistFilter
> >at java.lang.Class.newInstance0(Class.java:340)
> >at java.lang.Class.newInstance(Class.java:308)
> >at org.mortbay.jetty.servlet.Holder.newInstance(Holder.java:153)
> >at
> org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:92)
> >at
> > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> >at
> >
> >
> org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:662)
> >at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
> >at
> >
> >
> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1272)
> >at
> > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
> >at
> > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:489)
> >at
> >
> >
> org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115)
> >at
> > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> >at
> >
> >
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
> >at
> >
> >
> org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
> >at
> > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> >at
> >
> >
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
> >at
> > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> >at
> > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
> >at org.mortbay.jetty.Server.doStart(Server.java:224)
> >at
> > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> >at
> >
> >
> org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
> >at
> >
> >
> org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441)
> >at
> >
> >
> org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383)
> >at
> >
> >
> org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210)
> >at
> > org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184)
> >at
> >
> >
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> >at
> >
> >
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> >at
> >
> >
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> >at
> >
> >
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> >at
> >
> >
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> >at
> >
> >
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> >at
> >
> >
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> >at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> >at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> >at
> > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >at
> >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> >at
> >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >at java.lang.reflect.Method.invoke(Method.java:597)
> >at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> >at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> >at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> >at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> >
> > Web.xml
> > 
> > http://java.sun.com/xml/ns/j2ee";
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
> > version="2.4">
> >
> >issuetracker
> >
> >
> >wicket.issuetracker
> >
> > org.apache.wicket.protocol.http.WicketFilter
> >
> >applicationClassName
> >

Re: Guice 3 / Guice persist 3 and wicket 1.5 M3 filter issue

[Martin Grigorov]

Looks like a question for Guice Persist folks.

The error message doesn't say what exactly is the problem but for some
reason PersistFilter cannot be instantiated.

On Fri, Nov 12, 2010 at 9:16 AM, Josh Kamau  wrote:

> Hi there;
>
> Has anyone tried working with the wicket 1.5-m3 and the new guice/guice
> persist 3 snapshots?
>
> am getting the below error:
>
> java.lang.InstantiationException: com.google.inject.persist.PersistFilter
>at java.lang.Class.newInstance0(Class.java:340)
>at java.lang.Class.newInstance(Class.java:308)
>at org.mortbay.jetty.servlet.Holder.newInstance(Holder.java:153)
>at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:92)
>at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>at
>
> org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:662)
>at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
>at
>
> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1272)
>at
> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
>at
> org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:489)
>at
>
> org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115)
>at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>at
>
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
>at
>
> org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
>at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>at
>
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
>at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>at
> org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
>at org.mortbay.jetty.Server.doStart(Server.java:224)
>at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>at
>
> org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
>at
>
> org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441)
>at
>
> org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383)
>at
>
> org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210)
>at
> org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184)
>at
>
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
>at
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
>at
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
>at
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
>at
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
>at
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
>at
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
>at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
>at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
>at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
>at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:597)
>at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
>
> Web.xml
> 
> http://java.sun.com/xml/ns/j2ee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
> version="2.4">
>
>issuetracker
>
>
>wicket.issuetracker
>
> org.apache.wicket.protocol.http.WicketFilter
>
>applicationClassName
>
> ke.co.at.issuetracker.WicketApplication
> 
> 
>
> 
>persistFilter
>com.google.inject.persist.PersistFilter
>
>
>  
>  wicket.issuetracker
>/*
>  
>
>  
>persistFilter
>/*
>
>
>
> 
>
> peristence.xml
>
> http://java.sun.com/xml/ns/persistence";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://java

Guice 3 / Guice persist 3 and wicket 1.5 M3 filter issue

[Josh Kamau]

Hi there;

Has anyone tried working with the wicket 1.5-m3 and the new guice/guice
persist 3 snapshots?

am getting the below error:

java.lang.InstantiationException: com.google.inject.persist.PersistFilter
at java.lang.Class.newInstance0(Class.java:340)
at java.lang.Class.newInstance(Class.java:308)
at org.mortbay.jetty.servlet.Holder.newInstance(Holder.java:153)
at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:92)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:662)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1272)
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
at
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:489)
at
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at
org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:224)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
at
org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441)
at
org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383)
at
org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210)
at
org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

Web.xml

http://java.sun.com/xml/ns/j2ee";
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
 version="2.4">

issuetracker


wicket.issuetracker

org.apache.wicket.protocol.http.WicketFilter

applicationClassName

ke.co.at.issuetracker.WicketApplication
 
 

 
persistFilter
com.google.inject.persist.PersistFilter


 
  wicket.issuetracker
/*
 

  
persistFilter
/*





peristence.xml

http://java.sun.com/xml/ns/persistence";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd";
version="1.0">

























Guice Module

package ke.co.at.issuetracker;

import ke.co.at.issuetracker.services.LoginService;
impo