Re: Error no application attached to current thread main with AnnotApplicationContextMock

2010-08-02 Thread Sam Grönblom

On 07/29/2010 06:21 PM, Igor Vaynberg wrote:

what version of wicket?

-igor

On Thu, Jul 29, 2010 at 1:54 AM, Sam Grönblomsam.gronb...@eficode.fi  wrote:
   

Getting this error when trying to use AnnotApplicationContextMock. Judging
by the example shown in the latest javadocs:
http://wicketbyexample.com/api/wicket-spring/latest/org/apache/wicket/spring/injection/annot/test/AnnotApplicationContextMock.html
you should create the application context mock before initializing
WicketTester. However then you get the error mentioned in the subject, ie.
no application attached to current thread main.

However if I initialize the WicketTester before the
AnnotApplicationContextMock I get null pointer errors which are caused when
the Panel or Page to be tested tries to access a service, which seems to
apply that they don't get injected correctly in this case either.

-
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

   

1.4.9

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



Re: Error no application attached to current thread main with AnnotApplicationContextMock

2010-08-02 Thread david_

I receive this exception also on method Application.get();
It happens on Tomcat after a redeploy. When I remove the work directory of
Tomcat, and do a restart, the error is gone.


2010/8/2 Sam Grönblom [via Apache Wicket] 
ml-node+2309949-1951419770-232...@n4.nabble.comml-node%2b2309949-1951419770-232...@n4.nabble.com


 On 07/29/2010 06:21 PM, Igor Vaynberg wrote:

  what version of wicket?
 
  -igor
 
  On Thu, Jul 29, 2010 at 1:54 AM, Sam Grönblom[hidden 
  email]http://user/SendEmail.jtp?type=nodenode=2309949i=0
  wrote:
 
  Getting this error when trying to use AnnotApplicationContextMock.
 Judging
  by the example shown in the latest javadocs:
 
 http://wicketbyexample.com/api/wicket-spring/latest/org/apache/wicket/spring/injection/annot/test/AnnotApplicationContextMock.html
  you should create the application context mock before initializing
  WicketTester. However then you get the error mentioned in the subject,
 ie.
  no application attached to current thread main.
 
  However if I initialize the WicketTester before the
  AnnotApplicationContextMock I get null pointer errors which are caused
 when
  the Panel or Page to be tested tries to access a service, which seems to

  apply that they don't get injected correctly in this case either.
 
  -
  To unsubscribe, e-mail: [hidden 
  email]http://user/SendEmail.jtp?type=nodenode=2309949i=1
  For additional commands, e-mail: [hidden 
  email]http://user/SendEmail.jtp?type=nodenode=2309949i=2
 
 
 
  -
  To unsubscribe, e-mail: [hidden 
  email]http://user/SendEmail.jtp?type=nodenode=2309949i=3
  For additional commands, e-mail: [hidden 
  email]http://user/SendEmail.jtp?type=nodenode=2309949i=4
 
 
 1.4.9

 -
 To unsubscribe, e-mail: [hidden 
 email]http://user/SendEmail.jtp?type=nodenode=2309949i=5
 For additional commands, e-mail: [hidden 
 email]http://user/SendEmail.jtp?type=nodenode=2309949i=6



 --
  View message @
 http://apache-wicket.1842946.n4.nabble.com/Error-no-application-attached-to-current-thread-main-with-AnnotApplicationContextMock-tp2306157p2309949.html
 To start a new topic under Wicket - User, email
 ml-node+1842947-1066186228-232...@n4.nabble.comml-node%2b1842947-1066186228-232...@n4.nabble.com
 To unsubscribe from Wicket - User, click 
 herehttp://apache-wicket.1842946.n4.nabble.com/subscriptions/Unsubscribe.jtp?code=bWV1bGVtYW5zLmRhdmlkQGdtYWlsLmNvbXwxODQyOTQ3fC0xOTcyOTcxMjQ2.




-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Error-no-application-attached-to-current-thread-main-with-AnnotApplicationContextMock-tp2306157p2309964.html
Sent from the Wicket - User mailing list archive at Nabble.com.


member variables, thread safety

2010-08-02 Thread Emmanouil Batsis


Apologies for the dumb question but I'm rather new to wicket and was  
wondering if it is safe to use member variables within components  
(i.e. compared to servlets, struts1 actions etc).


Many thanks,

Manos
--
Manos Batsis, Chief Technologist
 ___
   _/ /_  (_)_  __
 / __ `/ __ \/ / ___/ ___// __ `/ ___/
/ /_/ / /_/ / (__  |__  )/ /_/ / /
\__,_/_.___/_//(_)__, /_/
//
5, Daphnidos Street
141 22, Neo Iraklio
Athens, Greece
Tel: +30 210 2851517
Mob: +30 694 8376942






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



SV: member variables, thread safety

2010-08-02 Thread Wilhelmsen Tor Iver
 Apologies for the dumb question but I'm rather new to wicket and was
 wondering if it is safe to use member variables within components
 (i.e. compared to servlets, struts1 actions etc).

Mostly yes: The component instances are tied to the user's session via the 
pagemap. But be wary of excessive state, i.e. prefer (dynamic) models over 
straight values, pass a PageReference instead of the Page to other pages etc. 
Shared state between pages/components is better kept in a custom Session 
subclass.

- Tor Iver.

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



Re: String not serializable exception coming for interned strings from Model with JRockit/Weblogic

2010-08-02 Thread Daniel Peters

Hello Janos,

i have the excactlty the same problem with Wicket and JRockit R28.
The only way to fix it, was to go back to JRockit R27.

Hopefully they will fix it soon, the new R28.0.1 still has the problem.
A collegue of mine will do a post in the Oracle forums now.


regards
Daniel

On 08.07.2010 14:09, Janos Cserep wrote:


The following seems to be a bug with JRockit or Weblogic, but maybe
someone on this list has seen it before and has a better
workaround/solution.

We have been developing a Wicket application for a government agency
that is going to be used by 15k users. The application will be
deployed on a Weblogic cluster running on JRockit and Red Hat.

We have been experiencing strange Model object not serializable
exceptions coming from Model and traced it back to interned (by the
compiler) String  objects becoming not serializable after hitting the
server with a few hundred parallel users. Once the exception occurs
for a given String reference it keeps coming consistently for that
reference.

The current workaround is a custom Model class that has an overrided
setObject method which checks the object if it's instanceof
Serializable and if the check fails it sets new String(object) on the
Model. This eliminates the exceptions but would like a better solution
to the problem.

