I need to read more about this, but I am interested to know if there are any
advantages to storing the token in a cookie for validation rather than putting
it into the session. I suppose if statelessness is required then it is
necessary. One advantage to storing it in session is that it does hel
One more suggestion is to declare the filter so that it is invoked when
request dispatcher methods are called:
WicketSessionFilter
*.do
REQUEST
INCLUDE
I'm not sure if that is what is happening in this situation, but it
might be worth a shot.
-Original Message-
From: James Perr
hink of at this point.
Aye
On Fri, Jul 25, 2008 at 2:25 PM, Zappaterrini, Larry <
[EMAIL PROTECTED]> wrote:
> I've had the same problem using java.text.DateFormat to validate the
> same pattern you are using. The solution I use is to check the string
> length to ensure that it is 1
I've had the same problem using java.text.DateFormat to validate the
same pattern you are using. The solution I use is to check the string
length to ensure that it is 10 characters. It might be nice if
PatternDateConverter were to be enhanced to have a required length value
to enforce this in an en
Regarding IModel and IModel, you could create subclasses to
represent them and then you can have two different constructors.
class GroupModel extends IModel
class UserModel extends IModel
then
Constructor(GroupModel model)
Constructor(UserModel model)
Will work.
-Original Message-
Fro
Should UserDAO in the XML be userDAO?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 23, 2008 3:14 PM
To: users@wicket.apache.org
Subject: Re: Spring injection not working
On Jul 23, 2008, at 12:10 PM, James Carman wrote:
> Have you tried usin
Anonymous inner classes are nice for their brevity but they are not
required. You can declare those as concrete classes. I'm not too sure
about Groovy but you should be able to put them in the same file.
-Original Message-
From: JulianS [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 22, 20
Your reason is a special instance of a much more general reason. Web
applications are much easier to deal with from a deployment perspective than
desktop applications. Also, there are firewall and security issues surrounding
access to central data repositories that web applications handle nicely
Well in a production situation there would be one host name used and
failover would just change which server the requests to that host name
get routed to. In that scenario the same cookies would be used so no
problem.
You should be able to use some trickery in your hosts file to mimic
this. Add a
Are you sure that the same JSESSIONID cookie is being sent to both
servers? Cookies only get sent when the host value matches the host in
the URL. Might that be your issue?
-Original Message-
From: Artem D. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 25, 2008 9:18 AM
To: users@wicke
I'm getting the same thing.
-Original Message-
From: Martin Funk [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 24, 2008 10:42 AM
To: users@wicket.apache.org
Subject: Re: generics
> basically we feel this is a much cleaner way then what is 1.4m2. this
> is a call for confirmation/discuss
zable.
-igor
On Mon, Jun 23, 2008 at 10:14 AM, Zappaterrini, Larry
<[EMAIL PROTECTED]> wrote:
> Say for instance the session contains a resource such as a database
> connection or a thread (Eyal's original question) that needs to be
freed
> when the session is invalidated. Is there (o
cket.apache.org
Subject: Re: Session end method
what resources are those? like i said before, by the time you get
notification that the session is expired you can no longer access
attributes within session.
-igor
On Mon, Jun 23, 2008 at 8:29 AM, Zappaterrini, Larry
<[EMAIL PROTECTED]> wrote:
&
read the javadoc.
-igor
On Mon, Jun 23, 2008 at 6:29 AM, Zappaterrini, Larry
<[EMAIL PROTECTED]> wrote:
> Ah, I see that now. I didn't dig deep enough. When I first started
> working with Wicket sessions I was assuming (bad I know!) that
> Session.invalidate would be called
23 AM
To: users@wicket.apache.org
Subject: Re: Session end method
Wicket doea that for you, unbind is called when session is terminarted
by the container
On 6/20/08, Zappaterrini, Larry <[EMAIL PROTECTED]> wrote:
> Assuming this is backed by an HttpSession, wouldn't you also have to
My guess would be no, since the object hierarchy of a page is a
fundamental aspect of Wicket. I don't think that instances of Wicket
Component objects are meant to be thread-safe and shared between
different Component trees. There is all kinds of mutable data in
Component that is not meant to be sh
Assuming this is backed by an HttpSession, wouldn't you also have to
register an implementation of HttpSessionListener via web.xml to handle
the situation where the HttpSession times out? Correct me if I'm wrong,
but in that instance, onUnbind will not be called and the Thread would
never be stoppe
Could I dig this one back up then ;)
http://www.nabble.com/Creating-Custom-Form-Components-td16159841.html#a1
6159841
Basically my request was to remove final from
FormComponent.add(IValidator...) to aid in creating custom form
component subclasses based on precedent with Component.add(IBehavior.
It is not about assuming anyone is an idiot. It is about preserving
maintainability and allowing an API to evolve without breaking client
code. The best approach is to mark members as final unless there is a
compelling reason not to. Final is a safeguard for APIs to know what
behavior is guaranteed
org
Subject: Re: (Class>) casting troubles
Zappaterrini, Larry wrote:
> Sebastiaan,
>
> Point 1 is a good one. I haven't puzzled that through completely. Upon
> initial inspection it seems that it is just the compiler being pedantic
> about a scenario that wouldn't
int 2, but what is wrong with
Class clazz = Foo.class?
Cheers,
Larry
-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 07, 2008 3:57 AM
To: users@wicket.apache.org
Subject: Re: (Class>) casting troubles
Zappaterrini, Larry wrote:
> Sorry, I
[mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2008 4:16 PM
To: users@wicket.apache.org
Subject: Re: (Class>) casting troubles
Zappaterrini, Larry wrote:
> In the example you have detailed, RawBar is not a subtype of Bar
> since it extends the raw type Bar.
I guess it depends on the defi
In the example you have detailed, RawBar is not a subtype of Bar
since it extends the raw type Bar.
-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2008 11:31 AM
To: users@wicket.apache.org
Subject: Re: (Class>) casting troubles
ARgh, you alwa
This is my take on it:
http://www.nabble.com/RE%3A-%28Class%3C--extends-Page%3C-%3E%3E%29-casti
ng-troubles-p17370699.html
I feel it covers the topic pretty thoroughly but I am by no means an
expert on the matter.
-Original Message-
From: Martin Funk [mailto:[EMAIL PROTECTED]
Sent: Wed
The way the your web.xml is configured does not have the requests going to
JasperReportServlet getting filtered by WicketSessionFilter. Change the filter
mapping for WicketSessionFilter from /app/* to /report/* or /* and you should
see it work the way you want.
Is there any timeframe for the development of a version of
Wicket-Security that is compatible with Wicket 1.4? I know Wicket 1.4 is
still a moving target, but I am curious to know what the plan for
Wicket-Security is.
Thanks,
Larry
__
The information contained in this message is pro
I am currently using 1.4 M1 and here are my choices:
1) Generifying* Wicket
[X] Can best be done like currently in the 1.4 branch, where models
and components are both generified. I care most about the improved
static type checking generified models and components give Wicket.
2) How strongly
In Application.init add getMarkupSettings().setStripWicketTags(true);
-Original Message-
From: Lauri Lehtinen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 21, 2008 1:09 PM
To: users@wicket.apache.org
Subject: How to strip wicket tags from markup in development mode?
Hi -
Is there an e
I think that is only part of the problem in this instance. The other
part of the problem is that Base.class presents only runtime
information. There is no way to invoke Base.class to get
Class> in a manner similar to how you can invoke a generic
method. The type represented in the <> returned by a
I can't get the ternary statement you provided to compile correctly
using 1.4-M1. The error I get is:
The type AbstractChoice is not visible
Due to the fact that the common ancestor for ListMultipleChoice and
ListChoice is the inaccessible package protected object AbstractChoice.
This is
Are IpLookupPage.html and BasePage.html both in the same location as
IpLookupPage.class and BasePage.class respectively and on the testing
classpath?
-Original Message-
From: AlexTM [mailto:[EMAIL PROTECTED]
Sent: Friday, May 09, 2008 2:41 AM
To: users@wicket.apache.org
Subject: MarkupNot
Double click on the Tomcat server in the Servers view. In the editor,
select the Modules tab. Select your web application and click Edit.
Uncheck Auto reloading enabled. That always does the trick for me. Now
if there were only a way to have it default to unchecked when deploying
a new application.
When Google asks to not have special treatment for their bot, they are
referring to content more than anything. Regarding the session id being
coded in the URL, see the Technical guidelines section of Google's
Webmaster Guidelines -
http://www.google.com/support/webmasters/bin/answer.py?answer=3576
Sorry, I should have attributed that code to Joel.
-Original Message-
From: Zappaterrini, Larry [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 25, 2008 10:56 AM
To: users@wicket.apache.org
Subject: RE: Double submit problem
I don't have a patch, at this point I was just testin
I don't have a patch, at this point I was just testing the waters. I'm
still new to Wicket and am learning about the goals of the community. If
there is interest in this it is something I could pursue further.
When I mentioned "not only does it prevent double submits" I was
speaking to the concept
your Spring bean is no longer a singleton, but as
long as your beans are stateless this does not really matter.
- Lars
On Thu, Mar 20, 2008 at 2:44 PM, Zappaterrini, Larry <
[EMAIL PROTECTED]> wrote:
> I suppose I need to learn more about how Spring support is implemented in
> Wicket. My
Support
you want to swallow the exception?
then you would return a null into a proxy and cause an npe later...
-igor
On Wed, Mar 19, 2008 at 1:43 PM, Zappaterrini, Larry
<[EMAIL PROTECTED]> wrote:
> It might be a nice improvement to Wicket's Spring support to allow for
>
It might be a nice improvement to Wicket's Spring support to allow for
missing bean definitions to be handled gracefully. This would allow for
the use of a sane default in the absence of explicit declaration in the
context XML. Right now using the Spring annotations support I get the
following erro
I was perusing Wicket's Javadocs and I came across a link to an old
thread
http://www.nabble.com/Why-add%28IBehavior%29-is-final--td7248198.html#a7
248198
Linked from
http://wicketstuff.org/wicket13doc/org/apache/wicket/Component.html#add(
org.apache.wicket.behavior.IBehavior)
The gist is that
They come bundled with the Wicket download under
src\jdk-1.5\wicket-examples
-Original Message-
From: Andrew Broderick [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 13, 2008 10:45 AM
To: 'users@wicket.apache.org'
Subject: downloading Wicket examples
Hi,
I found many useful Wicket exam
users@wicket.apache.org
Subject: Re: Authentication and Assigning a Session Id
wicket's Session has invalidate() and invalidateNow()
-igor
On Mon, Mar 10, 2008 at 1:38 PM, Zappaterrini, Larry
<[EMAIL PROTECTED]> wrote:
> While it is true that the jsessionid token is not contro
h a
> > check in requestcycle.onbeginrequest to do something like what you
> > want...
> >
> > -igor
> >
> >
> >
> >
> > On Mon, Mar 10, 2008 at 12:43 PM, Zappaterrini, Larry
> > <[EMAIL PROTECTED]> wrote:
> > > Hi Eve
Hi Everyone,
Is it possible to control when Wicket issues a valid session identifier to the
user? The use case I am trying to support is only assign a valid session id to
the user after they successfully authenticate. This is important to prevent
possible session hijacking. When dealing with H
43 matches
Mail list logo
