RE: CSRF Protection: double submitted cookie

2008-10-22 Thread Zappaterrini, Larry
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 help prevent 
the double form submit error. See 
http://www.nabble.com/Double-submit-problem-td15957979.html#a15957979 for 
example.

The JIRA issue you mention has a broken link. It looks like it should be 

http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks

If I am not mistaken.

-Original Message-
From: Jörn Zaefferer [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 22, 2008 8:05 AM
To: users@wicket.apache.org
Subject: Re: CSRF Protection: double submitted cookie

I've created a ticket and attached a reference implementation:
https://issues.apache.org/jira/browse/WICKET-1885

Jörn

On Mon, Oct 20, 2008 at 11:31 PM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
 The double-submitted-cookie isn't related to double submit protection,
 no. Thats a completely different turf.

 With that out of the way, its enough to create just one cookie and use
 that both while rendering and validating forms.

 I hope that makes it clearer. I'll try to provide a reference
 implementation tomorrow.

 Jörn

 On Mon, Oct 20, 2008 at 12:58 PM, Johan Compagner [EMAIL PROTECTED] wrote:
 hmm i will read the paper then
 I stil dont get it how it is possible with 1 cookie, that then can never
 change when it is first generated
 and all the forms also just have that value right?

 But it is also for double submit protection right? So the cookie has to
 change right?
 But how can you then have 1 cookie? for all the forms?
 If i submit one and that is rerendered or redirected to another page.
 (so it has a new cookie so the double submit cant happen)
 But if a new cookie is set then all other forms are also suddenly invalid..
 and that looks pretty wrong to me

 johan


 On Mon, Oct 20, 2008 at 12:44 PM, Jörn Zaefferer 
 [EMAIL PROTECTED] wrote:

 No, the cookie is subject to the same-origin-policy, both in reading
 and writing. The request is authenticated because the session cookie
 is set, but its invalid when the form itself is missing the value.
 Combining the attack with XSS would give access to the cookie, but
 then he could just as well hijack the session directly.

 In other words: With CSRF alone there is no way for the attacker to
 read the cookie, therefore its enough to use just one.

 Their whitepaper may do a better job of explaining the techniquie:
 http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf
 Solutions are described on page 8ff.

 Jörn

 On Mon, Oct 20, 2008 at 12:33 PM, Johan Compagner [EMAIL PROTECTED]
 wrote:
  what i dont get
  if an attacker wants to submit the form. and it can get to the form it
 can
  do the post
  but you say it cant access the cookie. But if the cookie value is just
  compared to the form post value
  we have to make sure that the name of the cookie cant be guessed right?
 So
  what should the name be?
 
  Because if the name would be wicket-form-uuid then couldnt the attacker
  also just generate that cookie?
 
  I guess there is a cookie per form (there can be many forms on the same
 page
  or different active pages)
  and that cookie must be regenerated/set on every form render?
 
  johan
 
 
  On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer 
  [EMAIL PROTECTED] wrote:
 
  Hi,
 
  my application currently uses CryptedUrlWebRequestCodingStrategy to
  protect against CRSF attacks. Afaik 1.3.5 will include an update that
  generates the key based on user sessions:
  http://issues.apache.org/jira/browse/WICKET-1782
  According to Johan Compagner, there are still issues with that
  approach, though I don't know if that has been fixed:
  http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593
 
  Anyway, the point of this mail is to bring up a different strategy for
  CSRF protection, the double-submitted-cookie. Discussion of that are
  here http://www.codinghorror.com/blog/archives/001175.html which links
  to this article, including a whitepaper:
 
 
 http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks
 
  The basic idea is:
 
  When a user visits a site, the site should generate a
  (cryptographically strong) pseudorandom value and set it as a cookie
  on the user's machine. The site should require every form submission
  to include this pseudorandom value as a form value and also as a
  cookie value. When a POST request is sent to the site, the request
  should only be considered valid if the form value and the cookie value
  are the same. When an attacker submits a form on behalf of a user, he
  can only modify the values of the form. An attacker cannot read any
  data sent from the server or modify cookie values, per the same-origin
  policy. This means 

RE: WicketSessionFilter Problem: java.lang.IllegalStateException

2008-07-30 Thread Zappaterrini, Larry
One more suggestion is to declare the filter so that it is invoked when
request dispatcher methods are called:

filter-mapping
  filter-nameWicketSessionFilter/filter-name
  url-pattern*.do/url-pattern
  dispatcherREQUEST/dispatcher
  dispatcherINCLUDE/dispatcher
/filter-mapping

I'm not sure if that is what is happening in this situation, but it
might be worth a shot.

-Original Message-
From: James Perry [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 30, 2008 7:31 AM
To: users@wicket.apache.org
Subject: Re: WicketSessionFilter Problem:
java.lang.IllegalStateException

I can't work out why it doesn't work so I decided to subclass the
WebRequestCycle and access the HTTPSession's attributes via my
PharmisisSession.

Cheers,
Jim.

On Wed, Jul 30, 2008 at 11:19 AM, James Perry
[EMAIL PROTECTED] wrote:
 Thanks for the swift reply. That's what I originally had but it didn't
 work and just tried again to re-confirm. :-)

 Any other suggestions? I've checkout the source code to see if that
helps.

 On Wed, Jul 30, 2008 at 10:42 AM, Martijn Dashorst
 [EMAIL PROTECTED] wrote:
 I think you have to wrap the wicket session filter around your *.do
 mapping, not your new/* mapping.

 Martijn

 On Wed, Jul 30, 2008 at 11:35 AM, James Perry
 [EMAIL PROTECTED] wrote:
 Hello!

 I would be grateful for any advice with the below problem I am
 encountering with the WicketSessionFilter.

 I managed to convince my colleagues to migrate our
www.mypharmisis.com
 (a drug ordering system for the Pharmaceutical industry) from Struts
 to Wicket after the success of a greenfield project using Wicket. I
 don't have the resources to migrate all at once so Struts 1 and
Wicket
 so I have set them up to coexist congruently. However! I am having
 problems sharing necessary state between Struts 1 and Wicket using
the
 WicketSessionFilter :-(

 When my Strut controllers tries to access my WebSession, it throws a
 java.lang.IllegalStateException: you can only locate or create
 sessions in the context of a request cycle. My stack trace is:

 org.apache.wicket.Session.findOrCreate(Session.java:206)
 org.apache.wicket.Session.get(Session.java:250)

com.mypharmsisis.pages.session.PharmisisSession.get(PharmisisSession.jav
a:24)

com.mypharmisis.struts.isis.actions.AbstractEasyAction.displayPage(Abstr
actEasyAction.java:52)

com.mypharmisis.struts.isis.actions.EasyOrderHomeAction.displayPage(Easy
OrderHomeAction.java:53)

 Here is a snippet of my web.xml:

!-- Wicket configuration using standard JEE filter --
filter
filter-namewicket.pharmisis/filter-name

filter-classorg.apache.wicket.protocol.http.WicketFilter/filter-class

init-param
param-nameapplicationClassName/param-name

param-valuecom.mypharmisis.pages.PharmisisApplication/param-value
/init-param
/filter

filter
filter-nameWicketSessionFilter/filter-name

filter-classorg.apache.wicket.protocol.http.servlet.WicketSessionFilte
r/filter-class
init-param
param-namefilterName/param-name
param-valuewicket.pharmisis/param-value
/init-param
/filter

filter-mapping
filter-namewicket.pharmisis/filter-name
url-pattern/secure/new/*/url-pattern
/filter-mapping

filter-mapping
filter-nameWicketSessionFilter/filter-name
url-pattern*.do/url-pattern
/filter-mapping

!-- End of Wicket configuration --

context-param
param-name
javax.servlet.jsp.jstl.fmt.localizationContext
/param-name
param-value
com.mypharmisis.isis.ApplicationResources
/param-value
/context-param

context-param
param-namecrystal_image_uri/param-name
param-value/isis2/crystalreportviewers11/param-value
/context-param

distributable/
listener

listener-classcom.mypharmisis.struts.isis.framework.IsisContextListene
r/listener-class
/listener

servlet
servlet-nameaction/servlet-name

servlet-classorg.apache.struts.action.ActionServlet/servlet-class

init-param
param-nameconfig/param-name
param-value/WEB-INF/struts-config.xml/param-value
/init-param
init-param
param-namedebug/param-name
param-valuetrue/param-value
/init-param
init-param
param-namedetail/param-name
param-value9/param-value
/init-param
init-param
param-namenocache/param-name
param-valuetrue/param-value
/init-param
init-param
param-namevalidate/param-name
param-valuetrue/param-value
/init-param

load-on-startup1/load-on-startup


/servlet

!-- DWR configuration --
servlet
servlet-namedwr-invoker/servlet-name
display-nameDWR Servlet/display-name

servlet-classorg.directwebremoting.servlet.DwrServlet/servlet-class
init-param
param-namedebug/param-name
 

RE: Strict 4 digit year for DateTextField?

2008-07-28 Thread Zappaterrini, Larry
Aye,

The use of DateFormat is actually in Spring's CustomDateEditor object.
See
http://static.springframework.org/spring/docs/2.5.x/api/org/springframew
ork/beans/propertyeditors/CustomDateEditor.html#CustomDateEditor(java.te
xt.DateFormat,%20boolean,%20int) where it mentions that
setLenient(false) does not enforce strict parsing as you might expect. I
think you are correct in thinking that creating your own IConverter
would be the best solution. I'd probably give subclassing
PatternDateConverter a shot.

Larry