Has anyone seen anything like this?

Thanks and regards,

Janos

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




--
Daniel Peters

Idealo Internet GmbH
Fon +49 30 40301033
Fax +49 30 28598351
Zionskirchstr. 73, 10119 Berlin
Geschäftsführer: Martin Sinner, Dr. Albrecht v. Sonntag HRB 76749
Amtsgericht Berlin-Charlottenburg
USt.-ID: DE813070905
www.idealo.de | www.idealo.at | www.idealo.co.uk | www.idealo.fr

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



Re: How to Update contents of a child component?

2010-08-02 Thread Nivedan Nadaraj
Thanks guys for the input. Will give a yell when I have resolved it, thanks
for the time.

Reg
Niv

On Fri, Jul 30, 2010 at 7:54 PM, vov vov...@mail.ru wrote:


 Do not forgot about setOutputMarkupPlaceholderTag(true) for your components
 that initially as invisible.
 And use AJAX...:)
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/How-to-Update-contents-of-a-child-component-tp2307756p2307883.html
 Sent from the Wicket - User 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




using cometd with threads

2010-08-02 Thread fachhoch

I was looking into cometd , I tried the example it worked for me.I havea
new requirement ,
I have to update a panel in my page if a job running   seperately in a
thread has finished processing.


for example user clicks a link, this starts a job in a thread 
asychronously.  This job might take several days , when this user  logs in
back and if the   job is completed I want to show the user that the job is
completed,
 in my case a thread   has to publish to a channel  is this possible ?
 


-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/using-cometd-with-threads-tp2310323p2310323.html
Sent from the Wicket - User 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



Error Hypothesis...

2010-08-02 Thread James Carman
I have a theory about what is causing this issue.  Just wanted to run it by
you guys.  In my log files, I first see this:

org.apache.wicket.protocol.http.request.InvalidUrlException:
org.apache.wicket.WicketRuntimeException: After 1 minute the Pagemap null is
still locked by: Thread[http-10080-Processor23,5,main], giv
ing up trying to get the page for path: 3:projects
at
org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:262)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)


Then, a bit lower in the file, I see:

org.apache.wicket.util.upload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed. Connection reset
at
org.apache.wicket.util.upload.FileUploadBase.parseRequest(FileUploadBase.java:386)
at
org.apache.wicket.util.upload.ServletFileUpload.parseRequest(ServletFileUpload.java:129)
at
org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:155)
at
org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:83)
at
org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWebRequest(ServletWebRequest.java:500)
at
org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1668)
at
org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:862)
at
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:135)
at
org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
at
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:286)
at
org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)


My theory is that our users are beginning the file upload, but hitting F5
(reload) or something before letting the file upload complete.  Does that
sound feasible?  It's hard for me to test this because I'm running locally
and the file upload happens almost instantaneously.  The user that is
causing this to happen is in Europe, so I'm thinking the file upload (only
8.5 MB) might take a bit longer and they are getting impatient.  If this can
happen, is there something Wicket can do to not lock up the pagemap in this
case, because there's nothing really I can do to block the user from hitting
F5?


Re: Error Hypothesis...

2010-08-02 Thread Johan Compagner
yes that is most likely the case.



On Mon, Aug 2, 2010 at 16:17, James Carman ja...@carmanconsulting.com wrote:
 I have a theory about what is causing this issue.  Just wanted to run it by
 you guys.  In my log files, I first see this:

 org.apache.wicket.protocol.http.request.InvalidUrlException:
 org.apache.wicket.WicketRuntimeException: After 1 minute the Pagemap null is
 still locked by: Thread[http-10080-Processor23,5,main], giv
 ing up trying to get the page for path: 3:projects
    at
 org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:262)
    at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310)
    at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
    at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
    at
 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
    at
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
    at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
    at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)


 Then, a bit lower in the file, I see:

 org.apache.wicket.util.upload.FileUploadBase$IOFileUploadException:
 Processing of multipart/form-data request failed. Connection reset
    at
 org.apache.wicket.util.upload.FileUploadBase.parseRequest(FileUploadBase.java:386)
    at
 org.apache.wicket.util.upload.ServletFileUpload.parseRequest(ServletFileUpload.java:129)
    at
 org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:155)
    at
 org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:83)
    at
 org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWebRequest(ServletWebRequest.java:500)
    at
 org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1668)
    at
 org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:862)
    at
 org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:135)
    at
 org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
    at
 org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:286)
    at
 org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119)
    at
 org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
    at
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
    at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
    at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
    at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
    at
 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
    at
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)


 My theory is that our users are beginning the file upload, but hitting F5
 (reload) or something before letting the file upload complete.  Does that
 sound feasible?  It's hard for me to test this because I'm running locally
 and the file upload happens almost instantaneously.  The user that is
 causing this to happen is in Europe, so I'm thinking the file upload (only
 8.5 MB) might take a bit longer and they are getting impatient.  If this can
 happen, is there something Wicket can do to not lock up the pagemap in this
 case, because there's nothing really I can do to block the user from hitting
 F5?


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



Re: Error Hypothesis...

2010-08-02 Thread James Carman
So, is there anything I can do to fix the problem (aside from hitting the
user on the head and telling them not to do that again)?  They keep getting
the application error screen when they do that.

On Mon, Aug 2, 2010 at 10:27 AM, Johan Compagner jcompag...@gmail.comwrote:

 yes that is most likely the case.



 On Mon, Aug 2, 2010 at 16:17, James Carman ja...@carmanconsulting.com
 wrote:
  I have a theory about what is causing this issue.  Just wanted to run it
 by
  you guys.  In my log files, I first see this:
 
  org.apache.wicket.protocol.http.request.InvalidUrlException:
  org.apache.wicket.WicketRuntimeException: After 1 minute the Pagemap null
 is
  still locked by: Thread[http-10080-Processor23,5,main], giv
  ing up trying to get the page for path: 3:projects
 at
 
 org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:262)
 at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310)
 at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
 at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
 at
  org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
 at
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
 at
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
 at
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
 
 
  Then, a bit lower in the file, I see:
 
  org.apache.wicket.util.upload.FileUploadBase$IOFileUploadException:
  Processing of multipart/form-data request failed. Connection reset
 at
 
 org.apache.wicket.util.upload.FileUploadBase.parseRequest(FileUploadBase.java:386)
 at
 
 org.apache.wicket.util.upload.ServletFileUpload.parseRequest(ServletFileUpload.java:129)
 at
 
 org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:155)
 at
 
 org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:83)
 at
 
 org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWebRequest(ServletWebRequest.java:500)
 at
  org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1668)
 at
  org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:862)
 at
 
 org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:135)
 at
 
 org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
 at
 
 org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:286)
 at
 
 org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119)
 at
 
 org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
 at
 
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
 at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
 at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
 at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
 at
  org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
 at
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
 
 
  My theory is that our users are beginning the file upload, but hitting F5
  (reload) or something before letting the file upload complete.  Does that
  sound feasible?  It's hard for me to test this because I'm running
 locally
  and the file upload happens almost instantaneously.  The user that is
  causing this to happen is in Europe, so I'm thinking the file upload
 (only
  8.5 MB) might take a bit longer and they are getting impatient.  If this
 can
  happen, is there something Wicket can do to not lock up the pagemap in
 this
  case, because there's nothing really I can do to block the user from
 hitting
  F5?
 

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




