Re: AJAX calls not working with mod_proxy
Hi! This works fine for us: ProxyPass / http://www.mydomain.com:8080/ ProxyPassReverse / http://www.mydomain.com:8080/ RewriteEngine On RewriteCond %{SERVER_NAME} !^www\.mydomain\.com RewriteRule /(.*) http://www.mydomain.com/$1 [redirect=301L] ** Martin 2009/5/24 James Carman : > I've never been able to set up a proxied connection to "/". I've > always had to do a forward to my webapp's URL. > > On Sat, May 23, 2009 at 7:09 PM, Michael Plöd wrote: >> Hi, >> I am currently struggling with a very strange behaviour between Wicket >> (1.3.4) and my mod_proxy configuration. >> >> The usual calls to BookmarkablePageLinks work perfectly. The same goes >> out to resource loading and so on. However, as soon as I want to work >> with AjaxFallbackLinks and so on I always get a "Page Expired" page >> telling me that the page I requested has expired. >> >> My scenario is as follows: >> - I have an Apache 2 Server for static content (images) in the url >> www.myhost.com/pictures >> - In addition to that I have a Tomcat server hosting my webapp which >> should be accessed unter www.myhost.com >> >> The mod_proxy config is as follows: >> >> ProxyPass /pictures ! >> ProxyPass / ajp://localhost:8009/site-1.0-SNAPSHOT/app/ >> ProxyPassReverse / ajp://localhost:8009/site-1.0-SNAPSHOT/app/ >> ProxyPassReverseCookiePath / /site-1.0-SNAPSHOT/app >> >> >> Any suggestions what I am missing here? >> >> Thanks a lot in advance, >> Mike >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AJAX calls not working with mod_proxy
I've never been able to set up a proxied connection to "/". I've always had to do a forward to my webapp's URL. On Sat, May 23, 2009 at 7:09 PM, Michael Plöd wrote: > Hi, > I am currently struggling with a very strange behaviour between Wicket > (1.3.4) and my mod_proxy configuration. > > The usual calls to BookmarkablePageLinks work perfectly. The same goes > out to resource loading and so on. However, as soon as I want to work > with AjaxFallbackLinks and so on I always get a "Page Expired" page > telling me that the page I requested has expired. > > My scenario is as follows: > - I have an Apache 2 Server for static content (images) in the url > www.myhost.com/pictures > - In addition to that I have a Tomcat server hosting my webapp which > should be accessed unter www.myhost.com > > The mod_proxy config is as follows: > > ProxyPass /pictures ! > ProxyPass / ajp://localhost:8009/site-1.0-SNAPSHOT/app/ > ProxyPassReverse / ajp://localhost:8009/site-1.0-SNAPSHOT/app/ > ProxyPassReverseCookiePath / /site-1.0-SNAPSHOT/app > > > Any suggestions what I am missing here? > > Thanks a lot in advance, > Mike > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: showstoppers -- NoSuchMethodError (again and again)
Have there been that many changes since 1.4-rc4? I just released rc4 like three weeks ago. Are we talking about the same rc4? -- Jeremy Thomerson http://www.wickettraining.com On Sat, May 23, 2009 at 9:41 PM, Brill Pappin wrote: > I don't actually have commit to wicketstuff, but cudos for having all > modules build and all tests passing, I'm able to build without any trouble > and deploy into our local repo on the first try. > I don't mind help get it up though, particularly if it gets things working > again. > > As of last night, all modules in wicketstuff-core are building and all tests > passing, but thats against the current wicket-1.4-SNAPSHOT so I'm not sure > about rc4 (I think it might not build against rc4 because of the mentioned > issues). > > I think you might have to wait until they do a new release, then tag your > repo immediately and release from there, there have been a lot of changes in > wicketstuff-core since wicket-rc4. > You might also be able to check the date of rc4 in the wicket svn and tag a > revision of wicketstuff-core for that date (risky, but might just work). > > - Brill > > > > On 23-May-09, at 10:03 PM, Jeremy Thomerson wrote: > >> What we really need to do (and I haven't had time to do) is cut a >> release of wicketstuff 1.4-rc4 to match wicket's recent release. That >> was the reason I went through all the effort of getting all of the WS >> core projects together - so that they could be numbered with releases >> that matched Wicket's. >> >> So, if you have time and are willing to work on something, please make >> sure all of the projects work and build against Wicket 1.4-rc4 and >> then make a tag of that moment in the repo. I can do the release from >> there if you send me a link. I started to do a release a couple weeks >> ago right after I built the core release, but some things weren't >> compiling / working and I didn't have the time to fix all of those >> projects. >> >> -- >> Jeremy Thomerson >> http://www.wickettraining.com >> >> >> >> >> On Fri, May 22, 2009 at 8:26 PM, Brill Pappin wrote: >>> >>> Over the last week I've been running into no end of NoSuchMethod >>> errors, particularly between the wicket 1.4-SNAPSHOT and the wicketstuff >>> 1.4-SNAPSHOT. >>> They both are snapshots, so this is expected now and then, however they >>> don't seem to be being fixed. >>> In all cases so far, the exceptions that popup during runtime reflection >>> and >>> a common theme is the ModalWindow classes. >>> For instance: >>> Caused by: java.lang.NoSuchMethodError: >>> >>> org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow.setPageMapName(Ljava/lang/String;)V >>> at >>> >>> org.wicketstuff.calendarviews.LargeView.initializeDetailModalWindow(LargeView.java:103) >>> There is another that I don't have off the top right now, but it's >>> similar >>> (also in ModalWindow, although not the same error). >>> In general one of the reasons I chose to work with Wicket is the easy way >>> it >>> can be tested. >>> So, to that end I would like to recommend to the WIcket Stuff developers >>> that *aLl example apps* have unit tests. Unit testing the examples would >>> more than likely expose these problems early. To begin with, any library >>> that uses ModalWindow should have unit tests added. >>> I'm in the process now of checking out the wicketstuff source so I can >>> start >>> trying to fix some of this stuff, time permitting myself. >>> - Brill >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: showstoppers -- NoSuchMethodError (again and again)
I don't actually have commit to wicketstuff, but cudos for having all modules build and all tests passing, I'm able to build without any trouble and deploy into our local repo on the first try. I don't mind help get it up though, particularly if it gets things working again. As of last night, all modules in wicketstuff-core are building and all tests passing, but thats against the current wicket-1.4-SNAPSHOT so I'm not sure about rc4 (I think it might not build against rc4 because of the mentioned issues). I think you might have to wait until they do a new release, then tag your repo immediately and release from there, there have been a lot of changes in wicketstuff-core since wicket-rc4. You might also be able to check the date of rc4 in the wicket svn and tag a revision of wicketstuff-core for that date (risky, but might just work). - Brill On 23-May-09, at 10:03 PM, Jeremy Thomerson wrote: What we really need to do (and I haven't had time to do) is cut a release of wicketstuff 1.4-rc4 to match wicket's recent release. That was the reason I went through all the effort of getting all of the WS core projects together - so that they could be numbered with releases that matched Wicket's. So, if you have time and are willing to work on something, please make sure all of the projects work and build against Wicket 1.4-rc4 and then make a tag of that moment in the repo. I can do the release from there if you send me a link. I started to do a release a couple weeks ago right after I built the core release, but some things weren't compiling / working and I didn't have the time to fix all of those projects. -- Jeremy Thomerson http://www.wickettraining.com On Fri, May 22, 2009 at 8:26 PM, Brill Pappin wrote: Over the last week I've been running into no end of NoSuchMethod errors, particularly between the wicket 1.4-SNAPSHOT and the wicketstuff 1.4-SNAPSHOT. They both are snapshots, so this is expected now and then, however they don't seem to be being fixed. In all cases so far, the exceptions that popup during runtime reflection and a common theme is the ModalWindow classes. For instance: Caused by: java.lang.NoSuchMethodError: org .apache .wicket .extensions.ajax.markup.html.modal.ModalWindow.setPageMapName(Ljava/ lang/String;)V at org .wicketstuff .calendarviews.LargeView.initializeDetailModalWindow(LargeView.java: 103) There is another that I don't have off the top right now, but it's similar (also in ModalWindow, although not the same error). In general one of the reasons I chose to work with Wicket is the easy way it can be tested. So, to that end I would like to recommend to the WIcket Stuff developers that *aLl example apps* have unit tests. Unit testing the examples would more than likely expose these problems early. To begin with, any library that uses ModalWindow should have unit tests added. I'm in the process now of checking out the wicketstuff source so I can start trying to fix some of this stuff, time permitting myself. - Brill - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org smime.p7s Description: S/MIME cryptographic signature
Storing css and image files
Hello. I'm new to web development and to Wicket. I created an Wicket project in Eclipse following the instructions in the website, from there and following the examples I have been able to create a couple of simple web pages. The problem I am having, is that I don't know where to store my css file and my image files so that they would be loaded when I execute my new web pages. If possible I would like to do it using relative paths so then I can deploy my war elsewhere Thanks Lucas B
Re: showstoppers -- NoSuchMethodError (again and again)
What we really need to do (and I haven't had time to do) is cut a release of wicketstuff 1.4-rc4 to match wicket's recent release. That was the reason I went through all the effort of getting all of the WS core projects together - so that they could be numbered with releases that matched Wicket's. So, if you have time and are willing to work on something, please make sure all of the projects work and build against Wicket 1.4-rc4 and then make a tag of that moment in the repo. I can do the release from there if you send me a link. I started to do a release a couple weeks ago right after I built the core release, but some things weren't compiling / working and I didn't have the time to fix all of those projects. -- Jeremy Thomerson http://www.wickettraining.com On Fri, May 22, 2009 at 8:26 PM, Brill Pappin wrote: > Over the last week I've been running into no end of NoSuchMethod > errors, particularly between the wicket 1.4-SNAPSHOT and the wicketstuff > 1.4-SNAPSHOT. > They both are snapshots, so this is expected now and then, however they > don't seem to be being fixed. > In all cases so far, the exceptions that popup during runtime reflection and > a common theme is the ModalWindow classes. > For instance: > Caused by: java.lang.NoSuchMethodError: > org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow.setPageMapName(Ljava/lang/String;)V > at > org.wicketstuff.calendarviews.LargeView.initializeDetailModalWindow(LargeView.java:103) > There is another that I don't have off the top right now, but it's similar > (also in ModalWindow, although not the same error). > In general one of the reasons I chose to work with Wicket is the easy way it > can be tested. > So, to that end I would like to recommend to the WIcket Stuff developers > that *aLl example apps* have unit tests. Unit testing the examples would > more than likely expose these problems early. To begin with, any library > that uses ModalWindow should have unit tests added. > I'm in the process now of checking out the wicketstuff source so I can start > trying to fix some of this stuff, time permitting myself. > - Brill > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: IModel and ResourceModel
Black box library? Isn't a black box one that you can't see in to? How would that apply to an OPEN source library where the code is available for [1] download, [2] publicly viewing on the internet, or [3] modifying yourself? [1] - http://download.filehat.com/apache/wicket/1.4-rc4/ [2] - http://fisheye6.atlassian.com/browse/wicket/trunk/wicket/src/main/java/org/apache/wicket/model/ResourceModel.java?r=672603 [3] - http://www.apache.org/licenses/LICENSE-2.0 But the answer is YES - it is an IModel which is the only reason your code compiles. It's also in the source code. I'd recommend using maven and "mvn eclipse:eclipse" or similar for your IDE so that you can just click into the code to see this. On Sat, May 23, 2009 at 1:08 PM, Luther Baker wrote: > I think that is what the source has but typing my > application based on what the black box library uses today seems like a bad > practice. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
AJAX calls not working with mod_proxy
Hi, I am currently struggling with a very strange behaviour between Wicket (1.3.4) and my mod_proxy configuration. The usual calls to BookmarkablePageLinks work perfectly. The same goes out to resource loading and so on. However, as soon as I want to work with AjaxFallbackLinks and so on I always get a "Page Expired" page telling me that the page I requested has expired. My scenario is as follows: - I have an Apache 2 Server for static content (images) in the url www.myhost.com/pictures - In addition to that I have a Tomcat server hosting my webapp which should be accessed unter www.myhost.com The mod_proxy config is as follows: ProxyPass /pictures ! ProxyPass / ajp://localhost:8009/site-1.0-SNAPSHOT/app/ ProxyPassReverse / ajp://localhost:8009/site-1.0-SNAPSHOT/app/ ProxyPassReverseCookiePath / /site-1.0-SNAPSHOT/app Any suggestions what I am missing here? Thanks a lot in advance, Mike - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generic BookmarkablePage
final Link link= -igor On Sat, May 23, 2009 at 12:55 PM, James Carman wrote: > BookmarkablePageLink perhaps? > > On Sat, May 23, 2009 at 2:05 PM, Luther Baker wrote: >> I'm afraid I'm late to the party and that this may have been discussed >> 'before' I moved to 1.4 - but is there an established best practice to >> handle something like BookmarkablePageLink ... when I'm not going to use a >> model? >> >> Can I confidently just leave the Type off? Is that best practice? or should >> we pick some well-known type? ahh .. that sounds wrong. >> >> final Link link = new >> BookmarkablePageLink("app-title", Home.class); >> vs >> final Link link = new BookmarkablePageLink("app-title", Home.class); >> >> I'm one of those 'hate yellow squigglies' kinda folks so it feels 'funny' >> ... had to ask. >> >> Thanks, >> >> -Luther >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Separating Development and Deployment
Usually it is best to move such configuration out of your war file. i.e. use a datasource for your database connection, etc. You don't want to have to build 3 wars for different environments: test, usertest and production. Martijn On Wed, May 20, 2009 at 9:01 PM, Dane Laverty wrote: > Thanks for piping in, Martijn. I should have clarified, my deployment and > development environments use different databases. I'm storing the database > connection information inside of the web.xml also, so I need to be able to > switch those as well as the Wicket configuration depending on the > environment. I suppose I could store the connection information for both, > and then select one based on the Wicket configuration, though that sounds a > little hack-ish. > > On Wed, May 20, 2009 at 11:51 AM, Martijn Dashorst < > martijn.dasho...@gmail.com> wrote: > >> Set a system property in your server config or startup script that >> tells wicket it's running in deployment mode. >> -Dwicket.configuration=deployment is all there's to it. >> >> Martijn >> >> On Wed, May 20, 2009 at 6:40 PM, Dane Laverty >> wrote: >> > I've got my project set up to deploy with Maven's Tomcat plugin now. My >> next >> > step is getting the web.xml to use the correct Wicket configuration >> > (development/deployment) value. Is there a way to run two separate >> web.xml >> > files for the application, and then somehow have Maven pick up the >> correct >> > one when I run "mvn tomcat:deploy"? Or am I going about this the wrong >> way >> > entirely? I've done some reading and it sounds like people are using "web >> > resource filtering" to address the issue, however to me it seems that it >> > just moves the parameters from the web.xml to the pom.xml, and that I >> would >> > have to manually change them in the pom.xml when I want to change from >> > deployment to development. >> > >> >> >> >> -- >> Become a Wicket expert, learn from the best: http://wicketinaction.com >> Apache Wicket 1.3.5 is released >> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: IModel and ResourceModel
On Sat, May 23, 2009 at 2:08 PM, Luther Baker wrote: > I typically write this out longhand (is that bad or unpopular) for ez > debugging): > > add(new Label("quote", new ResourceModel("default-quote"))); > > would often be: > > IModel model = new ResourceModel("default-quote"))); > Label label = new Label("quote", model); > add(label); > > My question is, am I correct to assume that a ResourceModel is an > IModel? I think that is what the source has but typing my > application based on what the black box library uses today seems like a bad > practice. I'm afraid to rely on this -- since, the source could change ... ? > False alarm? Am I misunderstanding something maybe? Check the javadocs: http://wicket.apache.org/docs/1.4/org/apache/wicket/model/ResourceModel.html ResourceModel extends AbstractReadOnlyModel. Sine resource strings are, in fact, Strings, I wouldn't foresee that changing. I think you're safe. I'm using it in my code, so if you're not, I'm screwed too! :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generic BookmarkablePage
BookmarkablePageLink perhaps? On Sat, May 23, 2009 at 2:05 PM, Luther Baker wrote: > I'm afraid I'm late to the party and that this may have been discussed > 'before' I moved to 1.4 - but is there an established best practice to > handle something like BookmarkablePageLink ... when I'm not going to use a > model? > > Can I confidently just leave the Type off? Is that best practice? or should > we pick some well-known type? ahh .. that sounds wrong. > > final Link link = new > BookmarkablePageLink("app-title", Home.class); > vs > final Link link = new BookmarkablePageLink("app-title", Home.class); > > I'm one of those 'hate yellow squigglies' kinda folks so it feels 'funny' > ... had to ask. > > Thanks, > > -Luther > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
AjaxEditableChoiceLabel: display value for Label?
I'm currently trying to use a AjaxEditableChoiceLabel for the first time. Everything works fine (displaying dropdown choice editor, retrieving/updating business object), except displaying the label value when the inplace dropdown choice is inactive. Instead of the selected values name it displays the object itself. AjaxEditableChoiceLabel ajaxEditableLabelUsertype = new AjaxEditableChoiceLabel( "usertype", new PropertyModel(user, "usertype"), Manager.getUsertypes(), new ChoiceRenderer("name", "id") ); Class User has an Attribute of Class UserType which has an id and a name. Manager.getUsertypes() returns all available Intances of UserType. When the Editor is not invoked, the label should display user.getUsertype.getName(). Right now it displays user.getUserType(). The choices inside the dropdown choice when its invoked are right (the names). What am I doing wrong? Thanks for any help on this. Roman - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
IModel and ResourceModel
I typically write this out longhand (is that bad or unpopular) for ez debugging): add(new Label("quote", new ResourceModel("default-quote"))); would often be: IModel model = new ResourceModel("default-quote"))); Label label = new Label("quote", model); add(label); My question is, am I correct to assume that a ResourceModel is an IModel? I think that is what the source has but typing my application based on what the black box library uses today seems like a bad practice. I'm afraid to rely on this -- since, the source could change ... ? False alarm? Am I misunderstanding something maybe? Thanks, -Luther
Generic BookmarkablePage
I'm afraid I'm late to the party and that this may have been discussed 'before' I moved to 1.4 - but is there an established best practice to handle something like BookmarkablePageLink ... when I'm not going to use a model? Can I confidently just leave the Type off? Is that best practice? or should we pick some well-known type? ahh .. that sounds wrong. final Link link = new BookmarkablePageLink("app-title", Home.class); vs final Link link = new BookmarkablePageLink("app-title", Home.class); I'm one of those 'hate yellow squigglies' kinda folks so it feels 'funny' ... had to ask. Thanks, -Luther
AbortWithWebErrorCodeException(404) results in blank page
I'm using tomcat, web.xml has the following configuration: ... Wicket Filter /* REQUEST ERROR 404 /404 ... /404 is mounted to ErrorNotFoundPage.class So, when I try to access something like localhost:8084/MyApp/fhdwef134, I get ErrorNotFoundPage. However, during rendering of a particular bookmarkable page, I throw AbortWithWebErrorCodeException(404) if the UUID provided in query string is not referencing to any object in repository. Instead of ErrorNotFoundPage, I'm getting a blank page. What am I doing wrong? -- sp - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and 3rd party Javascript libraries
Thanks for the replies. I will look at the links too. On 5/23/09, nino martinez wael wrote: > I've had no issues building javascript libraries.. One tricky area if > any could be ajax... But that was more the javascript libraries than > wicket. > > I've writte a couple of articles on the topic too.. > > > http://ninomartinez.wordpress.com/2008/09/09/apache-wicket-javascript-integration/ > http://blog.jayway.com/2008/09/26/wicket-javascript-internals-dissected/ > > And I have a new release of the artwork package comming up soon :) > > 2009/5/23 Sam Stainsby : > > > On Thu, 21 May 2009 20:32:01 -0500, Vasu Srinivasan wrote: > > > >> Apologize if this question sounds too generic... Are there restrictions > >> in using 3rd party Javascript libraries when using Wicket? We have a > >> separate design/javascript team and they love the idea of having just > >> html to work with. But there is also a need of freedom/flexibility in > >> adding custom javascript solutions (eg DWR, Dojo etc) Will Wicket's > >> javascript libraries get in the way ? Incidentally whats the javascript > >> library kit that Wicket uses by default ? > > > > I've just been using Wiquery, a (currently alpha-ish) framework that > > integrates JQuery and Wicket. I was able to JQuery-enable my application > > framework and make it themeroller-ready in the space of an evening. My > > understanding is that there is a lot of work to go on Wiquery, but it > > seems to be usable, and a good start rather than working it all out for > > yourself. Having said that, I haven't done much more than pop up a dialog > > box and play with themeroller so far. > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Regards, Vasu Srinivasan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Ajax appends to a Table
On Fri, May 22, 2009 at 10:01 AM, Igor Vaynberg wrote: > better approach is outlined in one of the articles on wicketinaction.com > > -igor > http://wicketinaction.com/2008/10/repainting-only-newly-created-repeater-items-via-ajax/ Thanks Igor. -Luther