RE: CSRF Protection: double submitted cookie
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 s
RE: WicketSessionFilter Problem: java.lang.IllegalStateException
One more suggestion is to declare the filter so that it is invoked when request dispatcher methods are called: WicketSessionFilter *.do REQUEST INCLUDE I'm not sure if that is what is happening in this situation, but it might be worth a shot. -Original Message- From: James 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.pharmisis >>> org.apache.wicket.protocol.http.WicketFilter >>> >>>applicationClassName >>> com.mypharmisis.pages.PharmisisApplication >>> >>> >>> >>> >>>WicketSessionFilter >>> org.apache.wicket.protocol.http.servlet.WicketSessionFilte r >>> >>>filterName >>>wicket.pharmisis >>> >>> >>> >>> >>>wicket.pharmisis >>>/secure/new/* >>> >>> >>> >>>WicketSessionFilter >>>*.do >>> >>> >>> >>> >>> >>> >>>javax.servlet.jsp.jstl.fmt.localizationContext >>> >>> >>>com.mypharmisis.isis.ApplicationResources >>> >>> >>> >>> >>>crystal_image_uri >>>/isis2/crystalreportviewers11 >>> >>> >>> >>> >>> com.mypharmisis.struts.isis.framework.IsisContextListene r >>> >>> >>> >>>action >>> org.apache.struts.action.ActionServlet >>> >>> >>>config >>>/WEB-INF/struts-config.xml >>> >>> >>>debug >>>true >>> >>> >>>detail >>>9 >>> >>> >>>nocache >>>true >>> >>> >>>validate >>>true >>> >>> >>>1 >>> >>> >>> >>> >>> >>> >>>dwr-invoker >>>DWR Servlet >>> org.directwebremoting.servlet.DwrServlet >>> >>>debug >>>true >>> >>> >>> >>> >>> >>> >>>action >>>*.do >>> >>> >>> >>>dwr-invoker >>>/dwr/* >>> >>> >>> >>> >>>index.jsp >>> >>> >>> >>>400 >>>/isisErrorAction.do?code=400 >>> >>> >>> >>>404 >>>/isisErrorAction.do?code=404 >>> >>> >>> >>>500 >>>/isisErrorAction.do?code=500 >>> >>> >>> >>> >>> >>> >>> >>>/WEB-INF/struts-bean.tld >>>/WEB-INF/struts-bean.tld >>> >>> >>>/WEB-INF/struts-html.tld >>>/WEB-INF/struts-html.tld >>> >>> >>>/WEB-INF/struts-logic.tld >>>/WEB-INF/struts-logic.tld >>> >>> >>>/WEB-INF/struts-template.tld >>> /WEB-INF/struts-template.tld >>> >>> >>>/WEB-INF/struts-tiles.tld >>>/WEB-INF/struts-tiles.tld >>> >>> >>>/WEB-INF/sslext.tld >>>/WEB-INF/sslext.tld >>> >>> >>> >>> >>> >
RE: Strict 4 digit year for DateTextField?
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?
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: passing objects between pages
Regarding IModel and IModel, you could create subclasses to represent them and then you can have two different constructors. class GroupModel extends IModel class UserModel extends IModel then Constructor(GroupModel model) Constructor(UserModel model) Will work. -Original Message- From: John [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2008 7:51 AM To: users@wicket.apache.org Subject: Re: passing objects between pages hi Igor, i do have a detachable Group model so am now passing that into my CreateUser page - thank you that is a very interesting point regarding serialization... thank you for mentioning it! i will have to bear that in mind. as i understand generics, the generic identity is lost at run time so you cannot have two constructors accepting different IModels like IModel and IModel. is there an obvious way around this that i have not spotted? my CreateUser page is also an edit page... as the code is exactly the same i am reusing it... but a create would pass a IModel but an edit would pass IModel, but it cannot!!! i have passed in the user id instead, and am loading it manually inside the page even though i already have the User object inside a detachable model when i make the Link to the edit page. does this sound correct? hi Thomas, those are good rules! i have written many pages with ids being used in Links, so for easy access to the object inside the model, i have creating final references to the model object at the start of the constructor... and then just calling myobject.getId() where needed. i am concerned that this might break your second rule, as the object inside the model may not be the same i think? i have read that for example new Label(myObject.getName()) is bad because the Label will be fixed as the name when the page was first constructed, but it will not change if the name changes but the page is redisplayed. however i have a gap in my understanding regrding redisplay of the page... when does a page get redisplayed? a page that displays a School information can not be re used for a different School i think as the IModel or School id will be passed to the page constructor. so it will only be displayed for the one School... does that mean that the School object that is inside the model on the page will always be the same or will that object change when the model is detached and reattached? so my final reference to the School object is a bad bad thing? also... when you view a different School does the first page still exist? i can see the first page can not be reused if i click a link to view the first School that is passing a IModel into the constructor, but if I pass the School id number via a PageParameters will Wicket reuse a page if the PageParameters match? john... On Tue, Jul 22, 2008 at 9:41 AM, Thomas Mäder <[EMAIL PROTECTED]> wrote: > I have three rules for directly referencing objects from pages > > 1) It's serializable > 2) The valueis not going to change from the time I construct the page > to when I use the object > 3) It doesn't matter if I get a copy of the object (because of > deserialization). > > 2 & 3 can be summarized as the object being a value object > > Thomas > > > On Mon, Jul 21, 2008 at 6:25 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: >> the easiest thing to do is to pass the imodel into the second >> page. i assume you already have a detachable group model that you are >> using to list users, so just pass it to the next page. >> >> in general keeping references to objects is safe for as long as the >> objects them selves are valid. the problem with hibernate objects is >> that although you have a reference that you can keep forever, the >> object's lifecycle is not tied to that reference. the object is tied >> to the session whose scope is usually a request, so the object itself >> is only valid during the request, which is why you have to use >> loadable detachable models. >> >> if you had an object that is not tied to any kind of lifecycle you >> could keep a reference indefinetely. >> >> once you start talking about objects that live across pages you run >> into another issue. wicket serializes each page individually. that >> means if you pass a reference to an object from page A to page B, page >> B will end up with a clone and change made to that object inside page >> B will not be visible to page A. something to keep in mind. this is >> not a problem for multiple references to an object within a page >> because serialization will properly keep track of multiple references >> to the same object. >> >> clears things up? >> >> -igor >> >> On Mon, Jul 21, 2008 at 9:10 AM, John <[EMAIL PROTECTED]> wrote: >>> hi, i am writing an application, but don't know how best to write it >>> in wicket. i can see lots of different ways to approach my problem >>> and would appreciate some direction as to which approach is the most >>> appropiate. i have read the documentation in the wiki regarding >>> models and unders
RE: Spring injection not working
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: New Wicket Grails Plug-in Available + about the Groovy wicket builder
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: why are we coding Web apps?
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
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: 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 > Receive
RE: Tomcat 6 clustering problem
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) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived( ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived( ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(Chan nelCoordinator.java:241) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(Re ceiverBase.java:225) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel (NioReplicationTask.java:188) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioRepli cationTask.java:91) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecuto r.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja va:907) at java.lang.Thread.run(Thread.java:619) Is there a way to resolve this issue? -- View this message in context: http://www.nabble.com/Tomcat-6-clustering-problem-tp18112263p18112263.ht ml 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 (ii
RE: generics
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 T 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 T 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
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.pu
RE: Session end method
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 ter
RE: Session end method
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
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: Is it safe to share static components across multiple page instances and request threads?
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: 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: Session end method
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: Making Component easier to Generify
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: Making Component easier to Generify
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 >>> Callable? >>> >>> 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 Callable instead of >>> T, so >>> for example setVisible(boolean) would become >>> setVisible(Callable) >>> >>> 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 Callable for constant values, such as >>> Callable.valueOf(true) would >>> return a Callable 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: (Class>) casting troubles
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 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 FormComponent and the Class argument becomes Class> (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>) 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 > Class 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 Foo 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>) 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 > to a Foo> 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 Class 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>) 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>) casting troubles >>> >>> ARgh, you always make typos
RE: (Class>) casting troubles
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
Class clazz = Foo.class?
Cheers,
Larry
-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 07, 2008 3:57 AM
To: users@wicket.apache.org
Subject: Re: (Class>) casting troubles
Zappaterrini, Larry wrote:
> Sorry, I 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
to a Foo> 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 Class 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>) 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>) casting troubles
>>
>> ARgh, you always make typos with this stuff.
>>
>> See correction.
>>
>> Sebastiaan van Erk wrote:
>>> Martin Funk wrote:
>>>
>>>>> Class> means "class of (anything that extends
>> (page of
>>>>> anything))".
>>>> I'm not so sure.
>>> There are 2 separate issues:
>>>
>>> ISSUE 1: Foo> is not assignable from a Foo
>>> where RawBar extends Bar as a raw type. That is, given:
>>>
>>> static class Foo {
>>> }
>>>
>>> static class Bar {
>>> }
>>>
>>> static class RawBar extends Bar {
>>> }
>>>
>>> static class SubBar extends Bar {
>>> }
>>>
>>> Thus:
>>>
>>>Bar bar = new RawBar(); // works, because RawBar is a subtype
> of
>>> Bar
>>>
>>> But:
>>>
>>>Foo> rawbar = new RawBar(); // DOES NOT WORK -
>> THIS
>>> IS CAUSING ONE HALF OF ALL OUR HEADACHES
>> (correction:)
>> Foo> rawbar = new Foo(); // DOES NOT
WORK
> -
>> THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES
>>
>> Btw, this does work (like you expect):
>> Foo> rawbar2 = new Foo>();
>>
>>> 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 Class. This is also really messed
>> up,
>>> because:
>>>
>>> Class fc = Foo.class;
>>>
>>> compiles, but generates a wa
RE: (Class>) casting troubles
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>) 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>) casting troubles
>
> ARgh, you always make typos with this stuff.
>
> See correction.
>
> Sebastiaan van Erk wrote:
>> Martin Funk wrote:
>>
>>>> Class> means "class of (anything that extends
> (page of
>>>> anything))".
>>> I'm not so sure.
>> There are 2 separate issues:
>>
>> ISSUE 1: Foo> is not assignable from a Foo
>> where RawBar extends Bar as a raw type. That is, given:
>>
>> static class Foo {
>> }
>>
>> static class Bar {
>> }
>>
>> static class RawBar extends Bar {
>> }
>>
>> static class SubBar extends Bar {
>> }
>>
>> Thus:
>>
>>Bar bar = new RawBar(); // works, because RawBar is a subtype
of
>
>> Bar
>>
>> But:
>>
>>Foo> rawbar = new RawBar(); // DOES NOT WORK -
> THIS
>> IS CAUSING ONE HALF OF ALL OUR HEADACHES
>
> (correction:)
> Foo> rawbar = new Foo(); // DOES NOT WORK
-
>
> THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES
>
> Btw, this does work (like you expect):
> Foo> rawbar2 = new Foo>();
>
>> 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 Class. This is also really messed
> up,
>> because:
>>
>> Class 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 Class (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> y) {
>> }
>>
>> it works like a charm for a new Foo>, 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 tha
RE: (Class>) casting troubles
In the example you have detailed, RawBar is not a subtype of Bar
since it extends the raw type Bar.
-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2008 11:31 AM
To: users@wicket.apache.org
Subject: Re: (Class>) casting troubles
ARgh, you always make typos with this stuff.
See correction.
Sebastiaan van Erk wrote:
> Martin Funk wrote:
>
>>> Class> means "class of (anything that extends
(page of
>>> anything))".
>>
>> I'm not so sure.
>
> There are 2 separate issues:
>
> ISSUE 1: Foo> is not assignable from a Foo
> where RawBar extends Bar as a raw type. That is, given:
>
> static class Foo {
> }
>
> static class Bar {
> }
>
> static class RawBar extends Bar {
> }
>
> static class SubBar extends Bar {
> }
>
> Thus:
>
>Bar bar = new RawBar(); // works, because RawBar is a subtype of
> Bar
>
> But:
>
>Foo> rawbar = new RawBar(); // DOES NOT WORK -
THIS
> IS CAUSING ONE HALF OF ALL OUR HEADACHES
(correction:)
Foo> rawbar = new Foo(); // DOES NOT WORK -
THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES
Btw, this does work (like you expect):
Foo> rawbar2 = new Foo>();
> 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 Class. This is also really messed
up,
> because:
>
> Class 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 Class (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> y) {
> }
>
> it works like a charm for a new Foo>, 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>) casting troubles
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>) 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> 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 > > > void foo(Class 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 ) >> >> 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.Class >>> required: java.lang.Class> >>> 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 subjec
RE: Wicket Session and non-Wicket Servlet
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:
openSessionInViewFilter
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
WicketSessionFilter
org.apache.wicket.protocol.http.WicketFilter
applicationClassName
com.alliancemanaged.simis.web.SIMISApplication
filterName
ReportingApplication
openSessionInViewFilter
/app/*
openSessionInViewFilter
/report
WicketSessionFilter
/app/*
JasperReportServlet
com.alliancemanaged.simis.web.jasperreport.JasperReportServlet
1
JasperImageServlet
com.alliancemanaged.simis.web.jasperreport.JasperImageServlet
1
JasperReportServlet
/report/*
JasperImageServlet
/reportimage/*
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(Iterator 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 I do Session.get() from my JasperReportServlet I
> am
> > > getting the error java.lang.IllegalStateException: you can only locate
> or
> > > create sessions in the context of a request cycle.
> > >
> > >
> > >
> > > So, can I no longer get an object from my wicket Session from a
> > non-wicket
> > > Servlet? I've been looking all over, and can't seem to find the right
> > > answer. Thanks for any help.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Matthew.
> > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> >
Wicket-Security and Wicket 1.4
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: users, please give us your opinion: what is your take on generics with Wicket
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]
RE: How to strip wicket tags from markup in development mode?
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 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: (Class>) casting troubles
I think that is only part of the problem in this instance. The other
part of the problem is that Base.class presents only runtime
information. There is no way to invoke Base.class to get
Class> in a manner similar to how you can invoke a generic
method. The type represented in the <> returned by a 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 > 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> clazz)"
bad(Base.class) displays the error:
"The method bad(Class>) in the
type Test is not applicable for the arguments
(Class)"
good(Derived.class) displays on hover
void Test.good(Class clazz)
good(Base.class) displays on hover
void Test.good(Class clazz)
So in the last instance the compiler infers Base for X since Base.class
returns Class and is happy. Changing
good(Class clazz)
to
good(Class clazz)
Should preserve the original intention of bad(Class>
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>) 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> clazz)
{ // ^^ two wildcards in one expression:
// uh oh, calling for trouble!
}
public static > void good(Class clazz)
{
//
}
public static class Base
{
}
public static class Derived extends Base
{
}
}
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
> > and not directly with >>.
>
> 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: Wicket java.lang.IllegalAccessError bug?
I can't get the ternary statement you provided to compile correctly
using 1.4-M1. The error I get is:
The type AbstractChoice is not visible
Due to the fact that the common ancestor for ListMultipleChoice and
ListChoice is the inaccessible package protected object AbstractChoice.
This is 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
RE: MarkupNotFoundException
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
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
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
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 per
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]
RE: Suggested Enhancement To Spring Support
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.(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.
> > ___
RE: Suggested Enhancement To Spring Support
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.(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.
_
Suggested Enhancement To Spring Support
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.(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]
Creating Custom Form Components
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]
RE: downloading Wicket examples
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]
RE: Authentication and Assigning a Session Id
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] > &g
RE: Authentication and Assigning a Session Id
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]
Authentication and Assigning a Session Id
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. _