Re: Error Hypothesis...

2010-08-02 Thread Johan Compagner
maybe do the actual upload through and iframe or something that has
its own pagemap?

Or block the ui in the browser as long as the upload is in progress
(but then user can still do F5, but they should know that they should
wait for it)

You can also for example use a flash uploader to a servlet that has
nice progress indicator (like gmail)


johan

On Mon, Aug 2, 2010 at 16:29, James Carman ja...@carmanconsulting.com wrote:
 So, is there anything I can do to fix the problem (aside from hitting the
 user on the head and telling them not to do that again)?  They keep getting
 the application error screen when they do that.

 On Mon, Aug 2, 2010 at 10:27 AM, Johan Compagner jcompag...@gmail.comwrote:

 yes that is most likely the case.



 On Mon, Aug 2, 2010 at 16:17, James Carman ja...@carmanconsulting.com
 wrote:
  I have a theory about what is causing this issue.  Just wanted to run it
 by
  you guys.  In my log files, I first see this:
 
  org.apache.wicket.protocol.http.request.InvalidUrlException:
  org.apache.wicket.WicketRuntimeException: After 1 minute the Pagemap null
 is
  still locked by: Thread[http-10080-Processor23,5,main], giv
  ing up trying to get the page for path: 3:projects
     at
 
 org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:262)
     at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310)
     at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
     at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
     at
  org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
     at
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
     at
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
     at
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
 
 
  Then, a bit lower in the file, I see:
 
  org.apache.wicket.util.upload.FileUploadBase$IOFileUploadException:
  Processing of multipart/form-data request failed. Connection reset
     at
 
 org.apache.wicket.util.upload.FileUploadBase.parseRequest(FileUploadBase.java:386)
     at
 
 org.apache.wicket.util.upload.ServletFileUpload.parseRequest(ServletFileUpload.java:129)
     at
 
 org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:155)
     at
 
 org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:83)
     at
 
 org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWebRequest(ServletWebRequest.java:500)
     at
  org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1668)
     at
  org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:862)
     at
 
 org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:135)
     at
 
 org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
     at
 
 org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:286)
     at
 
 org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119)
     at
 
 org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
     at
 
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
     at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
     at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
     at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
     at
  org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
     at
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
 
 
  My theory is that our users are beginning the file upload, but hitting F5
  (reload) or something before letting the file upload complete.  Does that
  sound feasible?  It's hard for me to test this because I'm running
 locally
  and the file upload happens almost instantaneously.  The user that is
  causing this to happen is in Europe, so I'm thinking the file upload
 (only
  8.5 MB) might take a bit longer and they are getting impatient.  If this
 can
  happen, is there something Wicket can do to not lock up the pagemap in
 this
  case, because there's nothing really I can do to block the user from
 hitting
  F5?
 

 -
 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: Error Hypothesis...

2010-08-02 Thread James Carman
Thanks!  I guess it's now a matter of telling the user if you want to do
stupid stuff like this, it's going to cost you X for us to code around it.
I'm sure that should get them to stop what they're doing. :)


On Mon, Aug 2, 2010 at 10:35 AM, Johan Compagner jcompag...@gmail.comwrote:

 maybe do the actual upload through and iframe or something that has
 its own pagemap?

 Or block the ui in the browser as long as the upload is in progress
 (but then user can still do F5, but they should know that they should
 wait for it)

 You can also for example use a flash uploader to a servlet that has
 nice progress indicator (like gmail)


 johan

 On Mon, Aug 2, 2010 at 16:29, James Carman ja...@carmanconsulting.com
 wrote:
  So, is there anything I can do to fix the problem (aside from hitting
 the
  user on the head and telling them not to do that again)?  They keep
 getting
  the application error screen when they do that.
 
  On Mon, Aug 2, 2010 at 10:27 AM, Johan Compagner jcompag...@gmail.com
 wrote:
 
  yes that is most likely the case.
 
 
 
  On Mon, Aug 2, 2010 at 16:17, James Carman ja...@carmanconsulting.com
  wrote:
   I have a theory about what is causing this issue.  Just wanted to run
 it
  by
   you guys.  In my log files, I first see this:
  
   org.apache.wicket.protocol.http.request.InvalidUrlException:
   org.apache.wicket.WicketRuntimeException: After 1 minute the Pagemap
 null
  is
   still locked by: Thread[http-10080-Processor23,5,main], giv
   ing up trying to get the page for path: 3:projects
  at
  
 
 org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:262)
  at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310)
  at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
  at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
  at
  
 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
  at
  
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
  at
  
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
  at
  
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
  
  
   Then, a bit lower in the file, I see:
  
   org.apache.wicket.util.upload.FileUploadBase$IOFileUploadException:
   Processing of multipart/form-data request failed. Connection reset
  at
  
 
 org.apache.wicket.util.upload.FileUploadBase.parseRequest(FileUploadBase.java:386)
  at
  
 
 org.apache.wicket.util.upload.ServletFileUpload.parseRequest(ServletFileUpload.java:129)
  at
  
 
 org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:155)
  at
  
 
 org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:83)
  at
  
 
 org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWebRequest(ServletWebRequest.java:500)
  at
  
 org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1668)
  at
   org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:862)
  at
  
 
 org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:135)
  at
  
 
 org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
  at
  
 
 org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:286)
  at
  
 
 org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119)
  at
  
 
 org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
  at
  
 
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
  at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
  at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
  at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
  at
  
 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
  at
  
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
  
  
   My theory is that our users are beginning the file upload, but hitting
 F5
   (reload) or something before letting the file upload complete.  Does
 that
   sound feasible?  It's hard for me to test this because I'm running
  locally
   and the file upload happens almost instantaneously.  The user that is
   causing this to happen is in Europe, so I'm thinking the file upload
  (only
   8.5 MB) might take a bit longer and they are getting impatient.  If
 this
  can
   happen, is there something Wicket can do to not lock up the pagemap in
  this
   case, because there's nothing really I can do to block the user from
  hitting
   F5?
  
 
  -
  To unsubscribe, e-mail: 

