Re: Form too large ?
i had this error some time ago, there is a jetty property "org.mortbay.jetty.Request.maxFormContentSize"; found it on http://scottryansblog.blogspot.com/2007/10/appfuse-dieing-on-large-forms-using.html lguwe On Tue, Dec 1, 2009 at 10:58 AM, Martin Makundi wrote: > Hi! > > What is this error? We got this from our production site... > > > 2009-12-01 11:16:19,634 1488650 [btpool0-17] ERROR RequestCycle - H > java.lang.IllegalStateException: Form too large > at org.mortbay.jetty.Request.extractParameters(Request.java:1269) > at org.mortbay.jetty.Request.getParameter(Request.java:640) > at > org.apache.wicket.protocol.http.servlet.ServletWebRequest.getParameter(ServletWebRequest.java:128) > at > org.apache.wicket.protocol.http.request.WebRequestCodingStrategy.decode(WebRequestCodingStrategy.java:205) > at org.apache.wicket.Request.getRequestParameters(Request.java:172) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1301) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1419) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:456) > at > org.apache.wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:160) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) > at wicket.quickstart.TakpServlet.service(TakpServlet.java:45) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) > 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:185) > 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.ContextHandlerCollection.handle(ContextHandlerCollection.java:146) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:285) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457) > at > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:627) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) > > - > 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: Conversation scope in wicket
hi james&joe, which are the issues with clint popetz's current work on the webbeans-wicket integration (already contained in the webbeans preview) that you would write your own? cheers, uwe. On Thu, Jun 18, 2009 at 8:05 PM, James Carman wrote: > JSR-299 is somewhat of a moving target right now, so it's hard to stay > up-to-date with it. I'm mainly working with the OpenWebBeans folks on > it. > > On Thu, Jun 18, 2009 at 2:03 PM, Joe Fawzy wrote: > > > > Hi all > > > > On Thu, Jun 18, 2009 at 7:44 AM, James Carman > > wrote: > > > > > On Thu, Jun 18, 2009 at 12:38 AM, Igor Vaynberg < > igor.vaynb...@gmail.com> > > > wrote: > > > > > > > > you are free to implement this as an open source addition to wicket. > > > > there is wicketstuff or googlecode or sf.net where you can host it. > > > > > > > > wicket is a ui framework and conversational scope management falls > > > > outside wicket's scope. it is our job to provide the hooks to make > > > > such things possible, not to provide an implementation. > > > > > > And, those hooks are very nice. I would only ask for some more > > > listener registering opportunities (like for listening to request > > > cycle events like begin/end rather than having to implement your own > > > request cycle). > > > > > > Yes this is a much needed functionality > > i think we may cooperate in that thing > > can u start another mail discussion suggesting ur needs , and make > everyone > > participate > > Thanks > > Joe > > > > > > > > > > > > > > > - > > > 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: Generate markup for hidden framework form field?
thx jörn for sharing ur solution!
i also just found a similar one by uwe schaefer:
http://www.codesmell.org/blog/2008/12/wicket-secureform/
cheers uwe.
On Tue, May 26, 2009 at 2:43 PM, Jörn Zaefferer
wrote:
> Thanks guys! The end result looks like this, works fine, and removed a
> lot of html boilderplate from our templates:
>
> public SecureForm(String id, IModel model) {
> super(id, model);
> setMarkupId(id);
> add(new IFormValidator() {
> �...@override
> public void validate(Form form) {
> String submitted =
> getRequest().getParameter("csrf-protection");
> if
> (Application.get().getConfigurationType().equals(Application.DEPLOYMENT)
> && !csrfProtection().equals(submitted)) {
> log.warn("potential csrf attack, submitted
> value: " + submitted +
> ", expected: " + csrfProtection());
> form.error("wrong csrf protection cookie");
> }
> }
>
> �...@override
> public FormComponent[] getDependentFormComponents() {
> return null;
> }
> });
> }
>
> @Override
> protected void onComponentTagBody(MarkupStream markupStream,
> ComponentTag openTag) {
> getResponse().write(new AppendingStringBuffer(" type=\"hidden\" name=\"csrf-protection\"
> value=\"").append(csrfProtection()).append("\" />"));
> super.onComponentTagBody(markupStream, openTag);
> }
>
> Jörn
>
> On Tue, May 26, 2009 at 2:23 PM, Jörn Zaefferer
> wrote:
>> The current component (the HiddenField) checks that the same value
>> that it started with, is submitted. I'll try to replace that using a
>> form validator that reads the parameter directly.
>>
>> Thanks
>> Jörn
>>
>> On Tue, May 26, 2009 at 1:32 PM, Maarten Bosteels
>> wrote:
>>> When you write it out with oncomponenttagbody it's not part of the
>>> component hierarchy, it's just rendered markup.
>>> Once the form is submitted, you can retrieve the value using the servlet
>>> API.
>>> What behavior would you want to add on top ?
>>>
>>> Maarten
>>>
>>>
>>> On Tue, May 26, 2009 at 12:17 PM, Jörn Zaefferer <
>>> joern.zaeffe...@googlemail.com> wrote:
>>>
How is that going the fix the problem? I'd end up with markup, but no
behaviour on top of it.
Jörn
On Mon, May 25, 2009 at 5:52 PM, Igor Vaynberg
wrote:
> right, so remove that code since you have replaced that component with
> pure markup.
>
> -igor
>
> On Mon, May 25, 2009 at 8:48 AM, Jörn Zaefferer
> wrote:
>> That was the idea. But Wicket still can't find the component markup
>> when looking for it. The form adds this elsewhere:
>>
>> add(new HiddenField("csrf-protection", new
>> Model(csrfProtection())).setRequired(true).add(new
>> IValidator() {
>> public void validate(IValidatable validatable) {
>> log.warn("potential csrf attack, submitted value: " +
>> validatable.getValue() + ", expected: " + csrfProtection());
>> validatable.error(new ValidationError().setMessage("wrong
csrf
>> protection cookie"));
>> }
>> }));
>>
>> Jörn
>>
>> On Mon, May 25, 2009 at 5:44 PM, Igor Vaynberg
wrote:
>>> if you write it out in oncomponenttagbody then you dont need it in the
>>> markupo anymore.
>>>
>>> -igor
>>>
>>> On Mon, May 25, 2009 at 6:32 AM, Jörn Zaefferer
>>> wrote:
Hi,
my application uses a form subclass everywhere for CSRF protection.
Each form needs a hidden field like this: >>> wicket:id="csrf-protection" />
The wicket component for that is added by the form subclass
(SecureForm) which all other forms in the application extend.
Currently each form has to include that markup somewhere, producing a
lot of duplication.
I'm looking for a way to get rid of that duplication. An approach I'm
currently investigating is to generate the markup, similar to how Form
genrates a hidden input it its onComponentTagBody:
@Override
protected void onComponentTagBody(MarkupStream markupStream,
ComponentTag openTag) {
String nameAndId = get("csrf-protection").getId();
AppendingStringBuffer buffer = new AppendingStringBuffer(
">>> />");
getResponse().write(buffer);
super.onComponentTagBody(markupStream, openTag);
}
That doesn't work, Wicket throws an exception of a missing reference
in markup anyway. Likely because this just writes to the response, not
extending the markup.
I also don't see any way to achieve this via MarkupS
Re: How to keep fields between pages
i wouldn't be happy to put such data into the session where it will lie around all the time; it doesnt belong to the user but to a usecase which consists of just some pages; a perfect application for conversation scope; when you use wicket with seam, seam can handle these conversation scopes for you. cheers, uwe! On Sat, May 23, 2009 at 12:36 AM, Jeremy Thomerson < jer...@wickettraining.com> wrote: > I would suggest that this would be the "wicket way" as well. This > sounds like the data is session scoped - it belongs to the user. It > doesn't really "belong" to a page. Just OO. > > -- > Jeremy Thomerson > http://www.wickettraining.com > > > > > On Fri, May 22, 2009 at 7:40 AM, Lorenzo Bolzani > wrote: > > Yes, I can, but it doesn't look very "wicket style", > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Another question for best practices
dear community,
still working on a reimplementation of a former jsf gui i have some more
questions about how to implement it correctly in wicket;
* simple components:
in my html i have many lines where i need just little modifications of the
html:
e.g. in jsf i had 10 lines like: (mediaPath is dynamic)
in wicket this will be 10 lines with: and 10 components
added to the page, like: add( new HrefChanger( "headerCssLink",
LINKTYPE_CSS) );
the HrefChanger-Component just takes the tag from the html and changes the
href attribute by prepending the css-path;
is this the correct way?
seems that sth like the wicket:link tag would be right for this - can i
write my own wicket:cssLink tag or can i somehow extend the behaviour of the
wicket:link tag?
* changing html content for inline styles or javascript:
in jsf i had this dynamic inline style definition: a{color:
${linkcolor}; }
in wicket i tried: a{color: ; }
and in the page: add( new Label("linkColor",
getLinkColor()).setRenderBodyOnly(true);
but the span does not get parsed, wicket says: "...you have added a
component in code but forgot to reference it in the markup..."; same when i
want to replace something in a javascript function, e.g. alert( 'Hello
whats the right way to do this?
thx in advance, uwe!
Re: migration from jsf to wicket
martin & john,
thank you very much for your ideas!
this helps me very much to make the next steps, i will post the results when
the integration is done!
bestregards, uwe!
On Thu, Jan 29, 2009 at 11:41 AM, Martin Makundi <
martin.maku...@koodaripalvelut.com> wrote:
> > 1) working with many attributes of an object
> > we have some pages where we access many attributes of an object, say we
> want
> > to show all 20 attributes of a person and all 10 attributes of
> > person.getAddress();
> > in the PersonPage.java i would have to add 30 label (or input)
> components,
> > 30 lines with nearly identical java code: add(new Label("firstName",
> > person.getName() );
> > isn't it tedious to always keep PersonDetails.java and PersonDetails.html
> > files in sync? in jsf/jsp the changes are only in the jsp/xhtml
>
> There are few options that come into my mind:
> 1. add(new Label(CONSTANT_FIRST_NAME, person.getName() ); // Now you
> can re-use your constant from WicketTests.
> 2. add(new Label(CONSTANT_FIRST_NAME, new PropertyModel(person,
> Person.NAME_CONSTANT) ); // Now you can re-use your Entity's NAME
> -constant from JPA/ORM/Hibernate queries.
> 3. use CompoundPropertyModels. Yes. You will have to sync the names in
> html and in Java. Maybe someone will develop a nice plugin that
> automates this in the future:
>
> http://cwiki.apache.org/WICKET/working-with-wicket-models.html#WorkingwithWicketmodels-CompoundPropertyModels
> http://cwiki.apache.org/WICKET/more-on-models.html
>
> > 2) page composition
> You can treat Title just as a Label. See tag and Wicket
> modularity:
> http://cwiki.apache.org/WICKET/wickets-xhtml-tags.html
> http://www.javalobby.org/java/forums/t60926.html
>
> http://cwiki.apache.org/WICKET/create-dynamic-markup-hierarchies-using-panels.html
>
> > 3) preview functionality
> > is this right: as soon as we use page composition and components, the
> > preview feature is gone; how do you experienced wicket users handle this?
> is
> > it usable in a prototype phase - before the html prototype is decomposed
> > into composition parts and components?
>
> The runtime page hierarchy is ofcourse visible only at runtime, but
> you can preview each panel separately ofcourse (if it makes sense).
>
> > is there a resource on the web that helps with the task of migrating from
> > jsf to wicket?
>
> I would save the html files using a browser (if the html markup is not
> available separately) and just pick up from there, starting to add
> wicket:id's to the components of the page, one-by-one (in development
> & debug mode it is quite fast as you do not need to restart the jetty
> server after saved&compiled change).
>
> my 2 cents ;)
>
> **
> Martin
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
migration from jsf to wicket
we are on the way to migrate our old struts web app to something more
modern.
our first try was seam/jsf, but the performance of jsf was very
disappointing.
so now our plan is to use seam (as we like its component model and the
performance was quite good - after using @BypassInterceptors) with
wicket;
on the one hand we are very impressed by wicket's java-centric approach, on
the other hand we have a lack of understanding of how to achieve some basic
things with wicket, as our experience comes from jsp and jsf.
there are some problems that we didnt find an elegant solution for with
wicket, perhaps somebody can help us to understand the wicket way...
1) working with many attributes of an object
we have some pages where we access many attributes of an object, say we want
to show all 20 attributes of a person and all 10 attributes of
person.getAddress();
in the PersonPage.java i would have to add 30 label (or input) components,
30 lines with nearly identical java code: add(new Label("firstName",
person.getName() );
isn't it tedious to always keep PersonDetails.java and PersonDetails.html
files in sync? in jsf/jsp the changes are only in the jsp/xhtml
2) page composition
in tiles and facelet compositions the layout is separated in templates
(with navigation, sidebars, header, footers, ...) that decorate the concrete
pages (eg the personDetails page); its possible that the concrete page
(personDetail.xhtml) defines some content of the decoration, e.g. that the
window title of the template should be replaced with: "Details of ${
person.name}";
in the template i would write with tiles or
in facelets;
the content for windowTitle is defined in personDetails.xhtml or in the
tiles definition for the personDetails.jsp
3) preview functionality
is this right: as soon as we use page composition and components, the
preview feature is gone; how do you experienced wicket users handle this? is
it usable in a prototype phase - before the html prototype is decomposed
into composition parts and components?
is there a resource on the web that helps with the task of migrating from
jsf to wicket?
the only one i know is the seam-booking example with the two versions; a
migration guide could be a motivation for jsf users to try out wicket (and
find out thats it better... :-) .
thanx in advance, uwe!
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