-Original Message-
From: damnitjim [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 28, 2008 11:43 AM
To: users@wicket.apache.org
Subject: Re: Strict 4 digit year for DateTextField?

Larry,
I think setLenient(false) should work if you use java.text.DateFormat
but
did you write your own custom implementation of IConverter interface?
Thats
the only way I can think 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 10 characters. It might be nice if
 PatternDateConverter were to be enhanced to have a required length
value
 to enforce this in an encapsulated manner, but it isn't required.


 Larry

 -Original Message-
 From: damnitjim [mailto:[EMAIL PROTECTED]
 Sent: Friday, July 25, 2008 2:03 PM
 To: users@wicket.apache.org
 Subject: Strict 4 digit year for DateTextField?

 Hi,
 Has anyone been able to enforce that the year is 4 digits instead of
two
 for
 the DateTextField? Right now, if my format is MM/dd/ the
 DateTextField
 is still allowing two digit fields to be submitted.

 final String dateFormat = MM/dd/;
 PatternDateConverter pdc = new PatternDateConverter( dateFormat, false
 );
 add(DateTextField.withConverter(obligationDate,  pdc));

 I looked at the JODA javadoc for DateTimeFormat that
 PatternDateConverter is
 using but didn't see anything that would help (I saw ISODateTimeFormat
 that
 came close but it doesn't allow you to pass in the format).

 This seems like a reasonably straight forward problem so what am I
 missing?
 Thanks!
 Aye

 _

 The information contained in this message is proprietary and/or
 confidential. If you are not the
 intended recipient, please: (i) delete the message and all copies;
(ii) do
 not disclose,
 distribute or use the message in any manner; and (iii) notify the
sender
 immediately. In addition,
 please be aware that any message addressed to our domain is subject to
 archiving and review by
 persons other than the intended recipient. Thank you.
 _

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



_

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Strict 4 digit year for DateTextField?

2008-07-25 Thread Zappaterrini, Larry
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 encapsulated manner, but it isn't required.


Larry

-Original Message-
From: damnitjim [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 25, 2008 2:03 PM
To: users@wicket.apache.org
Subject: Strict 4 digit year for DateTextField?

Hi,
Has anyone been able to enforce that the year is 4 digits instead of two
for
the DateTextField? Right now, if my format is MM/dd/ the
DateTextField
is still allowing two digit fields to be submitted.

final String dateFormat = MM/dd/;
PatternDateConverter pdc = new PatternDateConverter( dateFormat, false
);
add(DateTextField.withConverter(obligationDate,  pdc));

I looked at the JODA javadoc for DateTimeFormat that
PatternDateConverter is
using but didn't see anything that would help (I saw ISODateTimeFormat
that
came close but it doesn't allow you to pass in the format).

This seems like a reasonably straight forward problem so what am I
missing?
Thanks!
Aye

_

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: New Wicket Grails Plug-in Available + about the Groovy wicket builder

2008-07-23 Thread Zappaterrini, Larry
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, 2008 4:36 PM
To: users@wicket.apache.org
Subject: Re: New Wicket Grails Plug-in Available + about the Groovy
wicket builder


I just tried this plugin for the first time and I got the example to
run. But
as soon as I tried to do something as simple as loop through a list of
items, it all came unstuck (code below). It seems to me like the
mismatch
between Wicket's use of anonymous inner classes and Groovy's lack of
support
for them is a deal breaker. You either have to reduce your usage of
Wicket
in Groovy code to preexisting Wicket components that were built in Java
(like the Label below), or you have to use a Groovy builder that emits
Java
code, which then gets compiled. Am I missing something? I hope so, I'd
love
to use GORM and Wicket together.

HomePage.groovy:

public class HelloPage extends WebPage
{
public HelloPage(final PageParameters parameters) {
add(new Label(message, If you see this message wicket is
properly
configured and running!));
add(new Loop(repeat, Book.list( 10 )))
{
@Override
protected void populateItem(LoopItem item)
{
Book book = (Book)
item.getModelObject();
item.setModel(new
CompoundPropertyModel(book));
item.add(new Label(name));
}
}
}
}

Julian

-- 
View this message in context:
http://www.nabble.com/New-Wicket-Grails-Plug-in-Available-%2B-about-the-
Groovy-wicket-builder-tp15828796p18598173.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

_

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Spring injection not working

2008-07-23 Thread Zappaterrini, Larry
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 using @SpringBean?

 On Wed, Jul 23, 2008 at 12:04 PM, David Nedrow [EMAIL PROTECTED]  
 wrote:
 I believe (though I'm clearly wrong in that belief) that I have  
 everything
 properly configured to allow spring injection along the lines of:

 import com.foo.dao.UserDAO;
 @Spring
 private UserDAO userDAO;

D'oh! Yes, I'm using @SpringBean.

I wish it was that simple. ;)

I was typing the examples I included in my original message, rather  
than copy and paste and flubbed it.

Wherever @Spring is in my example, read @SpringBean.

-David



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

_

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: why are we coding Web apps?

2008-07-16 Thread Zappaterrini, Larry
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.



From: Michael Allan [mailto:[EMAIL PROTECTED]
Sent: Wed 7/16/2008 2:00 PM
To: users@wicket.apache.org
Subject: why are we coding Web apps?



Daan van Etten wrote:

 Yeah I know, problem are that our application are ajax heavy, and
 stateless and ajax does not cope well I've heard..

 Maybe not within Wicket, I know too little of Wicket to draw a valid
 conclusion on that. But it is definitely possible.
 Look for example at the SproutCore development model. They create their
 application in Javascript and do requests to the backend to get records,
 save records, etc. Their application runs in the browser, making the server
 more like a stateless backend (from what I understood of SproutCore).
 I know it's possible (and done before) to build a Javascript application
 (or even desktop) that way.

I'd rephrase that to:

  ... build a desktop application, or even a Javascript application
   (if you are into pain)

You are generalizing beyond a traditional Web architecture (as Wicket
supports), and that opens the field to other client/server
architectures, in addition to the Web.  And I can't think of a reason
for coding a Web client, except this one:

  1. The user can seamlessly click into the application from external
 sites, and click back out again.

Can anyone think of another reason?  Because otherwise, if I have an
app that doesn't need cross-hyperlinks with the larger Web, then why
should I code it as a Web app in the first place?  Shouldn't I code
the front end as a proper GUI, using a framework like Swing?

I'm asking myself this question.  And in my case I come up with one
additional reason, which is just a special case of (1):

  1 a. A Web client is good for demonstrating a new application,
   because it's convenient for casual users, who wish to try out
   the app.  Most users have Web browsers pre-installed.  They may
   not have Java, etc.

--
Michael Allan

Toronto, 647-436-4521
http://zelea.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



_

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_


RE: Tomcat 6 clustering problem

2008-06-25 Thread Zappaterrini, Larry
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 host name (clustertest perhaps)  that points to the first
server's IP address, access the site, switch the IP address in the hosts
file to the second server, verify that the second server is indeed hit
and that the behavior is correct.

I'm not sure if you are familiar with working with a hosts file so just
know that on all Unix-like systems I have encountered it is found at
/etc/hosts and on all Windows systems I have encountered it is found at
C:\WINDOWS\system32\drivers\etc\hosts

Larry

-Original Message-
From: Artem D. [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 25, 2008 10:05 AM
To: users@wicket.apache.org
Subject: RE: Tomcat 6 clustering problem


Disabling cookies in browser made it work!
Servers are configured with jvmRoutes jvm1 and jvm2, i.e. for the first
server:

Engine name=Catalina defaultHost=localhost jvmRoute=jvm1

jsessionid request parameter while requesting the first server looks
like
jsessionid=3E526DD2214AEA5B5C2DAB9C6713AF26.jvm1

When switching to the second server jvm2 suffix is used.

What's the correct way to make it work with enabled cookies?

-Artem.


lzappaterrini wrote:
 
 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@wicket.apache.org
 Subject: Tomcat 6 clustering problem
 
 
 Hi all,
 I've got wicket 1.4-m2 based application running on two different
 network
 hosts configured as Tomcat 6 Simple TCP cluster.
 I try to simulate failover with session replication using the
following
 schema:
 1) Log into the first server, store some info in HTTP session
 2) Access mounted page on the first server, i.e.
 http://first.server/mounted/page
 3) Try to access the same page on the second server, i.e.
 http://second.server/mounted/page
 
 I assume that HTTP session should replicate between Tomcat's and I
want
 to
 get immediate reply from the second server, but all I get is
forwarding
 me
 to the login screen and the following entries in log:
 
 Jun 25, 2008 5:10:39 PM org.apache.catalina.ha.session.DeltaManager
 messageReceived
 SEVERE: Manager [localhost#/mas]: Unable to receive message through
TCP
 channel
 java.lang.IllegalArgumentException: Unknown object type null
 at

org.apache.wicket.protocol.http.pagestore.DiskPageStore.restoreAfterSeri
 alization(DiskPageStore.java:1211)
 at

org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevel
 CachePageMap.readObject(SecondLevelCacheSessionStore.java:403)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at

sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
 a:39)
 at

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
 Impl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at
 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
 at
 java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
 at

java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753
 )
 at
 java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
 at
 java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
 at

org.apache.catalina.ha.session.DeltaRequest$AttributeInfo.readExternal(D
 eltaRequest.java:361)
 at

org.apache.catalina.ha.session.DeltaRequest.readExternal(DeltaRequest.ja
 va:255)
 at

org.apache.catalina.ha.session.DeltaManager.deserializeDeltaRequest(Delt
 aManager.java:619)
 at

org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaMan
 ager.java:1363)
 at

org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager
 .java:1320)
 at

org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaMan
 ager.java:1083)
 at

org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(Cl
 usterSessionListener.java:87)
 at

org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpClu
 ster.java:899)
 at

org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpClu
 ster.java:880)
 at

org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChann
 el.java:269)
 at

org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(
 ChannelInterceptorBase.java:79)
 at

org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.message
 Received(TcpFailureDetector.java:110)
 

RE: generics