Re: Form Component Border - on Submit

2010-08-02 Thread gmail
On the submit link's onclick event you must iterate the form fields and run
the same script you do on the field's onblur event.

kjarbr




On 02.08.10 16.33, cresc md.naz...@gmail.com wrote:

 
 I have implemented form component border to validate and show the error
 messages inline just below the form component. (as explained here)
 http://www.java2s.com/Open-Source/Java-Document/JBoss/jboss-seam-2.1.0.A1/org/
 jboss/seam/example/wicket/FormInputBorder.java.htm
 
 But this works only when the focus is on the field and blur is triggered.
 Without focussing on the form component if I hit the submit ajax link, then
 how do I show inline error messages. Please assist.
 
 Regards,
 cresc



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



Re: using cometd with threads

2010-08-02 Thread Rodolfo Hansen
Yes, the code is designed to be thread safe.

On Mon, 2010-08-02 at 07:15 -0700, fachhoch wrote:
 I was looking into cometd , I tried the example it worked for me.I havea
 new requirement ,
 I have to update a panel in my page if a job running   seperately in a
 thread has finished processing.
 
 
 for example user clicks a link, this starts a job in a thread 
 asychronously.  This job might take several days , when this user  logs in
 back and if the   job is completed I want to show the user that the job is
 completed,
  in my case a thread   has to publish to a channel  is this possible ?
  
 
 



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



Re: using cometd with threads

2010-08-02 Thread fachhoch

but is it write to use web api in  my service  classes  ?
My job is in service  layer as its a thread and web has nothing to do with ,
now I have to call  web api (cometd api )  inside my service classes is 
this write ?

-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/using-cometd-with-threads-tp2310323p2310404.html
Sent from the Wicket - User 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: WicketTester and Palette component

2010-08-02 Thread loic

Hi Kent, thanks a lot i will take a look a this

Regards,
Loic
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/WicketTester-and-Palette-component-tp2306743p2310424.html
Sent from the Wicket - User 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



How to access div on wicket modal dialog

2010-08-02 Thread zoran

Hi,

I'm using a wicket modal dialog with the panel that contains a div container
like
div id=slider/div

