Serialization and Form Models
Models have been my achilles heel when it comes to Wicket. Not so much their explicit use, but understanding whe they data they wrap around is serialized or kept in session and when it's not. I was running some tests today to experiment with just this subject. The domain object I was using in my tests intentionally had one field that I could, as an option, populate with unserializable value. This made it easy for me to determine when Wicket was trying to store the object with the page, as it would throw an exception. I created a page with a form to create new instances of this particular object. I initialized the form with a CompoundPropertyModel wrapped around my domain object. When I submitted the form and saved the object to my backend store , I received a WicketNotSerializableException. I was initially surprised by this, but after a few moments I realized (and correct me if I'm wrong) that the model wasn't detachable and that when I saved it the attribute I mentioned above was being populated with that unserializable value, but wicket was trying to save the page (probably to disk) with the model wrapped around the now unserializable object. I guess this isn't a big deal, but what concerns me, and the reason I was running these tests, was that some of the objects I'm working with have huge data graphs attached to them. I don't want these huge objects stored in memory or serialized with any of the pages to disk. Can a form be backed by a detachable model? It certainly wouldn't be a "loadable" detachable model for new objects that are to be created as there's nothing yet to load. If one can back a form with detachable model, does that limit anything that you can do with the form?
LDM, Forms, and Ajax
I'm experimenting with a domain model that extremely interconnected. It's being persisted using a graph database which handles this high degree of interconnectivity with aplomb, however because my each of my domain objects is so tighly tied to the others, I have to be very careful to always use LoadableDetachableModels or I can easily end up serializing quite a bit of unintended data with the page. So far, this hasn't been too bad. In the past, I never used LDMs for forms, and I ran into a few initial issues at first, but they were mostly just me relearning some of my former habits. However, I have no run into an a corner case that I'm hoping someone with more knowledge of Wicket or a good creative stream might be able to help me figure out. I have a form backed by a LDM. Three of the fields (select fields) are cascading in the sense that I need to fill out one before the second is enabled and the options for the second are determined by the first. The cascade continues from the second to the third. I attached a AjaxFormComponentUpdatingBehavior tied to the "onblur" event for the first and second fields. I used this update the second and third fields when appropriate. This seemed to work fine, but then suddenly I ran into problems with the fields reverting back to the values they held before I modified them. I'm embarrassed to admin that I was stumped by this for a good thirty minutes until I remembered that this was all backed by a LDM. Obviously, when the ajax request would hit the server, the model would be reloaded from the back end with it's original values. I'm a bit stuck. I can make the form a little less fancy and not limit the items in the second and third fields from the value in the first and second respectively, but I'd prefer not to have to do that. Any ideas? Matt
setResponsePage() and mounted URLs
My mounted pages work perfectly when I use a BookmarkablePageLink to them,
however I am having difficulty when I try to use setResponsePage() to those
same pages. Here's a snipped that I pulled from a Quickstart I'm using to
figure out where I'm going wrong:
setStatelessHint(true);
add(new StatelessLink("statelessPage1") {
public void onClick() {
setResponsePage(StatelessPage1.class);
}
});
add(new BookmarkablePageLink("statelessPage1-2",
StatelessPage1.class));
The second link produces a nice clean link URL like "
http://localhost:8080/statelessapp/stateless1";, however the first produces a
much less desirable "
http://localhost:8080/statelessapp/?wicket:bookmarkablePage=:com.mycompany.HomePage&wicket:interface=:0:statelessPage1::ILinkListener:
:".
In this simplified example I could clearly use a BookmarkablePageLink in
both situations, however in my real app the logic to determine where a
particualr link needs to go a is occassional conditional so I end up with
something like:
add(new StatelessLink("statelessPage1") {
public void onClick() {
if(somethingIsTrue){
setResponsePage(StatelessPage1.class);
}else{
setResponsePage(StatelessPage2.class);
}
}
});
Can someone put me on the right path to using mounted URLs with
setResponsePage()?
Matt
Turning off ModificationWatcher
I'm experimenting with Wicket inside Google's new Java support for its App Engine. My simple apps run fine if the configuration is set to DEPLOYMENT, however in development mode, I get an exception related to ModificationWatcher. Looking at the exception I think this ModificationWatcher is being used as part of a new thread which is a no-no inside the App Engine sandbox. Is there way way to just disbable this modification watcher without putting the entire app in deployment mode? There are a number of items I like about development mode but this one glitch is preventing me from using it. Matt
Google App Engine and Wicket
I've been experimenting a bit with Google App Engine and Wicket and things seemed to work fairly well once I turned off the ModificationWatcher. However, I realized that my simple tests were all stateless and that once stateful, Wicket would use the DiskPageStore to write some files, which is not allowed in the App Engine sandbox. Sure enough, once I added some stateful pages, I started seeing exceptions related to the DiskPageStore. I'm a neophyte when it comes to the deep down Wicket internals so I'm not sure what my other options might be. In a post Matej Knopp said, ""* DiskPageStore*'s purpose is to store serialized pages on disk in order to allow access to previous page versions and also to conserve session memory usage." This leads me to believe that using the sassion for storing this information isn't a preferred approach. What about the App Engine's datastore (an abstration on BigTable)? That seems like it might be too slow to adequately serve this need, but I'm not sure. A thread on Wicket/Terracotta integration ended up with an alternative "SecondLevelCacheSessionStore" but I'm not sure if that is only usable with Terracotta or if it might might sense in other situations. Any other options? Also, looking forward, with the knoledge that writing giles and spawning new threads are not allowed in the App Engine sandbox, are there any other items I should be onl the lookout for in Wicket that might make it a poor choice for this situation? Matt
Custom URL Handling
I have been happily using HybridUrlCodingStrategy for the common pages of my current app, however I am now beginning to implement a section which has slightly different requirements for the URL and while I have some idea about where I can start to implement this custom URL handling, I would like the advice of those more experienced that I to make sure I'm not heading down a rathole. My application will serve many different organizations. All users will see the same set of pages, but the organization that they are choosing to view (users can view the data from any organization) will affect the data on those pages. I would like the urls to be something like this: http://myapp.com/organization1/calendar http://myapp.com/organization1/events http://myapp.com/organization2/calendar http://myapp.com/organization2/events I would need to know the organization part of the URL before retrieving the data for the page, so in reality it's nothing more that page parameter. In all other respects, I would like to keep the functionality provided by HybridUrlCodingStrategy, so would my best bet be to extend that strategy? Is there somewhere else I should be inserting custom code to intercept the URL before it gets to the coding strategy instead? Matt
AjaxLink causing a redirect
I've been playing around with URL rewriting a bit and have run across some promising techniques. While testing these techniques, I've been slowly loading up my pages with a number of different kinds of actions and links. Everything was working pretty smoothly until I got put my first AjaxLink on the page. For some reason, just the presence of an AjaxLink causes a redirect during the processing of the page. Remove the AjaxLink; no redirect. I'm not questioning the necessity of this as I'm sure there's a good reason. I am curious though. Why does this happen? Matt
Automatically adding a parameter to every link?
The data in the application that I'm working on is divided in any number of different contexts. The pages displayed for each context are the same but the data shown on those pages will be different depending on the specific context. A logged in user might might have multiple pages (browser windows) open at one time from any one of these contexts, otherwise I would store the context in their session. As it stands I need to pass the context around from page to page as a parameter. Is there an easy way to have this parameter automatically appended to all links on page as they are rendered or generated? I suppose I could build my own set of Link components that look for the existing context of a page and append that to themselves, and use those links instead of the built in ones. Any other options? -Matt
Add "Any" option to DropDownChoice
I'm sure this has been answered before but I've a good bit searching the list and can't seem to find it... I need to add an option to a DropDownChoice that displays the word "Any" and will be treated differently than the other options. I've hacked an IChoiceRenderer to death and managed to get the option to display but obviously when the form is submitted and Wicket tries to update the model things fall apart. I'm clearly doing things wrong at a very basic level This doesn't seem like isn't an unusual use case so I assume I'm probably missing something obvious, but I could sure use some help seeing it.
SSL Offloading and Wicket
I'm sure I'm missing something simple as there are certainly many others using similar setups, but I cannot figure out what I'm doing wrong. We force all requests from the public internet to use HTTPS when accessing our app.We terminate SSL at the load balancer and the request that actually hits Apache and then Tomcat is straight HTTP. The load balancer adds the proper X-Forwarded-Proto headers to the requests heading back to the app server and Wicket and we've confirmed that these are being received. We've setup the XForwardedRequestWrapperFactory in our web application init. We can even confirm that request.getScheme() is properly returning "https" inside our application. Where things break down is when Wicket issues a redirect, which of course it does all of the time as people navigate from page to page. For some reason, the issued redirects are always HTTP, instead of HTTPS. These HTTP redirects themselves eventually get redirected back to HTTPS by our load balancer on their return trip from the client, but many of our customers are ultra security conscious and have firewalls in place that won't even allow those initial HTTP requests through, so we've got a problem. We've traced through the Tomcat code and the cause is in org.apache.catalina.connector.Response. This is the original response that was created when the container first began processing the request. It carries a pointer to the "original" request as well and it uses this request with its getScheme(), getServerPort(), and getServerName() to generate the redirect that is eventually returned. It does not use the "wrapped" request that contains the values determined from processing the X-Forwarded headers. As I said, I'm sure this is working as intended and that we've just missed something somewhere, but for the life of me, I can figure out what it is. Any ideas? We need Wicket/Tomcat to produce HTTPS redirects. Matt
Re: SSL Offloading and Wicket
That makes sense. I'll ask there. Thank you. Matt On Thu, Dec 12, 2013 at 2:00 AM, Martin Grigorov wrote: > Hi, > > I think you should ask in Tomcat mailing lists. > The related code in Wicket is: > > https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java?source=cc#L232 > > As you can see Wicket always passes relative url to the underlying > container. > The container makes it absolute, i.e. sets the scheme, host, port and full > path, and then sets the "Location" response header. > > > On Thu, Dec 12, 2013 at 6:05 AM, Matthew Welch > wrote: > > > I'm sure I'm missing something simple as there are certainly many others > > using similar setups, but I cannot figure out what I'm doing wrong. > > > > We force all requests from the public internet to use HTTPS when > accessing > > our app.We terminate SSL at the load balancer and the request that > actually > > hits Apache and then Tomcat is straight HTTP. The load balancer adds the > > proper X-Forwarded-Proto headers to the requests heading back to the app > > server and Wicket and we've confirmed that these are being received. > We've > > setup the XForwardedRequestWrapperFactory in our web application init. We > > can even confirm that request.getScheme() is properly returning "https" > > inside our application. > > > > Where things break down is when Wicket issues a redirect, which of course > > it does all of the time as people navigate from page to page. For some > > reason, the issued redirects are always HTTP, instead of HTTPS. These > HTTP > > redirects themselves eventually get redirected back to HTTPS by our load > > balancer on their return trip from the client, but many of our customers > > are ultra security conscious and have firewalls in place that won't even > > allow those initial HTTP requests through, so we've got a problem. > > > > We've traced through the Tomcat code and the cause is > > in org.apache.catalina.connector.Response. This is the original response > > that was created when the container first began processing the request. > It > > carries a pointer to the "original" request as well and it uses this > > request with its getScheme(), getServerPort(), and getServerName() to > > generate the redirect that is eventually returned. It does not use the > > "wrapped" request that contains the values determined from processing the > > X-Forwarded headers. > > > > As I said, I'm sure this is working as intended and that we've just > missed > > something somewhere, but for the life of me, I can figure out what it is. > > > > Any ideas? We need Wicket/Tomcat to produce HTTPS redirects. > > > > Matt > > >
Re: SSL Offloading and Wicket
We are considering something along those lines you are suggesting as an alternative.As far as load balancers, we actually have two separate situations: one uses AWS Elastic Load Balancer and the other HAProxy. Matt On Thu, Dec 12, 2013 at 4:35 AM, Michael Haitz wrote: > you could use "proxyPort“ in your connector configuration, but this will > always override ‚getServerPort‘ with this value no matter you’ve a http or > https request. > > Do you use an apache or nginx in front? > > > Am 12.12.2013 um 05:05 schrieb Matthew Welch : > > > I'm sure I'm missing something simple as there are certainly many others > > using similar setups, but I cannot figure out what I'm doing wrong. > > > > We force all requests from the public internet to use HTTPS when > accessing > > our app.We terminate SSL at the load balancer and the request that > actually > > hits Apache and then Tomcat is straight HTTP. The load balancer adds the > > proper X-Forwarded-Proto headers to the requests heading back to the app > > server and Wicket and we've confirmed that these are being received. > We've > > setup the XForwardedRequestWrapperFactory in our web application init. We > > can even confirm that request.getScheme() is properly returning "https" > > inside our application. > > > > Where things break down is when Wicket issues a redirect, which of course > > it does all of the time as people navigate from page to page. For some > > reason, the issued redirects are always HTTP, instead of HTTPS. These > HTTP > > redirects themselves eventually get redirected back to HTTPS by our load > > balancer on their return trip from the client, but many of our customers > > are ultra security conscious and have firewalls in place that won't even > > allow those initial HTTP requests through, so we've got a problem. > > > > We've traced through the Tomcat code and the cause is > > in org.apache.catalina.connector.Response. This is the original response > > that was created when the container first began processing the request. > It > > carries a pointer to the "original" request as well and it uses this > > request with its getScheme(), getServerPort(), and getServerName() to > > generate the redirect that is eventually returned. It does not use the > > "wrapped" request that contains the values determined from processing the > > X-Forwarded headers. > > > > As I said, I'm sure this is working as intended and that we've just > missed > > something somewhere, but for the life of me, I can figure out what it is. > > > > Any ideas? We need Wicket/Tomcat to produce HTTPS redirects. > > > > Matt > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