2008-06-24 Thread Zappaterrini, Larry
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/discussion from our user base. do try to
 port a small project or a part of a larger project you are working on
 to the [1] branch to see how the new api feels. if we do like this
 more the new branch will be merged into what will be 1.4m3.

 [1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics

   
am I the only one running into this:

mvn clean install
[...]
[INFO] 

[INFO] Building Wicket
[INFO]task-segment: [clean, install]
[INFO] 

[INFO] [clean:clean]
[INFO] Deleting directory /home/fnk64/tmp/generics/wicket/target
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 748 source files to 
/home/fnk64/tmp/generics/wicket/target/classes
[INFO] 

[ERROR] BUILD FAILURE
[INFO] 

[INFO] Compilation failure
/home/fnk64/tmp/generics/wicket/src/main/java/org/apache/wicket/markup/h
tml/list/ListItem.java:[90,42] 
type parameters of TT cannot be determined; no unique maximal instance

exists for type variable T with upper bounds T,java.lang.Object



/home/fnk64/tmp/generics/wicket/src/main/java/org/apache/wicket/markup/h
tml/list/ListItem.java:[90,42] 
type parameters of TT cannot be determined; no unique maximal instance

exists for type variable T with upper bounds T,java.lang.Object
[...]

though eclipse compiler doesn't complain

I'm running: javac -version
javac 1.5.0_15

 uname -a
Linux fnk64-desktop 2.6.24-19-generic #1 SMP Wed Jun 18 14:43:41 UTC 
2008 i686 GNU/Linux

on a current Kubuntu 8/04

mf

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Session end method

2008-06-23 Thread Zappaterrini, Larry
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 when the HttpSession timed out. I
noticed that it actually wasn't, so I then assumed (again!) that Wicket
wasn't handling any HttpSession time outs. Would it make sense to have
Wicket call Session.invalidate when the HttpSession times out to
simplify this use case and not require implementing ISessionStore?

-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED] 
Sent: Saturday, June 21, 2008 3: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
 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 stopped.

 -Original Message-
 From: Nino Saturnino Martinez Vazquez Wael
 [mailto:[EMAIL PROTECTED]
 Sent: Friday, June 20, 2008 3:03 AM
 To: users@wicket.apache.org
 Subject: Re: Session end method

 Theres also an unsecure way of doing it, namely this(from
 applicationclass):

 @Override
 protected ISessionStore newSessionStore() {
 return new SecondLevelCacheSessionStore(this, new
 DiskPageStore()) {
 @Override
 protected void onBind(Request request, Session newSession)
{

 sessionMap.put(newSession.getId(), (ZeuzSession)
 newSession);
 super.onBind(request, newSession);
 }

 @Override
 protected void onUnbind(String sessionId) {
 ZeuzSession session = (ZeuzSession)
 sessionMap.get(sessionId);
 session.onBeforeDestroy();
 sessionMap.remove(sessionId);
 super.onUnbind(sessionId);
 }

 };
 }


 Eyal Golan wrote:
 Hello,
 Is there a method in Session that is called when the Session is
ended?
 Ended = user logs out (invalidate) or time-out (or anything else that
 can do
 that)

 My goal is to keep some information in the session and persist it
when
 the
 session terminates.

 Is it legal to create a Thread (as a member in the Session /
 Application)
 that every X minutes will get information from the Session and do
 something
 with it?



 --
 -Wicket for love

 Nino Martinez Wael
 Java Specialist @ Jayway DK
 http://www.jayway.dk
 +45 2936 7684


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

 __

 The information contained in this message is proprietary and/or
 confidential. If you are not the
 intended recipient, please: (i) delete the message and all copies;
(ii) do
 not disclose,
 distribute or use the message in any manner; and (iii) notify the
sender
 immediately. In addition,
 please be aware that any message addressed to our domain is subject to
 archiving and review by
 persons other than the intended recipient. Thank you.
 _

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-- 
Sent from Gmail for mobile | mobile.google.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Session end method

2008-06-23 Thread Zappaterrini, Larry
I see. So then would the best place to do session cleanup be in
WebApplication.sessionDestroyed?

I guess the question really boils down to: where is the best place to
clean up session related resources to ensure that they are freed in all
instances regardless of which ISessionStore implementation is used?

Thanks,
Larry

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 23, 2008 11:11 AM
To: users@wicket.apache.org
Subject: Re: Session end method

session.invalidate() triggers the invalidation, just like it does in
httpsession. you might want to 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 when the HttpSession timed out. I
 noticed that it actually wasn't, so I then assumed (again!) that
Wicket
 wasn't handling any HttpSession time outs. Would it make sense to have
 Wicket call Session.invalidate when the HttpSession times out to
 simplify this use case and not require implementing ISessionStore?

 -Original Message-
 From: Johan Compagner [mailto:[EMAIL PROTECTED]
 Sent: Saturday, June 21, 2008 3: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
 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 stopped.

 -Original Message-
 From: Nino Saturnino Martinez Vazquez Wael
 [mailto:[EMAIL PROTECTED]
 Sent: Friday, June 20, 2008 3:03 AM
 To: users@wicket.apache.org
 Subject: Re: Session end method

 Theres also an unsecure way of doing it, namely this(from
 applicationclass):

 @Override
 protected ISessionStore newSessionStore() {
 return new SecondLevelCacheSessionStore(this, new
 DiskPageStore()) {
 @Override
 protected void onBind(Request request, Session
newSession)
 {

 sessionMap.put(newSession.getId(), (ZeuzSession)
 newSession);
 super.onBind(request, newSession);
 }

 @Override
 protected void onUnbind(String sessionId) {
 ZeuzSession session = (ZeuzSession)
 sessionMap.get(sessionId);
 session.onBeforeDestroy();
 sessionMap.remove(sessionId);
 super.onUnbind(sessionId);
 }

 };
 }


 Eyal Golan wrote:
 Hello,
 Is there a method in Session that is called when the Session is
 ended?
 Ended = user logs out (invalidate) or time-out (or anything else
that
 can do
 that)

 My goal is to keep some information in the session and persist it
 when
 the
 session terminates.

 Is it legal to create a Thread (as a member in the Session /
 Application)
 that every X minutes will get information from the Session and do
 something
 with it?



 --
 -Wicket for love

 Nino Martinez Wael
 Java Specialist @ Jayway DK
 http://www.jayway.dk
 +45 2936 7684


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

 __

 The information contained in this message is proprietary and/or
 confidential. If you are not the
 intended recipient, please: (i) delete the message and all copies;
 (ii) do
 not disclose,
 distribute or use the message in any manner; and (iii) notify the
 sender
 immediately. In addition,
 please be aware that any message addressed to our domain is subject
to
 archiving and review by
 persons other than the intended recipient. Thank you.
 _

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 --
 Sent from Gmail for mobile | mobile.google.com

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

 __

 The information contained in this message is proprietary and/or
confidential. If you are not the
 intended recipient, please: (i) delete the message and all copies;
(ii) do not disclose,
 distribute or use the message in any manner; and (iii) notify the
sender immediately. In addition,
 please be aware that any message addressed to our domain is subject to
archiving and review by
 persons other than the intended recipient. Thank you.
 _

 -
 To unsubscribe, e-mail: [EMAIL

RE: Session end method

2008-06-23 Thread Zappaterrini, Larry
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 (or should there) be a more
intuitive way to handle this use case than Nino's solution of providing
a custom ISessionStore? Perhaps some other callback on Session such as
onUnbind. Maybe this isn't a common enough use case to warrant a new
method though.

Thanks,
Larry

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 23, 2008 12:48 PM
To: users@wicket.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:
 I see. So then would the best place to do session cleanup be in
 WebApplication.sessionDestroyed?

 I guess the question really boils down to: where is the best place to
 clean up session related resources to ensure that they are freed in
all
 instances regardless of which ISessionStore implementation is used?

 Thanks,
 Larry

 -Original Message-
 From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
 Sent: Monday, June 23, 2008 11:11 AM
 To: users@wicket.apache.org
 Subject: Re: Session end method

 session.invalidate() triggers the invalidation, just like it does in
 httpsession. you might want to 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 when the HttpSession timed out. I
 noticed that it actually wasn't, so I then assumed (again!) that
 Wicket
 wasn't handling any HttpSession time outs. Would it make sense to
have
 Wicket call Session.invalidate when the HttpSession times out to
 simplify this use case and not require implementing ISessionStore?

 -Original Message-
 From: Johan Compagner [mailto:[EMAIL PROTECTED]
 Sent: Saturday, June 21, 2008 3: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
 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 stopped.

 -Original Message-
 From: Nino Saturnino Martinez Vazquez Wael
 [mailto:[EMAIL PROTECTED]
 Sent: Friday, June 20, 2008 3:03 AM
 To: users@wicket.apache.org
 Subject: Re: Session end method

 Theres also an unsecure way of doing it, namely this(from
 applicationclass):

 @Override
 protected ISessionStore newSessionStore() {
 return new SecondLevelCacheSessionStore(this, new
 DiskPageStore()) {
 @Override
 protected void onBind(Request request, Session
 newSession)
 {

 sessionMap.put(newSession.getId(), (ZeuzSession)
 newSession);
 super.onBind(request, newSession);
 }

 @Override
 protected void onUnbind(String sessionId) {
 ZeuzSession session = (ZeuzSession)
 sessionMap.get(sessionId);
 session.onBeforeDestroy();
 sessionMap.remove(sessionId);
 super.onUnbind(sessionId);
 }

 };
 }


 Eyal Golan wrote:
 Hello,
 Is there a method in Session that is called when the Session is
 ended?
 Ended = user logs out (invalidate) or time-out (or anything else
 that
 can do
 that)

 My goal is to keep some information in the session and persist it
 when
 the
 session terminates.

 Is it legal to create a Thread (as a member in the Session /
 Application)
 that every X minutes will get information from the Session and do
 something
 with it?



 --
 -Wicket for love

 Nino Martinez Wael
 Java Specialist @ Jayway DK
 http://www.jayway.dk
 +45 2936 7684



-
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

 __

 The information contained in this message is proprietary and/or
 confidential. If you are not the
 intended recipient, please: (i) delete the message and all copies;
 (ii) do
 not disclose,
 distribute or use the message in any manner; and (iii) notify the
 sender
 immediately. In addition,
 please be aware that any message addressed to our domain is subject
 to
 archiving and review by
 persons other than the intended recipient. Thank you

RE: Session end method

2008-06-23 Thread Zappaterrini, Larry
Sorry, contains was too strong of a word. Let's say when the session is
invalidated that a heavyweight object contained in a global repository
must be freed. Come to think of it, even something as simple as logging
information about the session when it is invalidated fits this
description.

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 23, 2008 1:22 PM
To: users@wicket.apache.org
Subject: Re: Session end method

well. a session cannot contain a thing like a thread or a database
connection because everything in session must be serializable.

-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 (or should there) be a more
 intuitive way to handle this use case than Nino's solution of
providing
 a custom ISessionStore? Perhaps some other callback on Session such as
 onUnbind. Maybe this isn't a common enough use case to warrant a new
 method though.

 Thanks,
 Larry

 -Original Message-
 From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
 Sent: Monday, June 23, 2008 12:48 PM
 To: users@wicket.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:
 I see. So then would the best place to do session cleanup be in
 WebApplication.sessionDestroyed?

 I guess the question really boils down to: where is the best place to
 clean up session related resources to ensure that they are freed in
 all
 instances regardless of which ISessionStore implementation is used?

 Thanks,
 Larry

 -Original Message-
 From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
 Sent: Monday, June 23, 2008 11:11 AM
 To: users@wicket.apache.org
 Subject: Re: Session end method

 session.invalidate() triggers the invalidation, just like it does in
 httpsession. you might want to 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 when the HttpSession timed out. I
 noticed that it actually wasn't, so I then assumed (again!) that
 Wicket
 wasn't handling any HttpSession time outs. Would it make sense to
 have
 Wicket call Session.invalidate when the HttpSession times out to
 simplify this use case and not require implementing ISessionStore?

 -Original Message-
 From: Johan Compagner [mailto:[EMAIL PROTECTED]
 Sent: Saturday, June 21, 2008 3: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
 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 stopped.

 -Original Message-
 From: Nino Saturnino Martinez Vazquez Wael
 [mailto:[EMAIL PROTECTED]
 Sent: Friday, June 20, 2008 3:03 AM
 To: users@wicket.apache.org
 Subject: Re: Session end method

 Theres also an unsecure way of doing it, namely this(from
 applicationclass):

 @Override
 protected ISessionStore newSessionStore() {
 return new SecondLevelCacheSessionStore(this, new
 DiskPageStore()) {
 @Override
 protected void onBind(Request request, Session
 newSession)
 {

 sessionMap.put(newSession.getId(), (ZeuzSession)
 newSession);
 super.onBind(request, newSession);
 }

 @Override
 protected void onUnbind(String sessionId) {
 ZeuzSession session = (ZeuzSession)
 sessionMap.get(sessionId);
 session.onBeforeDestroy();
 sessionMap.remove(sessionId);
 super.onUnbind(sessionId);
 }

 };
 }


 Eyal Golan wrote:
 Hello,
 Is there a method in Session that is called when the Session is
 ended?
 Ended = user logs out (invalidate) or time-out (or anything else
 that
 can do
 that)

 My goal is to keep some information in the session and persist it
 when
 the
 session terminates.

 Is it legal to create a Thread (as a member in the Session /
 Application)
 that every X minutes will get information from the Session and do
 something
 with it?



 --
 -Wicket for love

 Nino Martinez Wael
 Java Specialist @ Jayway DK
 http://www.jayway.dk
 +45 2936 7684

RE: Session end method

2008-06-20 Thread Zappaterrini, Larry
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 stopped.

-Original Message-
From: Nino Saturnino Martinez Vazquez Wael
[mailto:[EMAIL PROTECTED] 
Sent: Friday, June 20, 2008 3:03 AM
To: users@wicket.apache.org
Subject: Re: Session end method

Theres also an unsecure way of doing it, namely this(from
applicationclass):

@Override
protected ISessionStore newSessionStore() {
return new SecondLevelCacheSessionStore(this, new
DiskPageStore()) {
@Override
protected void onBind(Request request, Session newSession) {

sessionMap.put(newSession.getId(), (ZeuzSession) 
newSession);
super.onBind(request, newSession);
}

@Override
protected void onUnbind(String sessionId) {
ZeuzSession session = (ZeuzSession) 
sessionMap.get(sessionId);
session.onBeforeDestroy();
sessionMap.remove(sessionId);
super.onUnbind(sessionId);
}

};
}


Eyal Golan wrote:
 Hello,
 Is there a method in Session that is called when the Session is ended?
 Ended = user logs out (invalidate) or time-out (or anything else that
can do
 that)

 My goal is to keep some information in the session and persist it when
the
 session terminates.

 Is it legal to create a Thread (as a member in the Session /
Application)
 that every X minutes will get information from the Session and do
something
 with it?

   

-- 
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Is it safe to share static components across multiple page instances and request threads?

2008-06-20 Thread Zappaterrini, Larry
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 shared across threads. Creating a new
instance of the link for every page would be the correct approach.


-Original Message-
From: Joel Halbert [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 20, 2008 4:31 AM
To: users@wicket.apache.org
Subject: Re: Is it safe to share static components across multiple page
instances and request threads?

(BTW I am assuming that since each component has a parent that sharing
is 
NOT allowed)

--
From: Joel Halbert [EMAIL PROTECTED]
Sent: Friday, June 20, 2008 9:29 AM
To: users@wicket.apache.org
Subject: Is it safe to share static components across multiple page 
instances and request threads?

 Hi,

 Is it threadsafe and wicket safe to share static Components across 
 multiple instances of a Page (as well as across request threads) in 
 wicket?

 Say for example I have a BookmarkablePageLink that takes no dynamic 
 PageParameter arguments, can I create this as a static class member
and 
 share it across all instances of the Page on which it is used?
(instead if 
 creating a new instance for each new page).

 Rgs,
 Joel 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Making Component easier to Generify

2008-06-12 Thread Zappaterrini, Larry
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 to persist as development and evolution of the
API is carried out. Occasionally a user can come up with a good argument
for removing the final restriction and makes their case, affecting a
change.

It is very easy to create an evolutionary dead end for an API by
allowing everything to be overridden. So either deprecate and start over
or risk breaking client code and have your users hate you for it :)

-Original Message-
From: Brill Pappin [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 12, 2008 11:09 AM
To: users@wicket.apache.org
Subject: Re: Making Component easier to Generify

I understand the reasoning, however I think best practice can be  
debated.
To use your example Swing allows the user to override quite a bit, and  
it doesn't make any (or very few) assumptions on what should and  
should not be done.

I don't like API's that assume I'm an idiot and prevent me from  
manipulating them how I see fit. If I cause a bug that I have to deal  
with, thats *my* problem to resolve.

In my book (and I'm not the only one) excessive use of final is an  
anti-pattern.

- Brill Pappin

On 12-Jun-08, at 10:01 AM, cowwoc wrote:


 Brill,

 This is actually an API best practice. Classes fall into two  
 categories:
 ones designed for subclassing, and ones designed to be final. The  
 same goes
 for methods. Swing is full of examples of what goes wrong when people
 override methods in classes that haven't been designed with  
 subclassing in
 mind.

 Gili


 Brill Pappin wrote:

 on removing the finals

 The final members are the worst thing I've had to deal with in Wicket
 so far.
 Although I understand that there may be a reason for them, they are
 more a hinderance than anything else and seem to be trying to  
 protect
 users from themselves.

 - Brill Pappin


 On 12-Jun-08, at 1:03 AM, cowwoc wrote:



 Have you considered moving from subclassing to composition in Wicket
 using
 CallableT?

 Currently it is quite common for developers to subclass a component
 in order
 to override isVisible() and other properties. I am proposing that
 instead
 the component classes become final and properties may only be set
 using
 setter methods. The setter methods would take CallableT instead of
 T, so
 for example setVisible(boolean) would become
 setVisible(CallableBoolean)

 The benefit of this approach is that you could introduce static
 factory
 methods to the Wicket components which would make them much easier
 to use in
 their Generic form. You could then introduce various helper  
 classes to
 create CallableT for constant values, such as
 Callable.valueOf(true) would
 return a CallableBoolean that always returns true.
 -- 
 View this message in context:

http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo
ur-take-on-generics-with-Wicket-tp17589984p17792488.html
 Sent from the Wicket - User mailing list archive at Nabble.com.



-
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 -- 
 View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo
ur-take-on-generics-with-Wicket-tp17589984p17800710.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Making Component easier to Generify

2008-06-12 Thread Zappaterrini, Larry
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...)

-Original Message-
From: Eelco Hillenius [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 12, 2008 12:51 PM
To: users@wicket.apache.org
Subject: Re: Making Component easier to Generify

 However, I am *in no way asking* the developers to reverse the final
 policy.

We actually relaxed that way more as we felt more confident about
Wicket's API and as motivated requests came in. Personally, I think
using final or not should be a deliberate choice (not automatic). If
you never use it, you can arrive to that evolutionary dead-end pretty
quickly (or indeed will have to break clients all the time), but if
you over-use it, your framework will lack flexibility. Anyway, IF you
stumble upon a final in a place where you'd like to see it go, you can
always send a motivated request for that. We've typically been willing
to remove finals when a good motivation was given.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: (Class? extends Page?) casting troubles

2008-06-09 Thread Zappaterrini, Larry
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 arise in practice. I'll have to think
about it some more.

I might be missing something with point 2, but what is wrong with
ClassFoo 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? extends Page?) casting troubles

Zappaterrini, Larry wrote:
 Sorry, I should have been more clear about subtype. :) When dealing
with
 raw types, the raw type is considered a super type of the generic
type.
 So Bar is a super type of Bar?. Since RawType extends the raw type
 Bar, consider it to be a peer of Bar?. When you consider them as
 peers, a warning is warranted. The new example you use works due to
 erasure. Bar? as declared in source code becomes Bar in byte code.
So
 the statement becomes:
 
   Bar bar = new RawBar();
 
 Which is perfectly legal. I have found that most of perceived
 inconsistencies in Java generics stems  from erasure and sub type
 substitution. The golden rule of generics is that the byte code
produced
 by compiling generics will never produce an invalid cast so long as
the
 code does not produce any warnings. This causes some things that may
 seem intuitive to be illegal.

Thanks for your explanation. I still think it's all rather horrible 
though. Type erasure was a huge mistake if you ask me. Two questions for

you though...

1) Can you come up with an example where assigning a Foo? extends Bar 
to a Foo? extends Bar? causes an invalid cast? (So I can understand 
why this intuitive seeming assignment is illegal).

2) How do you get rid of the warning in ClassFoo clazz = Foo.class 
without using Class?? Because it would seem strange if there is no 
warning free way to use a certain language construct...

Regards,
Sebastiaan

 -Original Message-
 From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] 
 Sent: Friday, June 06, 2008 4:16 PM
 To: users@wicket.apache.org
 Subject: Re: (Class? extends Page?) 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 definition of subtype. It is at least the
case
 
 that the following assignment compiles without warnings (without 
 warnings about unchecked casts):
 
Bar? bar = new RawBar();
 
 So is it then a subtype? Or isn't it? It's all terribly inconsistent
if 
 you ask me. :-(
 
 Regards,
 Sebastiaan
 
 
 
 -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? extends Page?) casting troubles

 ARgh, you always make typos with this stuff.

 See correction.

 Sebastiaan van Erk wrote:
 Martin Funk wrote:

 Class? extends Page? means class of (anything that extends
 (page of
 anything)).
 I'm not so sure.
 There are 2 separate issues:

 ISSUE 1: Foo? extends Bar? is not assignable from a FooRawBar 
 where RawBar extends Bar as a raw type. That is, given:

   static class FooT {
   }

   static class BarT {
   }

   static class RawBar extends Bar {
   }

   static class SubBarT extends BarT {
   }

 Thus:

Bar? bar = new RawBar(); // works, because RawBar is a subtype
 of
 Bar?

 But:

Foo? extends Bar? rawbar = new RawBar(); // DOES NOT WORK -
 THIS 
 IS CAUSING ONE HALF OF ALL OUR HEADACHES
 (correction:)
 Foo? extends Bar? rawbar = new FooRawBar(); // DOES NOT
WORK
 -
 THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES

 Btw, this does work (like you expect):
 Foo? extends Bar? rawbar2 = new FooSubBar?();

 Note that this is the issue that complete baffles me, as RawBar is a

 subtype of Bar?, so I *really* *really* *REALLY* have no idea why
 the 
 compiler chokes on this.

 ISSUE 2: The class literal of a generic type returns a class of a
raw
 
 type.  Thus Foo.class return ClassFoo. This is also really messed
 up, 
 because:
 
 ClassFoo fc = Foo.class;

 compiles, but generates a warning (reference to raw type). But if
you
 
 type this in eclipse:

 x fc = Foo.class;

 and use eclipse quickfix to change x to the correct type, it'll 
 change it to precisely ClassFoo (the JLS is very short about this,
 see 
 also 


http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#1
 5.8.2). 
 So what the heck is the proper type for the class literal??? I
 couldn't 
 find any!

 Finally, note that when you define a method like this:

   static void method1(Foo? extends Bar? y) {
   }

 it works like a charm for a new FooSubBarString, i.e., the Foo
 of
 (anything that extends (bar of anything)) really is the correct 
 interpretation.

 It's just that the interaction with raw types is completely *foobar*

 (pun intended).

 Regards,
 Sebastiaan

RE: (Class? extends Page?) casting troubles

2008-06-09 Thread Zappaterrini, Larry
Ah, I forgot the context around which we were discussing Foo.class. That is 
definitely a shortcoming of erasure if ever there were one. Unfortunately the 
best you can do with class literals is Class?. I actually ran into this 
problem early on when moving to Wicket 1.4. I have a custom FormComponent that 
wraps another FormComponent and provides it with an associated Label. This 
object is meant for subclassing, to provide a text field with a label for 
instance. Prior to 1.4 the object took Class? extends FormComponent as an 
argument to its constructor and instantiated the wrapped component from that. 
Subclasses called super with their Class of choice. Enter 1.4 with 
FormComponentT and the Class argument becomes Class? extends 
FormComponent? (looks familiar, right?). It is impossible to provide such an 
object using class literals so I had to rethink the design. Frustrating? You 
bet! I understand why erasure was chosen but I feel it is too limiting 
sometimes. It seems that it is most visible in the instance of using Class 
objects. It makes for interesting discussions anyway...

 


From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
Sent: Mon 6/9/2008 12:54 PM
To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) 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 arise in practice. I'll have to think
 about it some more.

 I might be missing something with point 2, but what is wrong with
 ClassFoo clazz = Foo.class?

If Foo is a generic type (as in the example I gave), then the above
assignment will give you a warning (which I don't know how to get rid
off without a suppress)...

Foo is a raw type. References to generic type FooT should be parameterized

Regards,
Sebastiaan

 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? extends Page?) casting troubles

 Zappaterrini, Larry wrote:
 Sorry, I should have been more clear about subtype. :) When dealing
 with
 raw types, the raw type is considered a super type of the generic
 type.
 So Bar is a super type of Bar?. Since RawType extends the raw type
 Bar, consider it to be a peer of Bar?. When you consider them as
 peers, a warning is warranted. The new example you use works due to
 erasure. Bar? as declared in source code becomes Bar in byte code.
 So
 the statement becomes:

  Bar bar = new RawBar();

 Which is perfectly legal. I have found that most of perceived
 inconsistencies in Java generics stems  from erasure and sub type
 substitution. The golden rule of generics is that the byte code
 produced
 by compiling generics will never produce an invalid cast so long as
 the
 code does not produce any warnings. This causes some things that may
 seem intuitive to be illegal.

 Thanks for your explanation. I still think it's all rather horrible
 though. Type erasure was a huge mistake if you ask me. Two questions for

 you though...

 1) Can you come up with an example where assigning a Foo? extends Bar
 to a Foo? extends Bar? causes an invalid cast? (So I can understand
 why this intuitive seeming assignment is illegal).

 2) How do you get rid of the warning in ClassFoo clazz = Foo.class
 without using Class?? Because it would seem strange if there is no
 warning free way to use a certain language construct...

 Regards,
 Sebastiaan

 -Original Message-
 From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
 Sent: Friday, June 06, 2008 4:16 PM
 To: users@wicket.apache.org
 Subject: Re: (Class? extends Page?) 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 definition of subtype. It is at least the
 case
 that the following assignment compiles without warnings (without
 warnings about unchecked casts):

Bar? bar = new RawBar();

 So is it then a subtype? Or isn't it? It's all terribly inconsistent
 if
 you ask me. :-(

 Regards,
 Sebastiaan



 -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? extends Page?) casting troubles

 ARgh, you always make typos with this stuff.

 See correction.

 Sebastiaan van Erk wrote:
 Martin Funk wrote:

 Class? extends Page? means class of (anything that extends
 (page of
 anything)).
 I'm not so sure.
 There are 2 separate issues:

 ISSUE 1: Foo? extends Bar? is not assignable from a FooRawBar
 where RawBar extends Bar as a raw type. That is, given:

   static class FooT {
   }

   static class BarT {
   }

   static class RawBar extends Bar {
   }

   static class SubBarT extends BarT {
   }

 Thus

RE: (Class? extends Page?) casting troubles

2008-06-06 Thread Zappaterrini, Larry
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? extends Page?) casting troubles