I want to access it from jQuery to create a jQuery UI slider like 
$(#slider).slider();

For some reason, this doesn't work. Is there some reason related to wicket
that prevents this to find div container using its id, because the same
thing works fine when I use jQuery modal dialog instead of wicket modal
dialog?

Zoran
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/How-to-access-div-on-wicket-modal-dialog-tp2310678p2310678.html
Sent from the Wicket - User 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: using cometd with threads

2010-08-02 Thread Rodolfo Hansen
How are you getting the Bayeux service?

It is alright to think of the Bayeux service as a messaging api, that
jumps across your various layers (from the service to the javascript
client). As long as you remember you can't trust the javascript clients
(malicious users), you are fine.

On Mon, 2010-08-02 at 08:14 -0700, fachhoch wrote:
 but is it write to use web api in  my service  classes  ?
 My job is in service  layer as its a thread and web has nothing to do with ,
 now I have to call  web api (cometd api )  inside my service classes is 
 this write ?
 



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



Re: using cometd with threads

2010-08-02 Thread fachhoch

Please suggest me how to get   Bayeux service  in service layer , right now I
have in subclass of org.apache.wicket.protocol.http.Application  


-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/using-cometd-with-threads-tp2310323p2310715.html
Sent from the Wicket - User 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



Encrypt Form Fields Using JS

2010-08-02 Thread MZemeck
Problem: Encrypt sensitive form fields (ie ssn) on client (javascript)

Solution:  Create behavior which fires javascript to hash field value and 
replace original value (###-##-)

This sounds simple enough, but since the length of the hashed string will 
be considerably longer than the original string, validations on this field 
(ssn must be nine digits) will fail.

I've considered placing the hashed value into a hidden field, but then the 
unencrypted value will be posted and the hashing accomplishes nothing.  If 
I clear out the original value I lose server-side validations.  Anyone 
have any ideas of the best way to accomplish this?



Notice: This communication, including any attachments, is intended solely 
for the use of the individual or entity to which it is addressed. This 
communication may contain information that is protected from disclosure 
under State and/or Federal law. Please notify the sender immediately if 
you have received this communication in error and delete this email from 
your system. If you are not the intended recipient, you are requested not 
to disclose, copy, distribute or take any action in reliance on the 
contents of this information.

Re: Encrypt Form Fields Using JS

2010-08-02 Thread Craig McIlwee
Why not use a password field to keep the value hidden and SSL to make sure 
there are no man in the middle attacks.  Seems like you are making it too hard?

- Original Message -
From: mzem...@osc.state.ny.us
To:
users@wicket.apache.org
Sent: Mon, 02 Aug 2010 15:00:55 -0400
Subject:
Encrypt Form Fields Using JS


 Problem: Encrypt sensitive form fields (ie ssn) on client (javascript)
 
 Solution:  Create behavior which fires javascript to hash field value and 
 replace original value (###-##-)
 
 This sounds simple enough, but since the length of the hashed string will 
 be considerably longer than the original string, validations on this field 
 (ssn must be nine digits) will fail.
 
 I've considered placing the hashed value into a hidden field, but then the 
 unencrypted value will be posted and the hashing accomplishes nothing.  If 
 I clear out the original value I lose server-side validations.  Anyone 
 have any ideas of the best way to accomplish this?
 
 
 
 Notice: This communication, including any attachments, is intended solely 
 for the use of the individual or entity to which it is addressed. This 
 communication may contain information that is protected from disclosure 
 under State and/or Federal law. Please notify the sender immediately if 
 you have received this communication in error and delete this email from 
 your system. If you are not the intended recipient, you are requested not 
 to disclose, copy, distribute or take any action in reliance on the 
 contents of this information.

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



Re: Encrypt Form Fields Using JS

2010-08-02 Thread MZemeck
I totally agree, seems like double-duty that accomplishes very little, and 
actually adds overhead.  But this is another debate and the feature has 
been requested and must be implemented as I described...




Craig McIlwee craig.mcil...@openroadsconsulting.com 
08/02/2010 03:06 PM
Please respond to
users@wicket.apache.org


To
users@wicket.apache.org
cc

Subject
Re: Encrypt Form Fields Using JS






Why not use a password field to keep the value hidden and SSL to make sure 
there are no man in the middle attacks.  Seems like you are making it too 
hard?

- Original Message -
From: mzem...@osc.state.ny.us
To:
users@wicket.apache.org
Sent: Mon, 02 Aug 2010 15:00:55 -0400
Subject:
Encrypt Form Fields Using JS


 Problem: Encrypt sensitive form fields (ie ssn) on client (javascript)
 
 Solution:  Create behavior which fires javascript to hash field value 
and 
 replace original value (###-##-)
 
 This sounds simple enough, but since the length of the hashed string 
will 
 be considerably longer than the original string, validations on this 
field 
 (ssn must be nine digits) will fail.
 
 I've considered placing the hashed value into a hidden field, but then 
the 
 unencrypted value will be posted and the hashing accomplishes nothing. 
If 
 I clear out the original value I lose server-side validations.  Anyone 
 have any ideas of the best way to accomplish this?
 
 
 
 Notice: This communication, including any attachments, is intended 
solely 
 for the use of the individual or entity to which it is addressed. This 
 communication may contain information that is protected from disclosure 
 under State and/or Federal law. Please notify the sender immediately if 
 you have received this communication in error and delete this email from 

 your system. If you are not the intended recipient, you are requested 
not 
 to disclose, copy, distribute or take any action in reliance on the 
 contents of this information.

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






Notice: This communication, including any attachments, is intended solely 
for the use of the individual or entity to which it is addressed. This 
communication may contain information that is protected from disclosure 
under State and/or Federal law. Please notify the sender immediately if 
you have received this communication in error and delete this email from 
your system. If you are not the intended recipient, you are requested not 
to disclose, copy, distribute or take any action in reliance on the 
contents of this information.

Re: Encrypt Form Fields Using JS

2010-08-02 Thread Igor Vaynberg
override getinputasarray() on the field and decrypt it there, that way
wicket sees the decrypted value

-igor

On Mon, Aug 2, 2010 at 12:14 PM,  mzem...@osc.state.ny.us wrote:
 I totally agree, seems like double-duty that accomplishes very little, and
 actually adds overhead.  But this is another debate and the feature has
 been requested and must be implemented as I described...




 Craig McIlwee craig.mcil...@openroadsconsulting.com
 08/02/2010 03:06 PM
 Please respond to
 users@wicket.apache.org


 To
 users@wicket.apache.org
 cc

 Subject
 Re: Encrypt Form Fields Using JS






 Why not use a password field to keep the value hidden and SSL to make sure
 there are no man in the middle attacks.  Seems like you are making it too
 hard?

 - Original Message -
 From: mzem...@osc.state.ny.us
 To:
 users@wicket.apache.org
 Sent: Mon, 02 Aug 2010 15:00:55 -0400
 Subject:
 Encrypt Form Fields Using JS


 Problem: Encrypt sensitive form fields (ie ssn) on client (javascript)

 Solution:  Create behavior which fires javascript to hash field value
 and
 replace original value (###-##-)

 This sounds simple enough, but since the length of the hashed string
 will
 be considerably longer than the original string, validations on this
 field
 (ssn must be nine digits) will fail.

 I've considered placing the hashed value into a hidden field, but then
 the
 unencrypted value will be posted and the hashing accomplishes nothing.
 If
 I clear out the original value I lose server-side validations.  Anyone
 have any ideas of the best way to accomplish this?



 Notice: This communication, including any attachments, is intended
 solely
 for the use of the individual or entity to which it is addressed. This
 communication may contain information that is protected from disclosure
 under State and/or Federal law. Please notify the sender immediately if
 you have received this communication in error and delete this email from

 your system. If you are not the intended recipient, you are requested
 not
 to disclose, copy, distribute or take any action in reliance on the
 contents of this information.

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






 Notice: This communication, including any attachments, is intended solely
 for the use of the individual or entity to which it is addressed. This
 communication may contain information that is protected from disclosure
 under State and/or Federal law. Please notify the sender immediately if
 you have received this communication in error and delete this email from
 your system. If you are not the intended recipient, you are requested not
 to disclose, copy, distribute or take any action in reliance on the
 contents of this information.

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



Re: How to access div on wicket modal dialog

2010-08-02 Thread Igor Vaynberg
if you open a page inside modal then the markup is in a different
window so you have to make sure your jquery script executes in the
right window.

if you are using a panel and the markup is rendered in the same window
it means your script is probably running too early.

-igor

On Mon, Aug 2, 2010 at 11:00 AM, zoran jeremy...@gmail.com wrote:

 Hi,

 I'm using a wicket modal dialog with the panel that contains a div container
 like
 div id=slider/div

 I want to access it from jQuery to create a jQuery UI slider like
 $(#slider).slider();

 For some reason, this doesn't work. Is there some reason related to wicket
 that prevents this to find div container using its id, because the same
 thing works fine when I use jQuery modal dialog instead of wicket modal
 dialog?

 Zoran
 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/How-to-access-div-on-wicket-modal-dialog-tp2310678p2310678.html
 Sent from the Wicket - User 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



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



Re: Encrypt Form Fields Using JS

2010-08-02 Thread MZemeck
Thanks for the reply, that would work however per our business rules the 
encryption must be one-way and will not be decrypted...




Igor Vaynberg igor.vaynb...@gmail.com 
08/02/2010 03:23 PM
Please respond to
users@wicket.apache.org


To
users@wicket.apache.org
cc

Subject
Re: Encrypt Form Fields Using JS






override getinputasarray() on the field and decrypt it there, that way
wicket sees the decrypted value

-igor

On Mon, Aug 2, 2010 at 12:14 PM,  mzem...@osc.state.ny.us wrote:
 I totally agree, seems like double-duty that accomplishes very little, 
and
 actually adds overhead.  But this is another debate and the feature has
 been requested and must be implemented as I described...




 Craig McIlwee craig.mcil...@openroadsconsulting.com
 08/02/2010 03:06 PM
 Please respond to
 users@wicket.apache.org


 To
 users@wicket.apache.org
 cc

 Subject
 Re: Encrypt Form Fields Using JS






 Why not use a password field to keep the value hidden and SSL to make 
sure
 there are no man in the middle attacks.  Seems like you are making it 
too
 hard?

 - Original Message -
 From: mzem...@osc.state.ny.us
 To:
 users@wicket.apache.org
 Sent: Mon, 02 Aug 2010 15:00:55 -0400
 Subject:
 Encrypt Form Fields Using JS


 Problem: Encrypt sensitive form fields (ie ssn) on client (javascript)

 Solution:  Create behavior which fires javascript to hash field value
 and
 replace original value (###-##-)

 This sounds simple enough, but since the length of the hashed string
 will
 be considerably longer than the original string, validations on this
 field
 (ssn must be nine digits) will fail.

 I've considered placing the hashed value into a hidden field, but then
 the
 unencrypted value will be posted and the hashing accomplishes nothing.
 If
 I clear out the original value I lose server-side validations.  Anyone
 have any ideas of the best way to accomplish this?



 Notice: This communication, including any attachments, is intended
 solely
 for the use of the individual or entity to which it is addressed. This
 communication may contain information that is protected from disclosure
 under State and/or Federal law. Please notify the sender immediately if
 you have received this communication in error and delete this email 
from

 your system. If you are not the intended recipient, you are requested
 not
 to disclose, copy, distribute or take any action in reliance on the
 contents of this information.

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






 Notice: This communication, including any attachments, is intended 
solely
 for the use of the individual or entity to which it is addressed. This
 communication may contain information that is protected from disclosure
 under State and/or Federal law. Please notify the sender immediately if
 you have received this communication in error and delete this email from
 your system. If you are not the intended recipient, you are requested 
not
 to disclose, copy, distribute or take any action in reliance on the
 contents of this information.

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






Notice: This communication, including any attachments, is intended solely 
for the use of the individual or entity to which it is addressed. This 
communication may contain information that is protected from disclosure 
under State and/or Federal law. Please notify the sender immediately if 
you have received this communication in error and delete this email from 
your system. If you are not the intended recipient, you are requested not 
to disclose, copy, distribute or take any action in reliance on the 
contents of this information.

Re: Error Hypothesis...

2010-08-02 Thread Martijn Dashorst
In Wicket Extensions we have an ajax upload field iirc. That should
not block the pagemap...

Martijn

On Mon, Aug 2, 2010 at 4:35 PM, Johan Compagner jcompag...@gmail.com wrote:
 maybe do the actual upload through and iframe or something that has
 its own pagemap?

 Or block the ui in the browser as long as the upload is in progress
 (but then user can still do F5, but they should know that they should
 wait for it)

 You can also for example use a flash uploader to a servlet that has
 nice progress indicator (like gmail)


 johan

 On Mon, Aug 2, 2010 at 16:29, James Carman ja...@carmanconsulting.com wrote:
 So, is there anything I can do to fix the problem (aside from hitting the
 user on the head and telling them not to do that again)?  They keep getting
 the application error screen when they do that.

 On Mon, Aug 2, 2010 at 10:27 AM, Johan Compagner jcompag...@gmail.comwrote:

 yes that is most likely the case.



 On Mon, Aug 2, 2010 at 16:17, James Carman ja...@carmanconsulting.com
 wrote:
  I have a theory about what is causing this issue.  Just wanted to run it
 by
  you guys.  In my log files, I first see this:
 
  org.apache.wicket.protocol.http.request.InvalidUrlException:
  org.apache.wicket.WicketRuntimeException: After 1 minute the Pagemap null
 is
  still locked by: Thread[http-10080-Processor23,5,main], giv
  ing up trying to get the page for path: 3:projects
     at
 
 org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:262)
     at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310)
     at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
     at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
     at
  org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
     at
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
     at
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
     at
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
 
 
  Then, a bit lower in the file, I see:
 
  org.apache.wicket.util.upload.FileUploadBase$IOFileUploadException:
  Processing of multipart/form-data request failed. Connection reset
     at
 
 org.apache.wicket.util.upload.FileUploadBase.parseRequest(FileUploadBase.java:386)
     at
 
 org.apache.wicket.util.upload.ServletFileUpload.parseRequest(ServletFileUpload.java:129)
     at
 
 org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:155)
     at
 
 org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:83)
     at
 
 org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWebRequest(ServletWebRequest.java:500)
     at
  org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1668)
     at
  org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:862)
     at
 
 org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:135)
     at
 
 org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
     at
 
 org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:286)
     at
 
 org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119)
     at
 
 org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
     at
 
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
     at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
     at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
     at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
     at
  org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
     at
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
 
 
  My theory is that our users are beginning the file upload, but hitting F5
  (reload) or something before letting the file upload complete.  Does that
  sound feasible?  It's hard for me to test this because I'm running
 locally
  and the file upload happens almost instantaneously.  The user that is
  causing this to happen is in Europe, so I'm thinking the file upload
 (only
  8.5 MB) might take a bit longer and they are getting impatient.  If this
 can
  happen, is there something Wicket can do to not lock up the pagemap in
 this
  case, because there's nothing really I can do to block the user from
 hitting
  F5?
 

 -
 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 

