Re: KonaKart shopping cart integration

[Per Lundholm]

When you wrote "shopping cart", I assumed it was only the widget which
presents what the customer bought and some mechanism for keeping that
in the session. KonaKart seems to be a lot more than that.

/Per

On Tue, Aug 3, 2010 at 2:35 AM, Steve Coughlan
 wrote:
> 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
>
>

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

KonaKart shopping cart integration

[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

Proposal: HierarchicConverterLocator, an IConverterLocator that adheres to the class hierarchy

[spam2...@meeque.de]

Hello Folks,


Recently I came across a small shortcoming (IMHO) in the way Wicket's
default IConverterLocator implementation handles inheritance. It seems
that the ConverterLocator only returns an IConverter, if one is
registered for the exact given Class. If such an IConverter is not
present, it returns null. 

However, any IConverter that is capable of converting a superclass of
the given Class, might also be suitable. For instance, if an IConverter
for Class ArrayList is requested, a more generic IConverter for Class
List might work as well.

It might be handy to register a generic IConverter for a supertype of
the class hierarchy and let it handle conversion for all subclasses.
This would also allow to register IConverters for abstract classes and
interfaces. And it might solve certain problems people have reported
about converting CGLib-enhanced proxy objects, like the ones often
returned by Hibernate.


In my Wicket app, I use a custom HierarchicConverterLocator, that
searches for IConverters using the superclass hierarchy. It is a
quick-and-dirty implementation, without any performance optimizations.
But it works very well for me!

If anyone thinks this might be useful, I can do a little more effort and
maybe contribute it. You can find (most of) the code below...


Regards,
Michael Riedel



/**
 *
 */
public class HierarchicConverterLocator implements IConverterLocator
{   
/** */
private ConverterLocator converterLocator = 
new ConverterLocator();

/**
 * 
 */
@Override
public IConverter getConverter( Class type )
{
final IConverter converter = getConverterOrNull( type );
if( converter == null )
{
return converterLocator.getConverter( type );
}
return converter;
}

/**
 * 
 */
private IConverter getConverterOrNull( Class type )
{
if( type == null )
{
return null;
}

final IConverter converter = get( type );
if( converter == null )
{
final List> superTypes = 
new LinkedList>();
superTypes.add( type.getSuperclass() );
superTypes.addAll( 
Arrays.asList( type.getInterfaces() ) 
);

for( Class superType : superTypes )
{
final IConverter superTypeConverter = 
getConverterOrNull( superType );
if ( superTypeConverter != null )
{
return superTypeConverter;
}
}
}
return converter;
}

/**
 * 
 */
public IConverter get( final Class type )
{
return converterLocator.get( type );
}

/**
 * 
 */
public IConverter set( final Class c, 
final IConverter converter )
{
return converterLocator.set( c, converter );
}

/**
 * 
 */
public IConverter remove(Class c)
{
return converterLocator.remove( c );
}
}


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

Re: using cometd with threads

[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

Re: Encrypt Form Fields Using JS

[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,  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 
> 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,   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" 
> > 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.
>

using breadcrumbs in Wicket 1.4.9

[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: How to access div on wicket modal dialog

[Igor Vaynberg]

thats what i do...save lives :)

-igor

On Mon, Aug 2, 2010 at 12:50 PM, zoran  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

Re: Encrypt Form Fields Using JS

[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  
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,   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 
> 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,   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" 
>> 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 
fo

Re: How to access div on wicket modal dialog

[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

[Igor Vaynberg]

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

-igor

On Mon, Aug 2, 2010 at 12:29 PM,   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 
> 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,   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" 
>> 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: Error Hypothesis...

[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  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  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 wrote:
>>
>>> yes that is most likely the case.
>>>
>>>
>>>
>>> On Mon, Aug 2, 2010 at 16:17, James Carman 
>>> 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.(MultipartServletWebRequest.java:155)
>>> >    at
>>> >
>>> org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.(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: Encrypt Form Fields Using JS

[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  
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,   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" 
> 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: How to access div on wicket modal dialog

[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  wrote:
>
> Hi,
>
> I'm using a wicket modal dialog with the panel that contains a div container
> like
> 
>
> 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

[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,   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" 
> 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: Encrypt Form Fields Using JS

[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"  
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

[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

Encrypt Form Fields Using JS

[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: using cometd with threads

[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

Re: using cometd with threads

[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

How to access div on wicket modal dialog

[zoran]

Hi,

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


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: WicketTester and Palette component

[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

Re: using cometd with threads

[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: using cometd with threads

[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: Form Component Border - on Submit

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

[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 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 
> 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  >wrote:
> >
> >> yes that is most likely the case.
> >>
> >>
> >>
> >> On Mon, Aug 2, 2010 at 16:17, James Carman 
> >> 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.(MultipartServletWebRequest.java:155)
> >> >at
> >> >
> >>
> org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.(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 getti

Re: Error Hypothesis...

[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  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 wrote:
>
>> yes that is most likely the case.
>>
>>
>>
>> On Mon, Aug 2, 2010 at 16:17, James Carman 
>> 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.(MultipartServletWebRequest.java:155)
>> >    at
>> >
>> org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.(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.

Re: Error Hypothesis...

[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 wrote:

> yes that is most likely the case.
>
>
>
> On Mon, Aug 2, 2010 at 16:17, James Carman 
> 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.(MultipartServletWebRequest.java:155)
> >at
> >
> org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.(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...

[Johan Compagner]

yes that is most likely the case.



On Mon, Aug 2, 2010 at 16:17, James Carman  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.(MultipartServletWebRequest.java:155)
>    at
> org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.(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

Error Hypothesis...

[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.(MultipartServletWebRequest.java:155)
at
org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.(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?

using cometd with threads

[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

Re: How to Update contents of a child component?

[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  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
>
>

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

[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

SV: member variables, thread safety

[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

member variables, thread safety

[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

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

[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.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]>
>  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]
> >> For additional commands, e-mail: [hidden 
> >> email]
> >>
> >>
> >>
> > -
> > To unsubscribe, e-mail: [hidden 
> > email]
> > For additional commands, e-mail: [hidden 
> > email]
> >
> >
> 1.4.9
>
> -
> To unsubscribe, e-mail: [hidden 
> email]
> For additional commands, e-mail: [hidden 
> email]
>
>
>
> --
>  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.com
> To unsubscribe from Wicket - User, click 
> here.
>
>
>

-- 
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.

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

[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önblom  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