ARgh, you always make typos with this stuff.

See correction.

Sebastiaan van Erk wrote:
 Martin Funk wrote:
 
 Class? extends Page? means class of (anything that extends
(page of
 anything)).

 I'm not so sure.
 
 There are 2 separate issues:
 
 ISSUE 1: Foo? extends Bar? is not assignable from a FooRawBar 
 where RawBar extends Bar as a raw type. That is, given:
 
   static class FooT {
   }
 
   static class BarT {
   }
 
   static class RawBar extends Bar {
   }
 
   static class SubBarT extends BarT {
   }
 
 Thus:
 
Bar? bar = new RawBar(); // works, because RawBar is a subtype of

 Bar?
 
 But:
 
Foo? extends Bar? rawbar = new RawBar(); // DOES NOT WORK -
THIS 
 IS CAUSING ONE HALF OF ALL OUR HEADACHES

(correction:)
Foo? extends Bar? rawbar = new FooRawBar(); // DOES NOT WORK -

THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES

Btw, this does work (like you expect):
Foo? extends Bar? rawbar2 = new FooSubBar?();

 Note that this is the issue that complete baffles me, as RawBar is a 
 subtype of Bar?, so I *really* *really* *REALLY* have no idea why
the 
 compiler chokes on this.
 
 ISSUE 2: The class literal of a generic type returns a class of a raw 
 type.  Thus Foo.class return ClassFoo. This is also really messed