Re: Encrypt Form Fields Using JS

2010-08-02 Thread Igor Vaynberg
so how do you expect to validate on server side???

-igor

On Mon, Aug 2, 2010 at 12:29 PM,  mzem...@osc.state.ny.us wrote:
 Thanks for the reply, that would work however per our business rules the
 encryption must be one-way and will not be decrypted...




 Igor Vaynberg igor.vaynb...@gmail.com
 08/02/2010 03:23 PM
 Please respond to
 users@wicket.apache.org


 To
 users@wicket.apache.org
 cc

 Subject
 Re: Encrypt Form Fields Using JS






 override getinputasarray() on the field and decrypt it there, that way
 wicket sees the decrypted value

 -igor

 On Mon, Aug 2, 2010 at 12:14 PM,  mzem...@osc.state.ny.us wrote:
 I totally agree, seems like double-duty that accomplishes very little,
 and
 actually adds overhead.  But this is another debate and the feature has
 been requested and must be implemented as I described...




 Craig McIlwee craig.mcil...@openroadsconsulting.com
 08/02/2010 03:06 PM
 Please respond to
 users@wicket.apache.org


 To
 users@wicket.apache.org
 cc

 Subject
 Re: Encrypt Form Fields Using JS






 Why not use a password field to keep the value hidden and SSL to make
 sure
 there are no man in the middle attacks.  Seems like you are making it
 too
 hard?

 - Original Message -
 From: mzem...@osc.state.ny.us
 To:
 users@wicket.apache.org
 Sent: Mon, 02 Aug 2010 15:00:55 -0400
 Subject:
 Encrypt Form Fields Using JS


 Problem: Encrypt sensitive form fields (ie ssn) on client (javascript)

 Solution:  Create behavior which fires javascript to hash field value
 and
 replace original value (###-##-)

 This sounds simple enough, but since the length of the hashed string
 will
 be considerably longer than the original string, validations on this
 field
 (ssn must be nine digits) will fail.

 I've considered placing the hashed value into a hidden field, but then
 the
 unencrypted value will be posted and the hashing accomplishes nothing.
 If
 I clear out the original value I lose server-side validations.  Anyone
 have any ideas of the best way to accomplish this?



 Notice: This communication, including any attachments, is intended
 solely
 for the use of the individual or entity to which it is addressed. This
 communication may contain information that is protected from disclosure
 under State and/or Federal law. Please notify the sender immediately if
 you have received this communication in error and delete this email
 from

 your system. If you are not the intended recipient, you are requested
 not
 to disclose, copy, distribute or take any action in reliance on the
 contents of this information.

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






 Notice: This communication, including any attachments, is intended
 solely
 for the use of the individual or entity to which it is addressed. This
 communication may contain information that is protected from disclosure
 under State and/or Federal law. Please notify the sender immediately if
 you have received this communication in error and delete this email from
 your system. If you are not the intended recipient, you are requested
 not
 to disclose, copy, distribute or take any action in reliance on the
 contents of this information.

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






 Notice: This communication, including any attachments, is intended solely
 for the use of the individual or entity to which it is addressed. This
 communication may contain information that is protected from disclosure
 under State and/or Federal law. Please notify the sender immediately if
 you have received this communication in error and delete this email from
 your system. If you are not the intended recipient, you are requested not
 to disclose, copy, distribute or take any action in reliance on the
 contents of this information.

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



Re: How to access div on wicket modal dialog

2010-08-02 Thread zoran

Igor, 

You save my life :)