up, 
 because:
 
 ClassFoo fc = Foo.class;
 
 compiles, but generates a warning (reference to raw type). But if you 
 type this in eclipse:
 
 x fc = Foo.class;
 
 and use eclipse quickfix to change x to the correct type, it'll 
 change it to precisely ClassFoo (the JLS is very short about this,
see 
 also 

http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#1
5.8.2). 
 
 
 So what the heck is the proper type for the class literal??? I
couldn't 
 find any!
 
 Finally, note that when you define a method like this:
 
   static void method1(Foo? extends Bar? y) {
   }
 
 it works like a charm for a new FooSubBarString, i.e., the Foo of

 (anything that extends (bar of anything)) really is the correct 
 interpretation.
 
 It's just that the interaction with raw types is completely *foobar* 
 (pun intended).
 
 Regards,
 Sebastiaan
 
 
 
 
 
 
 

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: (Class? extends Page?) casting troubles

2008-06-06 Thread Zappaterrini, Larry
Sorry, I should have been more clear about subtype. :) When dealing with
raw types, the raw type is considered a super type of the generic type.
So Bar is a super type of Bar?. Since RawType extends the raw type
Bar, consider it to be a peer of Bar?. When you consider them as
peers, a warning is warranted. The new example you use works due to
erasure. Bar? as declared in source code becomes Bar in byte code. So
the statement becomes:

Bar bar = new RawBar();

Which is perfectly legal. I have found that most of perceived
inconsistencies in Java generics stems  from erasure and sub type
substitution. The golden rule of generics is that the byte code produced
by compiling generics will never produce an invalid cast so long as the
code does not produce any warnings. This causes some things that may
seem intuitive to be illegal.
 
-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 4:16 PM
To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) 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 definition of subtype. It is at least the case

that the following assignment compiles without warnings (without 
warnings about unchecked casts):

   Bar? bar = new RawBar();

So is it then a subtype? Or isn't it? It's all terribly inconsistent if 
you ask me. :-(

Regards,
Sebastiaan



 -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? extends Page?) casting troubles
 
 ARgh, you always make typos with this stuff.
 
 See correction.
 
 Sebastiaan van Erk wrote:
 Martin Funk wrote:

 Class? extends Page? means class of (anything that extends
 (page of
 anything)).
 I'm not so sure.
 There are 2 separate issues:

 ISSUE 1: Foo? extends Bar? is not assignable from a FooRawBar 
 where RawBar extends Bar as a raw type. That is, given:

   static class FooT {
   }

   static class BarT {
   }

   static class RawBar extends Bar {
   }

   static class SubBarT extends BarT {
   }

 Thus:

Bar? bar = new RawBar(); // works, because RawBar is a subtype
of
 
 Bar?

 But:

Foo? extends Bar? rawbar = new RawBar(); // DOES NOT WORK -
 THIS 
 IS CAUSING ONE HALF OF ALL OUR HEADACHES
 
 (correction:)
 Foo? extends Bar? rawbar = new FooRawBar(); // DOES NOT WORK
-
 
 THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES
 
 Btw, this does work (like you expect):
 Foo? extends Bar? rawbar2 = new FooSubBar?();
 
 Note that this is the issue that complete baffles me, as RawBar is a 
 subtype of Bar?, so I *really* *really* *REALLY* have no idea why
 the 
 compiler chokes on this.

 ISSUE 2: The class literal of a generic type returns a class of a raw

 type.  Thus Foo.class return ClassFoo. This is also really messed
 up, 
 because:
 
 ClassFoo fc = Foo.class;

 compiles, but generates a warning (reference to raw type). But if you

 type this in eclipse:

 x fc = Foo.class;

 and use eclipse quickfix to change x to the correct type, it'll 
 change it to precisely ClassFoo (the JLS is very short about this,
 see 
 also 


http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#1
 5.8.2). 

 So what the heck is the proper type for the class literal??? I
 couldn't 
 find any!

 Finally, note that when you define a method like this:

   static void method1(Foo? extends Bar? y) {
   }

 it works like a charm for a new FooSubBarString, i.e., the Foo
of
 
 (anything that extends (bar of anything)) really is the correct 
 interpretation.

 It's just that the interaction with raw types is completely *foobar* 
 (pun intended).

 Regards,
 Sebastiaan







 
 __
 
 The information contained in this message is proprietary and/or
confidential. If you are not the 
 intended recipient, please: (i) delete the message and all copies;
(ii) do not disclose, 
 distribute or use the message in any manner; and (iii) notify the
sender immediately. In addition, 
 please be aware that any message addressed to our domain is subject to
archiving and review by 
 persons other than the intended recipient. Thank you.
 _
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you

RE: (Class? extends Page?) casting troubles

2008-06-04 Thread Zappaterrini, Larry
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: Wednesday, June 04, 2008 8:14 AM
To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

Hi Peter,

2008/6/4 Peter Ertl [EMAIL PROTECTED]:

 I remember that having more than one wildcard in an type expression
seems
 to be inherently broken.

I hope it is not, I hope it is just hard to understand.



 Usually you can rewrite something like

  void foo(Class? extends Page? pageClass)

I think both signatures are not semanticall equal. Here there are two
wildcards. On one hand wildcards are by definition independent from each
other, but on the other hand there are coupled in this example, by the
extends. Maybe in java it was decided that the independance is more
important than the coupling.
As I read the signature the type parameter might be of any type as long
as
it extends Page parametrized with any other type.
Now when the method is used one parameter is given.
foo(Bar.class)
If Bar is a non-generic subtype of Page the compiler is happy. Either
cause
the type paramter of Page is well defined by the declaration of Bar or
the
compiler just forgets about them type parameters in an non-generic case
(I
don't know).
If Bar is a generic subtype than Bar.class is its raw type which is a
subtype of the raw type of Page, but nothing else.
So the compiler is not happy.



 into something like

  X extends Page? void foo(ClassX pageClass)

Having the wildcard in the generic type definition of the method it
relaxes
the Bounds.
Here the compiler just has to make sure that X extends a parametrized
Page
which every subtype of Page does.

@All
Is there anyone out there having a better explanation? Currently I'm
working
my way through the generics FAQ by Angelika Langer
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
I see quite some statements there that apply here, but I still can't
grab
the whole picture.



 I would bet this solves your problem :-)

 However, nobody can explain why... :-(

 Probably some lack of the generics specification, broken compiler, or
 whatever...

 I would suggest to avoid more than one wildcard in one type expression
in
 general and use above workaround.

I'm not sure about the analysis but still a good guideline.


mf














 Cheers
 Peter


 Am 04.06.2008 um 10:10 schrieb Johan Compagner:


  Yeah it is very strange that you get different errors in eclipse and
 javac.
 I wonder which one is correcct..

 But you have to generify the Page then it should work fine (like
Void)

 I think we just need to drop the ? in that example
 What do you exactly call?


 johan


 On Wed, Jun 4, 2008 at 9:39 AM, Rod Good [EMAIL PROTECTED]
wrote:

  Hi,

 I'm getting inconvertible type errors when I compile from Maven on
the
 command line with Java 6.

 Does anyone know if this issue was resolved ? I am building against
 1.4-m2 - downloaded today (04-06-2008).

 The issue is the same as noted by Ryan Mckinley on 05/21/2008 :


 strangely, things work fine for me in eclipse, but from the command

 line, I still get:


 $ mvn clean install:



/Users/ryan/Documents/workspace/dexter/website/src/java/dexter/website/
 wicket/page/DownloadingPage.java:[18,97] inconvertible types found :
 java.lang.Classdexter.website.wicket.page.account.DexSignInPage
 required: java.lang.Class? extends org.apache.wicket.Page?


 I ran: mvn clean install in the wicket directory...

 Not sure if the java version is helpful: ryan$ mvn -version Maven

 version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp

 Thanks,
 Rod.

 NOTICE
 This e-mail and any attachments are confidential and may contain
 copyright
 material of Macquarie Group Limited or third parties. If you are not
the
 intended recipient of this email you should not read, print,
re-transmit,
 store or act in reliance on this e-mail or any attachments, and
should
 destroy all copies of them. Macquarie Group Limited does not
guarantee
 the
 integrity of any emails or any attached files. The views or opinions
 expressed are the author's own and may not reflect the views or
opinions
 of
 Macquarie Group Limited.




 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.

RE: Wicket Session and non-Wicket Servlet

2008-06-03 Thread Zappaterrini, Larry
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.



From: Matthew Hanlon [mailto:[EMAIL PROTECTED]
Sent: Tue 6/3/2008 6:18 PM
To: users@wicket.apache.org
Subject: Re: Wicket Session and non-Wicket Servlet




 Check out the api for WicketSessionFilter, it will tell you how to make the
 session available for non wicket servlets.


 http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wicket/protocol/http/servlet/WicketSessionFilter.html



Yeah, that's how I had my filter and servlet configured originally.  But the
problem was that the request never seemed to be making it to the servlet,
instead the WicketFilter would pick it up and handle it.  Perhaps that is
another flaw.  So I dropped the mapping of the WicketFilter to the servlet,
and then, of course, I got my IllegalStateException.

Here's my current setup in web.xml:

filter
  filter-nameopenSessionInViewFilter/filter-name
   filter-class
  org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
   /filter-class
/filter
filter
  filter-nameWicketSessionFilter/filter-name
  filter-classorg.apache.wicket.protocol.http.WicketFilter/filter-class
  init-param
param-nameapplicationClassName/param-name

param-valuecom.alliancemanaged.simis.web.SIMISApplication/param-value
  /init-param
  init-param
param-namefilterName/param-name
param-valueReportingApplication/param-value
  /init-param
/filter
!-- Filter Mappings --
filter-mapping
  filter-nameopenSessionInViewFilter/filter-name
  url-pattern/app/*/url-pattern
/filter-mapping
filter-mapping
  filter-nameopenSessionInViewFilter/filter-name
  url-pattern/report/url-pattern
/filter-mapping
filter-mapping
  filter-nameWicketSessionFilter/filter-name
  url-pattern/app/*/url-pattern
/filter-mapping
!-- Servlet to serve up JasperReports --
servlet
  servlet-nameJasperReportServlet/servlet-name

servlet-classcom.alliancemanaged.simis.web.jasperreport.JasperReportServlet/servlet-class
load-on-startup1/load-on-startup
  /servlet
!-- Servlet to serve images for JasperReport HTML output --
servlet
  servlet-nameJasperImageServlet/servlet-name

servlet-classcom.alliancemanaged.simis.web.jasperreport.JasperImageServlet/servlet-class
  load-on-startup1/load-on-startup
/servlet
!-- Servlet Mappings --
servlet-mapping
  servlet-nameJasperReportServlet/servlet-name
  url-pattern/report/*/url-pattern
/servlet-mapping
servlet-mapping
  servlet-nameJasperImageServlet/servlet-name
  url-pattern/reportimage/*/url-pattern
/servlet-mapping

I think I got it to work correctly via the method Martijn suggested.  That's
what I had been trying to do, just couldn't figure it out.  If i understand
you correct, Martijn, this is what I'm doing:

MySession session = null;
for(IteratorString iter = Application.getApplicationKeys().iterator();
iter.hasNext();) {
String key = iter.next();
Object sess = servletRequest.getSession().getAttribute(wicket: + key +
:session);
if (sess != null  sess instanceof MySession) {
session = (MySession)sess;
break;
}
}

I'm not sure if that's the best or most robust way, but it seems to get the
job done.  If there's a better solution, please tell!

Regards,
Matthew.




 On Tue, Jun 3, 2008 at 4:30 PM, Martijn Dashorst 
 [EMAIL PROTECTED]
 wrote:

  You can't access the Wicket Session from outside a Wicket request
  using Session.get(). It is a thread local that is maintained by the
  request cycle. If it was possible in 2.0, then that was a bug and most
  certainly a security risk.
 
  You should try to look up the Wicket session in the HttpSession of
  your servlet using the session id and wicket key.
 
  Or just store the report in the http session instead.
 
  Martijn
 
  On Tue, Jun 3, 2008 at 10:21 PM, Matthew R Hanlon [EMAIL PROTECTED]
  wrote:
   Okay, I may have this all wrong, and then that's my problem.  I have an
   application that was developed under the 2.0 branch that I recently
  migrated
   to 1.4.  This application uses a servlet to handle requests for Jasper
   Reports, and under 2.0 everything worked great.  I store the report
  request
   in the user's Session, and retrieve it in the JasperReportServlet to
 look
  up
   the request.  In my JasperReportServlet I was doing:
  
  
  
   public final void doGet(final HttpServletRequest servletRequest, final
   HttpServletResponse servletResponse) throws ServletException,
 IOException
  
   {
  
String requestId =
  
 
 servletRequest.getParameter(ReportingConstants.PARAMETER_NAME_REPORT_REQUEST
   );
  
ReportRequest reportReq = null;
  
MySession session = (MySession)Session.get();
  
reportReq = session.getReportRequest(requestId);
  
  
  
// handle report request, etc.
  
   }
  
  
  
   However, in 1.4 when 

RE: users, please give us your opinion: what is your take on generics with Wicket

2008-06-02 Thread Zappaterrini, Larry
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 do you feel about your choice above?
   [X] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Wicket-Security and Wicket 1.4

2008-06-02 Thread Zappaterrini, Larry
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 proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: (Class? extends Page?) casting troubles

2008-05-21 Thread Zappaterrini, Larry
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.Voidclass to get
ClassBaseVoid in a manner similar to how you can invoke a generic
method. The type represented in the  returned by a class literal is
not generic since this information is not present at runtime. Derived
does not have this problem since it is not generic.

I am not completely sure why this plays out the way it does with the
given method signatures, but I have an idea. Derived provides the
reifiable (completely preserved at runtime) type of Void in place of T.
So when the method bad is called with Derived, ? can be inferred to be
of type Void. This is not possible with the generic type Base since T is
not reifiable and not provided by the literal Base.class. The compiler
cannot infer what ? should be. Providing X extends Base? for the
method good circumvents this conundrum. 

Looking at the messages this produces in Eclipse:

bad(Derived.class) displays on hover:
void Test.bad(Class? extends Base? clazz)

bad(Base.class) displays the error:
The method bad(Class? extends Base?) in the 
type Test is not applicable for the  arguments 
(ClassBase)

good(Derived.class) displays on hover
Derived void Test.good(ClassDerived clazz)

good(Base.class) displays on hover
Base void Test.good(ClassBase clazz)

So in the last instance the compiler infers Base for X since Base.class
returns ClassBase and is happy. Changing 

good(ClassX clazz)
to
good(Class? extends X clazz)

Should preserve the original intention of bad(Class? extends Base?
clazz). It is instructive that if you put bad(clazz) as the body of the
method good, everything compiles and runs just fine.

Sorry for the verbosity of this message. I just really wanted to try to
understand this problem and thought that some of you might be interested
in any ideas about it. I have been using the O'Reilly book Java
Generics and Collections as a guide through the murky depths of
generics and it has been most helpful.

-Original Message-
From: Peter Ertl [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 21, 2008 5:04 AM
To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

I suspect the multiple wildcards (?) in one type expression causing  
all that trouble.

probably an issue of the compiler and not of the language spec.

public class Test
{
   public static void main(String[] args)
   {
 bad(Derived.class); // ok
 bad(Base.class); // compile error
 good(Derived.class); // ok
 good(Base.class); // ok
   }

   public static void bad(Class? extends Base? clazz)
   { //  ^^ two wildcards in one expression:
 // uh oh, calling for trouble!
   }

   public static X extends Base? void good(ClassX clazz)
   {
 //
   }

   public static class BaseT
   {
   }

   public static class Derived extends BaseVoid
   {
   }
}








Am 21.05.2008 um 10:38 schrieb Gerolf Seitz:

 On Wed, May 21, 2008 at 10:30 AM, Johan Compagner
[EMAIL PROTECTED] 
 
 wrote:

 always strange that that works
 If you just look at it then it seems to be the same thing :)


 tbh, i would still like to get an explanation _why_ it works with
 S extends Component? and not directly with ? extends Component? 
 .

  Gerolf

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: How to strip wicket tags from markup in development mode?

2008-05-21 Thread Zappaterrini, Larry
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 easy way to strip the wicket tags from the produced markup 
while keeping the application in development mode?

I'm finding the development of a Facebook FBML app pretty painful, as 
wicket:* are ignored by Facebook and result in error messages. With 
deployment configuration I get around this, but then I run into a lot of

Internal error pages which aren't very helpful.

Thanks

--
LL

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Wicket java.lang.IllegalAccessError bug?

2008-05-19 Thread Zappaterrini, Larry
I can't get the ternary statement you provided to compile correctly
using 1.4-M1. The error I get is:

The type AbstractChoiceT,E is not visible

Due to the fact that the common ancestor for ListMultipleChoice and
ListChoice is the inaccessible package protected object AbstractChoice.
This is caused by the behavior of ternary assignment where, if the
second and third operands are of different reference types, then it must
be possible to convert one of the types to the other type (call this
latter type T) by assignment conversion; the type of the conditional
expression is T. It is a compile-time error if neither type is
assignment compatible with the other type. This is copied verbatim from

http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.h
tml#290293

Casting one of the new statements to FormComponent allows the statement
to compile and run without error for me:

FormComponent o = false
? (FormComponent) new ListMultipleChoice(,
new Model(), Collections.EMPTY_LIST, (IChoiceRenderer) null)
: new ListChoice(,
new Model(), Collections.EMPTY_LIST, (IChoiceRenderer)
null).setNullValid(true);

I imagine it may correct the runtime error you are seeing too.

-Original Message-
From: Martin Makundi [mailto:[EMAIL PROTECTED] 
Sent: Sunday, May 18, 2008 3:56 AM
To: users@wicket.apache.org
Subject: Re: Wicket java.lang.IllegalAccessError bug?

Yap. If you rephrase it into ifs (or change ternary false state into
true) it works fine.

**
Martin

2008/5/18 Johan Compagner [EMAIL PROTECTED]:
 I have no idea what could cause that suddenly in 1.4
 Maybe something that java 5 source compiler does?
 But a simple if works fine?

 On 5/17/08, Martin Makundi [EMAIL PROTECTED] wrote:
 Hi!

 I just upgraded from 1.3.1 to 1.4-m1 and I received the strangest of
errors.

 Has anyone had the same experience below? This occurs only with the
 ternary operator, probably because both elements get initialized at
 runtime:

 public class AnyPage extends WebPage {

 public AnyPage() {
 // I wanted to use a ternary operator to choose between rendering
 a listchoice or a multiplelistchoice.
 // This worked in 1.3.1 but not in 1.4-m1 anymore. The JVM used
is
 1.6.0_04 with jetty 6.1.0

// 

 Object o = false
 ? new ListMultipleChoice(,
 new Model(), Collections.EMPTY_LIST, (IChoiceRenderer) null)
 : new ListChoice(,
 new Model(), Collections.EMPTY_LIST, (IChoiceRenderer)
 null).setNullValid(true);

// 
   }
 }

 Throws a nasty exception:

 2008-05-17 16:57:23,531 67447 [btpool0-8] ERROR RequestCycle  - Can't
 instantiate page using constructor public wicket.quickstart.AnyPage()
 org.apache.wicket.WicketRuntimeException: Can't instantiate page
using
 constructor public wicket.quickstart.AnyPage()
   at

org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.
java:168)
   at

org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.
java:58)
   at

org.apache.wicket.request.target.component.BookmarkablePageRequestTarget
.newPage(BookmarkablePageRequestTarget.java:262)
   at

org.apache.wicket.request.target.component.BookmarkablePageRequestTarget
.getPage(BookmarkablePageRequestTarget.java:283)
   at

org.apache.wicket.request.target.component.BookmarkablePageRequestTarget
.processEvents(BookmarkablePageRequestTarget.java:210)
   at

org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(Ab
stractRequestCycleProcessor.java:91)
   at

org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java
:1174)
   at org.apache.wicket.RequestCycle.step(RequestCycle.java:1251)
   at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1352)
   at
org.apache.wicket.RequestCycle.request(RequestCycle.java:499)
   at

org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:375
)
   at

org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:1
24)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
   at

wicket.quickstart.SessionLeakWorkaroundServlet.service(SessionLeakWorkar
ound.java:57)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
   at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
   at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
   at

org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:1
85)
   at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
   at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
   at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
   at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
   at org.mortbay.jetty.Server.handle(Server.java:285)
   at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
   at


RE: MarkupNotFoundException

2008-05-09 Thread Zappaterrini, Larry
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: MarkupNotFoundException


Hi.

I have a class IpLookupPage that uses markupinheritence and inherits a
class
called BasePage. I is working fine when i test it manually but when i am
using testng to do unit testing on the page i get an exception.

The code looks like:
ApplicationContext context = getStubApplicationContextForPage();
BossoWicketTester app = createWicketTester(context);

app.openPage(IpLookupPage.class);