if you are using a panel and the markup is rendered in the same window
it means your script is probably running too early. 

That is exactly what was the problem. 

I added 
response.renderOnDomReadyJavascript(js);

In AbstractBehavior RenderHead method, and everything works like it should
work.

Thanks,
Zoran
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/How-to-access-div-on-wicket-modal-dialog-tp2310678p2310845.html
Sent from the Wicket - User 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: Encrypt Form Fields Using JS

2010-08-02 Thread MZemeck
The only thing I've come up with to meet all the requirements is to set 
the hashed value to a hidden field, and replace the original value 
(123-45-6789) with all nines (999-99-).  This would allow the 
validator to pass but puts a requirement on the js to validate the 
original value, ie it should not replace a 'Q' with a '9'




Igor Vaynberg igor.vaynb...@gmail.com 
08/02/2010 03:46 PM
Please respond to
users@wicket.apache.org


To
users@wicket.apache.org
cc

Subject
Re: Encrypt Form Fields Using JS






so how do you expect to validate on server side???

-igor

On Mon, Aug 2, 2010 at 12:29 PM,  mzem...@osc.state.ny.us wrote:
 Thanks for the reply, that would work however per our business rules the
 encryption must be one-way and will not be decrypted...




 Igor Vaynberg igor.vaynb...@gmail.com
 08/02/2010 03:23 PM
 Please respond to
 users@wicket.apache.org


 To
 users@wicket.apache.org
 cc

 Subject
 Re: Encrypt Form Fields Using JS






 override getinputasarray() on the field and decrypt it there, that way
 wicket sees the decrypted value

 -igor

 On Mon, Aug 2, 2010 at 12:14 PM,  mzem...@osc.state.ny.us wrote:
 I totally agree, seems like double-duty that accomplishes very little,
 and
 actually adds overhead.  But this is another debate and the feature has
 been requested and must be implemented as I described...




 Craig McIlwee craig.mcil...@openroadsconsulting.com
 08/02/2010 03:06 PM
 Please respond to
 users@wicket.apache.org


 To
 users@wicket.apache.org
 cc

 Subject
 Re: Encrypt Form Fields Using JS






 Why not use a password field to keep the value hidden and SSL to make
 sure
 there are no man in the middle attacks.  Seems like you are making it
 too
 hard?

 - Original Message -
 From: mzem...@osc.state.ny.us
 To:
 users@wicket.apache.org
 Sent: Mon, 02 Aug 2010 15:00:55 -0400
 Subject:
 Encrypt Form Fields Using JS


 Problem: Encrypt sensitive form fields (ie ssn) on client (javascript)

 Solution:  Create behavior which fires javascript to hash field value
 and
 replace original value (###-##-)

 This sounds simple enough, but since the length of the hashed string
 will
 be considerably longer than the original string, validations on this
 field
 (ssn must be nine digits) will fail.

 I've considered placing the hashed value into a hidden field, but then
 the
 unencrypted value will be posted and the hashing accomplishes nothing.
 If
 I clear out the original value I lose server-side validations.  Anyone
 have any ideas of the best way to accomplish this?



 Notice: This communication, including any attachments, is intended
 solely
 for the use of the individual or entity to which it is addressed. This
 communication may contain information that is protected from 
disclosure
 under State and/or Federal law. Please notify the sender immediately 
if
 you have received this communication in error and delete this email
 from

 your system. If you are not the intended recipient, you are requested
 not
 to disclose, copy, distribute or take any action in reliance on the
 contents of this information.

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






 Notice: This communication, including any attachments, is intended
 solely
 for the use of the individual or entity to which it is addressed. This
 communication may contain information that is protected from disclosure
 under State and/or Federal law. Please notify the sender immediately if
 you have received this communication in error and delete this email 
from
 your system. If you are not the intended recipient, you are requested
 not
 to disclose, copy, distribute or take any action in reliance on the
 contents of this information.

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






 Notice: This communication, including any attachments, is intended 
solely
 for the use of the individual or entity to which it is addressed. This
 communication may contain information that is protected from disclosure
 under State and/or Federal law. Please notify the sender immediately if
 you have received this communication in error and delete this email from
 your system. If you are not the intended recipient, you are requested 
not
 to disclose, copy, distribute or take any action in reliance on the
 contents of this information.

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






Notice: This communication, including any attachments, is intended solely 
for the use of the individual or entity to which it is addressed. This 
communication may contain information that is protected 

Re: How to access div on wicket modal dialog

2010-08-02 Thread Igor Vaynberg
thats what i do...save lives :)