And i get this error message:

org.apache.wicket.markup.MarkupNotFoundException: Markup of type 'html'
for
component 'com.ongame.bo.bofraud.markup.pages.IpLookupPage' not found.
Enable debug messages for org.apache.wicket.util.resource to get a list
of
all filenames tried:
 [Page class = com.ongame.bo.bofraud.markup.pages.IpLookupPage, id = 0,
version = 0]
 at
org.apache.wicket.MarkupContainer.getAssociatedMarkupStream(MarkupContai
ner.java:354)
 at org.apache.wicket.Page.onRender(Page.java:1435)
 at org.apache.wicket.Component.render(Component.java:2266)
 at org.apache.wicket.Page.renderPage(Page.java:891)
 at
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget
.respond(BookmarkablePageRequestTarget.java:231)
 at
org.apache.wicket.request.AbstractRequestCycleProcessor.respond(Abstract
RequestCycleProcessor.java:103)
 at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java
:1100)
 at org.apache.wicket.RequestCycle.step(RequestCycle.java:1169)
 at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1245)
 at org.apache.wicket.RequestCycle.request(RequestCycle.java:489)
 at
org.apache.wicket.protocol.http.MockWebApplication.processRequestCycle(M
ockWebApplication.java:382)
 at
com.ongame.bo.bofraud.WicketApplicationTest$BossoWicketTester.openPage(W
icketApplicationTest.java:101)
 at
com.ongame.bo.bofraud.markup.pages.IpLookupPageTest.testInvalidIpAddress
(IpLookupPageTest.java:68)
 Caused by: org.apache.wicket.markup.MarkupNotFoundException: Markup not
found. Component class: com.ongame.bo.bofraud.markup.pages.IpLookupPage
Enable debug messages for org.apache.wicket.util.resource to get a list
of
all filenames tried
 at
org.apache.wicket.markup.MarkupCache.getMarkupStream(MarkupCache.java:21
5)
 at
org.apache.wicket.MarkupContainer.getAssociatedMarkupStream(MarkupContai
ner.java:342)
 ... 33 more
 ... Removed 21 stack frames


Anyone that knows what the problem is?

Regards 
Alex
-- 
View this message in context:
http://www.nabble.com/MarkupNotFoundException-tp17142219p17142219.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Wicket and Eclipse WTP

2008-05-07 Thread Zappaterrini, Larry
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.

-Original Message-
From: John Krasnay [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 07, 2008 2:22 PM
To: users@wicket.apache.org
Subject: Wicket and Eclipse WTP

I've recently switched from the Sysdeo Tomcat plugin for Eclipse to WTP
for running my Tomcat instance. I'm trying to get to a point where when
I change a .html or .properties file it just shows up without
re-deploying the whole web context. It seems that if I change a file
under src/main/webapp it's silently deployed with no fuss, but if
anything changes in the classpath, including say a Wicket .html file,
WTP feels the need to re-deploy the whole context.

Has anyone had any success working around this?

jk

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Removing the jsessionid for SEO

2008-04-03 Thread Zappaterrini, Larry
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=35769#desi
gn 

It specifically recommends allow(ing) search bots to crawl your sites
without session IDs or arguments that track their path through the
site.

-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 03, 2008 7:35 AM
To: users@wicket.apache.org
Subject: Re: Removing the jsessionid for SEO

isnt google always saying that you shouldn't alter behavior of your site
depending of it is there bot or not?

On Thu, Apr 3, 2008 at 1:00 PM, Artur W. [EMAIL PROTECTED] wrote:


 Hi!


 igor.vaynberg wrote:
 
  also by doing what you have done users with cookies disabled wont be
  able to use your site...
 

 In my opinion session id is a problem. Google index the same page
again
 and
 again.

 About the users without cookies we can do like this:


static class Unbuffered extends WebResponse {

 private static final String[] botAgents = {
onetszukaj,
 googlebot,
 appie, architext,
jeeves, bjaaland, ferret, gulliver,
 harvest, htdig,
linkwalker, lycos_, moget,
muscatferret,
 myweb, nomad,
 scooter,
yahoo!\\sslurp\\schina, slurp, weblayers,
 antibot, bruinbot,
 digout4u,
echo!, ia_archiver, jennybot, mercator,
 netcraft, msnbot,
 petersnews,
unlost_web_crawler, voila, webbase,
 webcollage, cfetch,
 zyborg,
wisenutbot, robot, crawl, spider }; /*
and
 so on... */

public Unbuffered(final HttpServletResponse res) {
super(res);
 }

@Override
public CharSequence encodeURL(final CharSequence url) {
 return isAgent() ? url : super.encodeURL(url);
}

private static boolean isAgent() {

String agent =


((WebRequest)RequestCycle.get().getRequest()).getHttpServletRequest().ge
tHeader(User-Agent);

for(String bot : botAgents) {
if (agent.toLowerCase().indexOf(bot) !=
-1)
 {
return true;
}
}

return false;
}
}


 I didn't test this code but I do similar thing in my old application
in
 Spring and it works.

 Take care,
 Artur


 --
 View this message in context:

http://www.nabble.com/Removing-the-jsessionid-for-SEO-tp16464534p1646739
6.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Double submit problem

2008-03-25 Thread Zappaterrini, Larry
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 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 of tokens. However Maurice's implementation
looked correct to me short of actually testing it out. I formerly used
Struts 1.2 and it has a similar feature that I've used successfully.

Your last point is valid. Using the back button could get tricky with
using a token. I'm not familiar with how Wicket handles back button
support, but I imagine there would be a nice way to integrate token
usage. Not all forms would require tokens. But for some critical forms
you might desire the integrity that a token provides. For a back button
click, you would have to interact with the user about their intentions.

I'm thinking specifically of something like a bank account transfer.
Using a token prevents CSRF and double submits. If the user clicks back
and tries to submit again, you would probably want to get verification
from them that they do in fact want to process the request again, or
just force them to start over possibly.

-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 25, 2008 10:36 AM
To: users@wicket.apache.org
Subject: Re: Double submit problem

do you have a good patch then?

And are you saying that all double submits are then not possible
anymore?

Also when i submit then think hmm thats wrong back button change
something
and submit again?



On Tue, Mar 25, 2008 at 3:25 PM, laz [EMAIL PROTECTED] wrote:


 Does anyone else feel that this would be generically useful to have as
a
 part
 of Wicket? Not only does it prevent double submits, but it also is a
 simple
 safeguard against cross-site request forgery (see
 http://en.wikipedia.org/wiki/Cross-site_request_forgery for a
summary).

 The one missing piece from your solution is synchronization. There is
the
 slightest possibility that the second submit of a double submit could
 enter
 onSubmit before the token is reset. I am not yet sure what would be
the
 best
 object to synchronize on, possibly the session id?



 hillj2 wrote:
 
  Here's a solution that SEEMS to be working.  It incorporates our
 solution
  to the double submit problem that we used on our JSP's.  It didn't
 appear
  to be working for me at first, but seems to be now.  (It does use
the
 old
  servlet request/session objects, but this may change once all our
old
 code
  is upgraded to wicket.)
 
  ...
 
  Like I said, for now this appears to be working.  I just extend all
my
  forms from this class and implement onSubmitted() with the same code
I
  previously put in onSubmit().  The key is putting matching unique
 strings
  in session and in the page instance.  On submit, those string should
  match, at which point, the string in session is cleared and the form
is
  processed as normal.  If another submit comes in, the string in
session
  has been cleared so it doesn't match the string svaed in the page
  instance.  In the case where setResponsePage is not called,
 onBeforeRender
  resets the token string, so submitting from the refreshed page won't
  register as an error.
 
  Our JSP version of this involves putting the token string in session
and
  also saving a copy to a hidden field on the JSP page.  Which I think
is
  similar (although maybe a bit more complex) to what Martijn was
  suggesting.
 
  Thanks for all you suggestions.
 
  Joel
 

 --
 View this message in context:
 http://www.nabble.com/Double-submit-problem-tp15957979p16275106.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



__

The information contained in this message is proprietary and/or
confidential. If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii)
do not disclose, 
distribute or use the message in any manner; and (iii) notify the sender
immediately. In addition, 
please be aware that any message addressed to our domain is subject to
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute

RE: Suggested Enhancement To Spring Support

2008-03-20 Thread Zappaterrini, Larry
I suppose I need to learn more about how Spring support is implemented in 
Wicket. My thinking was that the injected property would simply get set to 
null. Then the getter for that injected property can perform a null check and 
lazily initialize it with a default type if necessary:
 
@SpringBean(name = someService)
private Service service;
 
public Service getService() {
if (service == null) {
service = new DefaultService();
}
return service;
}
 
This allows for default implementation to be provided that can then be 
overridden by declaring the bean in Spring. I've used this type of pattern with 
Spring in other settings and thought it might be useful in Wicket too.



From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Wed 3/19/2008 5:49 PM
To: users@wicket.apache.org
Subject: Re: Suggested Enhancement To Spring 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
  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 error when I don't define the object in the XML:

  org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean
  named 'beanName' is defined
  at
  org.springframework.beans.factory.support.DefaultListableBeanFactory.get
  BeanDefinition(DefaultListableBeanFactory.java:355)
  at
  org.springframework.beans.factory.support.AbstractBeanFactory.getMergedB
  eanDefinition(AbstractBeanFactory.java:800)
  at
  org.springframework.beans.factory.support.AbstractBeanFactory.isSingleto
  n(AbstractBeanFactory.java:343)
  at
  org.springframework.context.support.AbstractApplicationContext.isSinglet
  on(AbstractApplicationContext.java:654)
  at
  org.apache.wicket.spring.SpringBeanLocator.isSingletonBean(SpringBeanLoc
  ator.java:133)
  at
  org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactory.get
  FieldValue(AnnotProxyFieldValueFactory.java:91)
  at org.apache.wicket.injection.Injector.inject(Injector.java:108)
  at
  org.apache.wicket.injection.ConfigurableInjector.inject(ConfigurableInje
  ctor.java:39)
  at
  org.apache.wicket.injection.ComponentInjector.onInstantiation(ComponentI
  njector.java:52)
  at
  org.apache.wicket.Application.notifyComponentInstantiationListeners(Appl
  ication.java:973)
  at org.apache.wicket.Component.init(Component.java:866)

  ... truncated for brevity

  Using getSpringContext().contains(String) either within or as an exposed
  method of SpringBeanLocator would probably be sufficient to avoid
  hitting this exception.

  Thanks,
  Larry

  __

  The information contained in this message is proprietary and/or 
 confidential. If you are not the
  intended recipient, please: (i) delete the message and all copies; (ii) do 
 not disclose,
  distribute or use the message in any manner; and (iii) notify the sender 
 immediately. In addition,
  please be aware that any message addressed to our domain is subject to 
 archiving and review by
  persons other than the intended recipient. Thank you.
  _

  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

RE: Suggested Enhancement To Spring Support

2008-03-20 Thread Zappaterrini, Larry
Thanks for the explanation, that makes perfect sense.