-igor

On Mon, Aug 2, 2010 at 12:50 PM, zoran jeremy...@gmail.com wrote:

 Igor,

 You save my life :)

if you are using a panel and the markup is rendered in the same window
it means your script is probably running too early.

 That is exactly what was the problem.

 I added
 response.renderOnDomReadyJavascript(js);

 In AbstractBehavior RenderHead method, and everything works like it should
 work.

 Thanks,
 Zoran
 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/How-to-access-div-on-wicket-modal-dialog-tp2310678p2310845.html
 Sent from the Wicket - User 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



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



using breadcrumbs in Wicket 1.4.9

2010-08-02 Thread Lawrence Sewell
My first Wicket application uses Wicket 1.4.9 and breadcrumbs where I  
need to go from:


panel A / panel B / panel C

to:

panel A / panel B / panel D

by selecting a submit button on a form in panel C, e.g. replace panel  
C (after processing the form) with panel D as the active crumb.


Is this possible?

I have only been able to do the following:

panel A / panel B / panel C / panel D

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



Re: Encrypt Form Fields Using JS

2010-08-02 Thread James Carman
Then it's not encryption.  Encrypted data should be readable to those who
have the key.

On Mon, Aug 2, 2010 at 3:29 PM, mzem...@osc.state.ny.us wrote:

 Thanks for the reply, that would work however per our business rules the
 encryption must be one-way and will not be decrypted...




 Igor Vaynberg igor.vaynb...@gmail.com
 08/02/2010 03:23 PM
 Please respond to
 users@wicket.apache.org


 To
 users@wicket.apache.org
 cc

 Subject
 Re: Encrypt Form Fields Using JS






 override getinputasarray() on the field and decrypt it there, that way
 wicket sees the decrypted value

 -igor

 On Mon, Aug 2, 2010 at 12:14 PM,  mzem...@osc.state.ny.us wrote:
  I totally agree, seems like double-duty that accomplishes very little,
 and
  actually adds overhead.  But this is another debate and the feature has
  been requested and must be implemented as I described...
 
 
 
 
  Craig McIlwee craig.mcil...@openroadsconsulting.com
  08/02/2010 03:06 PM
  Please respond to
  users@wicket.apache.org
 
 
  To
  users@wicket.apache.org
  cc
 
  Subject
  Re: Encrypt Form Fields Using JS
 
 
 
 
 
 
  Why not use a password field to keep the value hidden and SSL to make
 sure
  there are no man in the middle attacks.  Seems like you are making it
 too
  hard?
 
  - Original Message -
  From: mzem...@osc.state.ny.us
  To:
  users@wicket.apache.org
  Sent: Mon, 02 Aug 2010 15:00:55 -0400
  Subject:
  Encrypt Form Fields Using JS
 
 
  Problem: Encrypt sensitive form fields (ie ssn) on client (javascript)
 
  Solution:  Create behavior which fires javascript to hash field value
  and
  replace original value (###-##-)
 
  This sounds simple enough, but since the length of the hashed string
  will
  be considerably longer than the original string, validations on this
  field
  (ssn must be nine digits) will fail.
 
  I've considered placing the hashed value into a hidden field, but then
  the
  unencrypted value will be posted and the hashing accomplishes nothing.
  If
  I clear out the original value I lose server-side validations.  Anyone
  have any ideas of the best way to accomplish this?
 
 
 
  Notice: This communication, including any attachments, is intended
  solely
  for the use of the individual or entity to which it is addressed. This
  communication may contain information that is protected from disclosure
  under State and/or Federal law. Please notify the sender immediately if
  you have received this communication in error and delete this email
 from
 
  your system. If you are not the intended recipient, you are requested
  not
  to disclose, copy, distribute or take any action in reliance on the
  contents of this information.
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 
 
  Notice: This communication, including any attachments, is intended
 solely
  for the use of the individual or entity to which it is addressed. This
  communication may contain information that is protected from disclosure
  under State and/or Federal law. Please notify the sender immediately if
  you have received this communication in error and delete this email from
  your system. If you are not the intended recipient, you are requested
 not
  to disclose, copy, distribute or take any action in reliance on the
  contents of this information.

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






 Notice: This communication, including any attachments, is intended solely
 for the use of the individual or entity to which it is addressed. This
 communication may contain information that is protected from disclosure
 under State and/or Federal law. Please notify the sender immediately if
 you have received this communication in error and delete this email from
 your system. If you are not the intended recipient, you are requested not
 to disclose, copy, distribute or take any action in reliance on the
 contents of this information.



Re: using cometd with threads

2010-08-02 Thread Rodolfo Hansen
You can get it from the ServletContext:

getServletContext().getAttribute(BayeuxServer.ATTRIBUTE);


On Mon, 2010-08-02 at 11:18 -0700, fachhoch wrote:
 Please suggest me how to get   Bayeux service  in service layer , right now I
 have in subclass of org.apache.wicket.protocol.http.Application  
 
 



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



KonaKart shopping cart integration

2010-08-02 Thread Steve Coughlan
I've been looking for a shopping cart solution that I can properly 
integrate with wicket.  There's been a few threads on this list where 
people have indicated they were building one but as far as I know 
nothing has ever eventuated.


I don't really want to build to whole engine from scratch so I've been 
looking around and come across konakart.  It's partially open source.  
Meaning the engine itself is closed but it has a complete (and well 
documented) integration layer.  I think this would be a good solution 
because all the backend functionality is there along with a nice admin 
panel.


The interface is either Java or SOAP (one line of code to switch between 
the two) which means you can run your cart engine on another server if 
you want.


So what I'm proposing is build a set of front-end wicket components.  
I'd prefer a fully open source solution but in the free java space this 
seems to be the easiest solution I can find.  I really don't have time 
to build an engine from the ground up.


So before I get going I just wanted to bounce it off the community and 
see if anyone can think of a better solution?


I only just come across brix and I'm still trying to get my head around 
it.  Any comments on whether  I should make this brix centric or pure 
wicket?


p.s. If I do build these components then I will release them as LGPL...

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