From: lars vonk [mailto:[EMAIL PROTECTED]
Sent: Thu 3/20/2008 10:16 AM
To: users@wicket.apache.org
Subject: Re: Suggested Enhancement To Spring Support



Spring support in Wicket works with proxies, so your services are not
Serialized by Wicket, but your Proxy is. With your suggestion your Service
will be Serialized and with it all its dependencies like DAO's etc. This
will most likely cause trouble when you are in a clustered environment and
use Session replication.

Also using this approach 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 thinking was that the injected property would simply get set to
 null. Then the getter for that injected property can perform a null check
 and lazily initialize it with a default type if necessary:

 @SpringBean(name = someService)
 private Service service;

 public Service getService() {
if (service == null) {
service = new DefaultService();
}
return service;
 }

 This allows for default implementation to be provided that can then be
 overridden by declaring the bean in Spring. I've used this type of pattern
 with Spring in other settings and thought it might be useful in Wicket too.

 

 From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
 Sent: Wed 3/19/2008 5:49 PM
 To: users@wicket.apache.org
 Subject: Re: Suggested Enhancement To Spring 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
   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 error when I don't define the object in the XML:
 
   org.springframework.beans.factory.NoSuchBeanDefinitionException: No
 bean
   named 'beanName' is defined
   at
 
 org.springframework.beans.factory.support.DefaultListableBeanFactory.get
   BeanDefinition(DefaultListableBeanFactory.java:355)
   at
 
 org.springframework.beans.factory.support.AbstractBeanFactory.getMergedB
   eanDefinition(AbstractBeanFactory.java:800)
   at
 
 org.springframework.beans.factory.support.AbstractBeanFactory.isSingleto
   n(AbstractBeanFactory.java:343)
   at
 
 org.springframework.context.support.AbstractApplicationContext.isSinglet
   on(AbstractApplicationContext.java:654)
   at
   org.apache.wicket.spring.SpringBeanLocator.isSingletonBean
 (SpringBeanLoc
   ator.java:133)
   at
 
 org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactory.get
   FieldValue(AnnotProxyFieldValueFactory.java:91)
   at org.apache.wicket.injection.Injector.inject(Injector.java:108)
   at
   org.apache.wicket.injection.ConfigurableInjector.inject
 (ConfigurableInje
   ctor.java:39)
   at
   org.apache.wicket.injection.ComponentInjector.onInstantiation
 (ComponentI
   njector.java:52)
   at
   org.apache.wicket.Application.notifyComponentInstantiationListeners
 (Appl
   ication.java:973)
   at org.apache.wicket.Component.init(Component.java:866)
 
   ... truncated for brevity
 
   Using getSpringContext().contains(String) either within or as an
 exposed
   method of SpringBeanLocator would probably be sufficient to avoid
   hitting this exception.
 
   Thanks,
   Larry
 
   __
 
   The information contained in this message is proprietary and/or
 confidential. If you are not the
   intended recipient, please: (i) delete the message and all copies; (ii)
 do not disclose,
   distribute or use the message in any manner; and (iii) notify the
 sender immediately. In addition,
   please be aware that any message addressed to our domain is subject to
 archiving and review by
   persons other than the intended recipient. Thank you.
   _
 
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 __

 The information contained in this message is proprietary and/or
 confidential. If you are not the
 intended recipient, please: (i) delete the message and all copies; (ii) do
 not disclose,
 distribute or use the message in any manner; and (iii) notify the sender
 immediately. In addition,
 please be aware that any message addressed

Creating Custom Form Components

2008-03-19 Thread Zappaterrini, Larry
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 the originator of the mailing list thread was trying to
encapsulate the behavior of a TextField within a Panel and needed to
have final removed from the method add(IBehavior). This was needed so
that the Panel could delegate the call to the TextField. In the end the
final restriction was removed.

I am currently trying to do something similar to the original author and
am wondering why the same concession isn't extended to add(IValidator)
in FormComponent? I am trying to create a component that encapsulates a
label/input pair in a form and my initial approach was to create a
subclass of FormComponentPanel. It would be nice if calls to
add(IValidator) on that object could be delegated to its input member.

As an aside, I can see two approaches to accomplishing what I want in
general. The first is the direction I have been pursuing. I am
leveraging Wicket's component model so that the markup for this
component is entirely contained in one HTML file for ease of reuse and
customizability. The fact that add(IValidator) is final has made that
option more complex. The other approach would be to have a helper or
builder that takes the Form object and adds the Components to it. The
downside of that approach is that there is no centralized markup file
representing the label/input pair.

What approaches have Wicket users taken to accomplish similar tasks?

Thanks,
Larry

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Suggested Enhancement To Spring Support

2008-03-19 Thread Zappaterrini, Larry
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 error when I don't define the object in the XML:

org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean
named 'beanName' is defined
 at
org.springframework.beans.factory.support.DefaultListableBeanFactory.get
BeanDefinition(DefaultListableBeanFactory.java:355)
 at
org.springframework.beans.factory.support.AbstractBeanFactory.getMergedB
eanDefinition(AbstractBeanFactory.java:800)
 at
org.springframework.beans.factory.support.AbstractBeanFactory.isSingleto
n(AbstractBeanFactory.java:343)
 at
org.springframework.context.support.AbstractApplicationContext.isSinglet
on(AbstractApplicationContext.java:654)
 at
org.apache.wicket.spring.SpringBeanLocator.isSingletonBean(SpringBeanLoc
ator.java:133)
 at
org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactory.get
FieldValue(AnnotProxyFieldValueFactory.java:91)
 at org.apache.wicket.injection.Injector.inject(Injector.java:108)
 at
org.apache.wicket.injection.ConfigurableInjector.inject(ConfigurableInje
ctor.java:39)
 at
org.apache.wicket.injection.ComponentInjector.onInstantiation(ComponentI
njector.java:52)
 at
org.apache.wicket.Application.notifyComponentInstantiationListeners(Appl
ication.java:973)
 at org.apache.wicket.Component.init(Component.java:866)

... truncated for brevity

Using getSpringContext().contains(String) either within or as an exposed
method of SpringBeanLocator would probably be sufficient to avoid
hitting this exception.

Thanks,
Larry

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: downloading Wicket examples

2008-03-13 Thread Zappaterrini, Larry
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 examples at:

http://wicketstuff.org/wicket13/

You can browse the source code, but not all classes are there (e.g
WicketExampleApplication). Where can I download jar or zip files of the
sources for these examples?

Thanks

___

The  information in this email or in any file attached
hereto is intended only for the personal and confiden-
tial  use  of  the individual or entity to which it is
addressed and may contain information that is  propri-
etary  and  confidential.  If you are not the intended
recipient of this message you are hereby notified that
any  review, dissemination, distribution or copying of
this message is strictly prohibited.  This  communica-
tion  is  for information purposes only and should not
be regarded as an offer to sell or as  a  solicitation
of an offer to buy any financial product. Email trans-
mission cannot be guaranteed to be  secure  or  error-
free. P6070214

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Authentication and Assigning a Session Id

2008-03-10 Thread Zappaterrini, Larry
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 HTTP sessions directly you can 
copy the session contents, invalidate the session, request a new session, and 
put the contents of the original session into the new one. I've browsed through 
some of Wicket's source code to see if this is easily accomplished but I 
haven't been able to figure it out. Does anyone have any input or suggestions?
 
Thanks,
Larry
 

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

RE: Authentication and Assigning a Session Id

2008-03-10 Thread Zappaterrini, Larry
While it is true that the jsessionid token is not controlled by application 
code, you can request a new one be generated by calling invalidate on the 
session then request a new session by calling getSession(true) on the request 
as I mentioned in my original message. Essentially it creates the illusion of 
one contiguous session to the user when it is actually two different sessions. 
I suppose I could attempt to do the same thing from within my application code 
in Wicket and use the HTTP request to accomplish it. I was just hoping to 
preserve Wicket's approach of treating HTTP as an implementation detail and not 
having to include any references to it in my code.



From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Mon 3/10/2008 4:24 PM
To: users@wicket.apache.org
Subject: Re: Authentication and Assigning a Session Id



yes, if all that is true. but you still do not control the jsessionid token...

-igor


On Mon, Mar 10, 2008 at 1:21 PM, Maurice Marrink [EMAIL PROTECTED] wrote:
 Igor,

  I thought that as long as you only use stateless pages and don't throw
  RestartResponseExceptions the http session remained temporary (as
  in is not assigned an id).

  Anyway Wicket-Security automatically binds the wicket session (assigns
  id to http session) after a successful login, if the session is not
  already bound. But there is no guarantee that the session is not bound
  until then.

  Maurice



  On Mon, Mar 10, 2008 at 9:01 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
   session management is handled by the servlet container and is outside
wicket's control. perhaps you can use a cookie in conjunction with 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 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 HTTP 
 sessions directly you can copy the session contents, invalidate the session, 
 request a new session, and put the contents of the original session into the 
 new one. I've browsed through some of Wicket's source code to see if this is 
 easily accomplished but I haven't been able to figure it out. Does anyone 
 have any input or suggestions?

  Thanks,
  Larry


  __

  The information contained in this message is proprietary and/or 
 confidential. If you are not the
  intended recipient, please: (i) delete the message and all copies; 
 (ii) do not disclose,
  distribute or use the message in any manner; and (iii) notify the 
 sender immediately. In addition,
  please be aware that any message addressed to our domain is subject to 
 archiving and review by
  persons other than the intended recipient. Thank you.
  _
  
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
  
  

  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Authentication and Assigning a Session Id

2008-03-10 Thread Zappaterrini, Larry
That was my initial inclination, but I don't see an easy way to get the data 
out of the session, request a new session, then populate the new session with 
the original data.

 


From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Mon 3/10/2008 6:00 PM
To: 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 controlled by application 
 code, you can request a new one be generated by calling invalidate on the 
 session then request a new session by calling getSession(true) on the request 
 as I mentioned in my original message. Essentially it creates the illusion of 
 one contiguous session to the user when it is actually two different 
 sessions. I suppose I could attempt to do the same thing from within my 
 application code in Wicket and use the HTTP request to accomplish it. I was 
 just hoping to preserve Wicket's approach of treating HTTP as an 
 implementation detail and not having to include any references to it in my 
 code.

  

  From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
  Sent: Mon 3/10/2008 4:24 PM
  To: users@wicket.apache.org
  Subject: Re: Authentication and Assigning a Session Id





  yes, if all that is true. but you still do not control the jsessionid 
 token...

  -igor


  On Mon, Mar 10, 2008 at 1:21 PM, Maurice Marrink [EMAIL PROTECTED] wrote:
   Igor,
  
I thought that as long as you only use stateless pages and don't throw
RestartResponseExceptions the http session remained temporary (as
in is not assigned an id).
  
Anyway Wicket-Security automatically binds the wicket session (assigns
id to http session) after a successful login, if the session is not
already bound. But there is no guarantee that the session is not bound
until then.
  
Maurice
  
  
  
On Mon, Mar 10, 2008 at 9:01 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
 session management is handled by the servlet container and is outside
  wicket's control. perhaps you can use a cookie in conjunction with 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 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 HTTP 
 sessions directly you can copy the session contents, invalidate the session, 
 request a new session, and put the contents of the original session into the 
 new one. I've browsed through some of Wicket's source code to see if this is 
 easily accomplished but I haven't been able to figure it out. Does anyone 
 have any input or suggestions?
  
Thanks,
Larry
  
  
__
  
The information contained in this message is proprietary and/or 
 confidential. If you are not the
intended recipient, please: (i) delete the message and all copies; 
 (ii) do not disclose,
distribute or use the message in any manner; and (iii) notify the 
 sender immediately. In addition,
please be aware that any message addressed to our domain is subject 
 to archiving and review by
persons other than the intended recipient. Thank you.
_

  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]


  
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
  
  

  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]



  __

  The information contained in this message is proprietary and/or 
 confidential. If you are not the
  intended recipient, please: (i) delete the message and all copies; (ii) do 
 not disclose,
  distribute or use the message in any manner; and (iii) notify the sender 
 immediately. In addition,
  please be aware that any message addressed to our domain is subject to 
 archiving and review by
  persons other than the intended recipient. Thank you.
  _

 -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED