Re: Should/Could ServletWebRequest.isAjax be cached?
The profiler shows that for a (large) page, 40% of the effort (20
seconds per such particular page) goes into just parsing the tags and
does not seem to process any logic.
So, some streamlining might be in order there, even after this particular issue.
Jira issue created with attached profiler screenshot:
https://issues.apache.org/jira/browse/WICKET-1910
**
Martin
2008/11/1 Matej Knopp [EMAIL PROTECTED]:
Sure this is valid but i can't imagine why this would be a bottleneck.
Unless the webserver does something very weird while retrieving the
header.
-Matej
On Sat, Nov 1, 2008 at 6:01 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
looks good, please create a jira issue.
-igor
On Sat, Nov 1, 2008 at 5:11 AM, Martin Makundi
[EMAIL PROTECTED] wrote:
Hi!
I was profiling my Wicket application and noticed that Jetty's
getHeader method was hit quite often.
It turns out the ServletWebRequest.isAjax method is hit quite often by
each of the page elements (I am generating a large HTML report page).
Since the Servlet container may not have optimal design for processing
the getHeader method, I wonder if the ServletWebRequest.isAjax -method
could/should be cached within wicket.
I made the following modification to the ServletWebRequest.isAjax
method, and measured a notable increase in performance:
public boolean isAjax() {
if (ajax == null) {
ajax = false;
String ajaxHeader = httpServletRequest.getHeader(Wicket-Ajax);
if (Strings.isEmpty(ajaxHeader) == false)
{
try
{
ajax = Strings.isTrue(ajaxHeader);
}
catch (StringValueConversionException e)
{
// We are not interested in this exception but we log it anyway
log.debug(Couldn't convert the Wicket-Ajax header: +
ajaxHeader);
}
}
}
return ajax;
}
However, my question remains: is this a valid optimization or does it
break the Wicket framework? Should it somehow be incorporated in the
next releases?
**
Martin
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
How can I format feedback messages?
Hi! How can I (centrally / per component) format the Numbers and Dates in feedback messages? I found some discussion about it, but no solution yet: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00736.html ** Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling runtime exceptions in ajax request
I'm interested in this subject too. Anyone? Daniel Stoch-2 wrote: Hi, In Wicket by default IRequestCycleProcessor.respond(RuntimeException, RequestCycle) method is called to handle runtime exceptions. In AbstractRequestCycleProcessor this method throws RestartResponseException (or RestartResponseAtInterceptPageException) and then the other page is shown (eg. ExceptionErrorPage or other page specified in RequestCycle.onRuntimeException()). In ajax requests I want to avoid loading another page when runtime exception is thrown. I want to show a proper exception message within the current page. I have prepared a small draft solution how to do this (by extending AjaxRequestTarget and WebRequestCycleProcessor classes), but firstly I want to ask you is it any standard way to handle runtime exception within ajax request, without rendering another page? -- Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Handling-runtime-exceptions-in-ajax-request-tp18927900p20289107.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]
Re: Different size of Modal Window in IE and Firefox
Ok, problem solved. I had old cookies with changed size placed in one browser. When I cleared cookies size of modal windows in both browsers are equal. Regards -- Tomasz Dziurko - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing borders with WicketTester
Sorry, but I dont get your point... What do you mean self contained (in terms of Wicket API) ? Im sure there is a lot of user created border components which contain a lot of surrounding markup and components and it is very desireble(at least for me :)) to be able to 'unit' test such components with Wicket tester, regardles (i.e with empty) to border body. Does method Im looking for was not provided because of technical problems ? If so what is the simplest way to test border components (surrounding markup and components) with i.e empty body ? Regards Daniel Lipski igor.vaynberg wrote: borders are not meant to be self-contained like panels. they are meant to be used within something that contains markup, eg page or panel. -igor On Fri, Oct 31, 2008 at 8:14 AM, dlipski [EMAIL PROTECTED] wrote: Hi Is it possible (if not why?) to test Border components in a way similar to testing Panels ? -WicketTester.startPanel(TestPanelSource) ? Its strange but I cant find corresponding method for Borders. Thanks in advance. Daniel Lipski -- View this message in context: http://www.nabble.com/testing-borders-with-WicketTester-tp20268028p20268028.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/testing-borders-with-WicketTester-tp20268028p20288374.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]
Re: testing borders with WicketTester
Are you sure you don't want to use markup inheritance rather than borders? On Sun, Nov 2, 2008 at 5:57 AM, Daniel Lipski [EMAIL PROTECTED] wrote: Sorry, but I dont get your point... What do you mean self contained (in terms of Wicket API) ? Im sure there is a lot of user created border components which contain a lot of surrounding markup and components and it is very desireble(at least for me :)) to be able to 'unit' test such components with Wicket tester, regardles (i.e with empty) to border body. Does method Im looking for was not provided because of technical problems ? If so what is the simplest way to test border components (surrounding markup and components) with i.e empty body ? Regards Daniel Lipski igor.vaynberg wrote: borders are not meant to be self-contained like panels. they are meant to be used within something that contains markup, eg page or panel. -igor On Fri, Oct 31, 2008 at 8:14 AM, dlipski [EMAIL PROTECTED] wrote: Hi Is it possible (if not why?) to test Border components in a way similar to testing Panels ? -WicketTester.startPanel(TestPanelSource) ? Its strange but I cant find corresponding method for Borders. Thanks in advance. Daniel Lipski -- View this message in context: http://www.nabble.com/testing-borders-with-WicketTester-tp20268028p20268028.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/testing-borders-with-WicketTester-tp20268028p20288374.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]
JavaScript Framework Dependencies
hi forgive me, if this topic is a dead horse already, but it really bugs me that this does not seem to be sorted out. i´m just wondering why there isn´t a project like org.wicketstuff.javascript.mootools/jquery/extjs/whatever the story: i was just implementing some mini behaviour using mootools when i found, that after packaging it nicely in a seperate project, it broke another mootools based behaviour used on a page that combined the two. no suprise there, as they use different versions of mootools. the obvious solution is: ripping the dependency out in a seperate project and make both use this one. (assuming backward compatibility is reliable) so, what do i learn from that? there should be *one single* source for mootools-header-contributions that any behaviour implementor is invited to use in order to prevent scripts form being loaded more than once on a single page (due to coming from different resources) and to give the user (or his maven or whatever he uses for dependency resolution) of these behaviours a chance of choosing the version. yes, i know... maintaining could be work, but it is bearable to at least have all major versions of the bigger JS toolkits bundled together with a simple class defining resources to use those things. to make it crystal clear: this is just about providing a single access point for using these scripts, not wrapping them with wicket components. bad idea? cu uwe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Refresh parent page from an iframe
Hi, I have a page that contains several iframes with some actions in each iframe. When I press on some of the actions I want the parent page to be updated (since the actions affect the whole parent page with the iframes). But every attempt to update the page is actually updating the iframe only. What actually happen is that the whole page get render again inside the iframe. I use setResponsePage(parent) within the iframe. Thats probably the problem but I don't know what else to use. I try to do as it written here:http://www.nabble.com/modal-window-navigation--td18551902.html but it does not work. Any idea's? Thanks in advance, Itay -- View this message in context: http://www.nabble.com/Refresh-parent-page-from-an-iframe-tp20290367p20290367.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]
Are there any open-source webapplications based on Wicket?
In PHP, many open-source applications exist, such as Drupal, PHPBB...and thousands of other scripts. So far I have not found a single Wicket-based website or project. Is there none so far or just hidden somewhere on the net ? -- View this message in context: http://www.nabble.com/Are-there-any-open-source-webapplications-based-on-Wicket--tp20290455p20290455.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]
Re: OnChangeAjaxBehavior receives only first input character
I fixed it. The problem is that the copmponent I want to update was outside the form. On Tue, Oct 28, 2008 at 3:51 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Hi Daniele Provide your code, java and html cutout, it's clearly not similar then it would work.. Daniele Dellafiore wrote: Hi all. I am using an OnChangeAjaxBehavior on a textField to filter contents of a table. My code is very similar to this example: http://www.wicket-library.com/wicket-examples/ajax/on-change-ajax-behavior The problem I have is that the first input character is received and I can get it in the onUpdate method of the Behavior. Then it stops sending event, the wicket ajax debug console confirm that nothing is sent anymore. If I remove and give the focus back to the field, I receive a new character, and only one again. Here is the debug console output for the first char I receive. INFO: focus removed from INFO: focus set on filter5 INFO: INFO: Initiating Ajax POST request on ?wicket:interface=:2:authorSearch:form:filter::IBehaviorListener:0:random=0.08630731350941423 INFO: Invoking pre-call handler(s)... INFO: Received ajax response (261 characters) INFO: ?xml version=1.0 encoding=UTF-8?ajax-responsecomponent id=authors6 ![CDATA[table id=authors6 thead tr class=headers thspanNome/span/th /tr /thead tbody /tbody /table]]/component/ajax-response INFO: Response parsed. Now invoking steps... INFO: Response processed successfully. INFO: Invoking post-call handler(s)... INFO: Calling focus on filter5 INFO: focus removed from filter5 -- -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] -- Daniele Dellafiore http://blog.ildella.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Tapestry to Wicket?
Hi Eelco, You are correct - right now my main worry is about development cost. Hardware cost is cheaper IMHO than having developers struggle with a hard framework and spending too much time trying to maintain and write code based around a hard framework. Honestly in our application (we have a roadmap for scalability) we are likely to get several hundred concurrent sessions per server with a few kb of state stored in the HTTPSession. Its not that much. What I was more concerned about was Page storage and storage that I can't control (for example, if I couldn't control IModel storage I would be concerned). We are unlikely to have spikes of traffic, but we are more likely to have dribs and drabs of users who potentially keep sessions open for perhaps minutes to hours. For our initial scaling the client will have an affinity to a specific server. We can control the number of users that we have on a server. We can then scale our servers horizontally if we hit a scaling issue on one of the servers. I'm starting not to worry about it too much. Honestly - I really face the same issues with Tapestry. What I don't face with Wicket is the development cost because it appears to be (I played with it yesterday) a very intelligent architecture. I was happy playing yesterday and even migrated our login page over very quickly. Of course I have to figure out how to handle my 'remember me' cookie and hit the database, but it all seems rather nice. Cheers, Graeme. Eelco Hillenius wrote: I have a complex table and many links on the page that are not book-markable. Will that be a problem in terms of too much session information? The default session store in Wicket saves history in some temp files and only holds the current page in memory (well, the current page of any page map in case you use more). Say that's a very heavy page, taking up to 100K. And say you run a VM with 1 GB of dedicated memory. You can support close to 10,000 concurrent sessions (close, because obviously, you'll use memory for other things than just sessions). Changes are that you run into bottlenecks with processors and database utilization long before you run out of memory for one box. The only kind of web sites I probably wouldn't recommend Wicket as used by default for are sites like Google, Yahoo and CNN etc, where you can have enormous spikes in traffic that are very short lived. But... the good news with Wicket then again is that you can build your app entirely using bookmarkable pages (even stateless if you want, so that you can avoid *any* memory usage) so that clustering will be easy and cheap. On top of that, you can plug in your own implementations of things like session store so that you can decide when/ how/ where state should be kept. You have to weigh the benefits of the stateful programming model against your technical requirements. But you can use Wicket for most use cases if you give it a bit of thought. Would it be conceptually easy for me to write Javascript/AJAX and hook them into Wicket in a simple way? Yeah, that's fairly simple. You can either write snippets that are used by components/ behaviors that integrate with our regular AJAX engine, or you can even plugin your own engine if you'd prefer that. Its all about cost. The funny thing is that in most discussions out there people focus on the cost of servers/ memory/ etc. While probably for most people - basically for anything that doesn't have the size of Google - development and maintenance cost is often the highest component. So a good development model makes sense. we have absolute faith that it will have a lot of users according to our business plan. May I ask what you think is a lot (say hits per second and concurrent sessions)? Thousands? Tens of thousands? Hundred of thousands? Even millions? If you're talking about really large numbers, you need to be aware of the choices you make in your app, not only for Wicket obviously, and test for scalability from the start. Though if you're talking about thousands up to maybe a few thousands, Wicket should be able to handle it fine without you having to worry about using stateful components. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Moving-from-Tapestry-to-Wicket--tp20254394p20291214.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]
Re: Refresh parent page from an iframe
There is an example Implementation of a file upload, that is contained in an iFrame ( http://www.demay-fr.net/blog/index.php/2007/12/07/93-simulate-ajax-file-upload-with-wicket). The Author wanted pretty much the same as you do: Alter the containing (parent) page. He uses a javascript call to the parent page. I'm not really sure if I can get all necessary steps together but here are some hints: 1) Add an AbstractDefaultAjaxBehavior to your parent page. Alter the getCallback method in a way that it makes a call to wicketAjaxGet and appends parameters to the query string to identify which iframe triggered the action. Take the query parameters from the current javascript scope. 2) Generate a method into the parent page that executes the getCallback script of the behavior and takes the parameters needed as function parameters. 3) append javascript to the submit button/whatever of the iframe that calls the javascript method in the parent page and pass the parameters that identify the calling iframe (maybe markup id?). 4) put java code that modifies your parent page into the AbstractDefaultAjaxBehavior's onResponse method and alter the page. That is the idea. Hope you can follow me. I'd advise you to take a closer look at the example by Monsieur Demay. Even though it contains some errors. There is a corrected version somewhere on the web. I'd say that there is no direct way using only java to solve your problem. But I've started using wicket 6 weeks ago so there might be a more clever answer :) Cheers Bert 2008/11/2 itayh [EMAIL PROTECTED] Hi, I have a page that contains several iframes with some actions in each iframe. When I press on some of the actions I want the parent page to be updated (since the actions affect the whole parent page with the iframes). But every attempt to update the page is actually updating the iframe only. What actually happen is that the whole page get render again inside the iframe. I use setResponsePage(parent) within the iframe. Thats probably the problem but I don't know what else to use. I try to do as it written here:http://www.nabble.com/modal-window-navigation--td18551902.html but it does not work. Any idea's? Thanks in advance, Itay -- View this message in context: http://www.nabble.com/Refresh-parent-page-from-an-iframe-tp20290367p20290367.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]
Re: Are there any open-source webapplications based on Wicket?
hippo, ehour, jtrac, artifactory, sakai to name a few. Martijn On Sun, Nov 2, 2008 at 8:51 AM, Toby78 [EMAIL PROTECTED] wrote: In PHP, many open-source applications exist, such as Drupal, PHPBB...and thousands of other scripts. So far I have not found a single Wicket-based website or project. Is there none so far or just hidden somewhere on the net ? -- View this message in context: http://www.nabble.com/Are-there-any-open-source-webapplications-based-on-Wicket--tp20290455p20290455.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] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaScript Framework Dependencies
Hi Uwe, this is exactly the reason why we have wicketstuff-prototype: http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-prototype IMHO we could use something similar for mootools. Sven Uwe Schäfer schrieb: hi forgive me, if this topic is a dead horse already, but it really bugs me that this does not seem to be sorted out. i´m just wondering why there isn´t a project like org.wicketstuff.javascript.mootools/jquery/extjs/whatever the story: i was just implementing some mini behaviour using mootools when i found, that after packaging it nicely in a seperate project, it broke another mootools based behaviour used on a page that combined the two. no suprise there, as they use different versions of mootools. the obvious solution is: ripping the dependency out in a seperate project and make both use this one. (assuming backward compatibility is reliable) so, what do i learn from that? there should be *one single* source for mootools-header-contributions that any behaviour implementor is invited to use in order to prevent scripts form being loaded more than once on a single page (due to coming from different resources) and to give the user (or his maven or whatever he uses for dependency resolution) of these behaviours a chance of choosing the version. yes, i know... maintaining could be work, but it is bearable to at least have all major versions of the bigger JS toolkits bundled together with a simple class defining resources to use those things. to make it crystal clear: this is just about providing a single access point for using these scripts, not wrapping them with wicket components. bad idea? cu uwe - 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]
Re: testing borders with WicketTester
self contained in that the page and panel has everything they need to render themselves. a border is meant to be embedded in a page or panel, not work independently. anyways, its really easy to create a generic panel to facilitate the testing of borders. -igor On Sun, Nov 2, 2008 at 2:57 AM, Daniel Lipski [EMAIL PROTECTED] wrote: Sorry, but I dont get your point... What do you mean self contained (in terms of Wicket API) ? Im sure there is a lot of user created border components which contain a lot of surrounding markup and components and it is very desireble(at least for me :)) to be able to 'unit' test such components with Wicket tester, regardles (i.e with empty) to border body. Does method Im looking for was not provided because of technical problems ? If so what is the simplest way to test border components (surrounding markup and components) with i.e empty body ? Regards Daniel Lipski igor.vaynberg wrote: borders are not meant to be self-contained like panels. they are meant to be used within something that contains markup, eg page or panel. -igor On Fri, Oct 31, 2008 at 8:14 AM, dlipski [EMAIL PROTECTED] wrote: Hi Is it possible (if not why?) to test Border components in a way similar to testing Panels ? -WicketTester.startPanel(TestPanelSource) ? Its strange but I cant find corresponding method for Borders. Thanks in advance. Daniel Lipski -- View this message in context: http://www.nabble.com/testing-borders-with-WicketTester-tp20268028p20268028.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/testing-borders-with-WicketTester-tp20268028p20288374.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]
Re: Are there any open-source webapplications based on Wicket?
http://cwiki.apache.org/WICKET/sites-using-wicket.html So far I have not found a single Wicket-based website or project. Is there none so far or just hidden somewhere on the net ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
example application for spring wicket hibernate
are there any examples for spring, wicket and hibernate ? -- View this message in context: http://www.nabble.com/example-application-for-spring-wicket-hibernate-tp20293119p20293119.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]
Re: JavaScript Framework Dependencies
On Sun, Nov 2, 2008 at 7:08 AM, Uwe Schäfer [EMAIL PROTECTED] wrote: i´m just wondering why there isn´t a project like org.wicketstuff.javascript.mootools/jquery/extjs/whatever why? because you havent built it yet. wicketstuff is open for participation, feel free. -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: example application for spring wicket hibernate
Phonebook: http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-phonebook . If you need NetBeans project for it just tell me, I have it somewhere on the disc Regards -- Tomasz Dziurko - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: example application for spring wicket hibernate
you may look at wicket iolite too, it's very usefull miro wrote: are there any examples for spring, wicket and hibernate ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaScript Framework Dependencies / Wicket Stuff commit access
Igor Vaynberg schrieb: i´m just wondering why there isn´t a project like org.wicketstuff.javascript.mootools/jquery/extjs/whatever why? because you havent built it yet. wicketstuff is open for participation, feel free. the answer i was hoping for ;) i´d like to ask for permission to commit org.wicketstuff.js.mootools project then and maybe some simple behaviours using it afterwards. sourceforge/teamcity/jira acount: uweschaefer cu uwe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaScript Framework Dependencies
Sven Meier schrieb: this is exactly the reason why we have wicketstuff-prototype: http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-prototype good to hear that. i´ll look into it thx uwe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaScript Framework Dependencies
afaik there are several projects in wicketstuff. at least for scriptaculous, jquery and mootools. no idea how good/extense these implementations are though. there is also wickext (code.google.com/p/wickext/ ) for jquery. francisco On Sun, Nov 2, 2008 at 8:51 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: On Sun, Nov 2, 2008 at 7:08 AM, Uwe Schäfer [EMAIL PROTECTED] wrote: i´m just wondering why there isn´t a project like org.wicketstuff.javascript.mootools/jquery/extjs/whatever why? because you havent built it yet. wicketstuff is open for participation, feel free. -igor - 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]
Broken pipe
Hi! I quite often suffer this exception.. anybody have similar experiences and know of a workaround? It crashes the jvm.. 2008-11-02 18:48:02,819 4[btpool0-4] ERROR TakpServlet - Faltal error, servlet service halted. org.mortbay.jetty.EofException at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:657) at org.mortbay.jetty.AbstractGenerator$Output.blockForOutput(AbstractGenerator.java:539) at org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:560) at org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:828) at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:617) at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:578) at org.apache.wicket.protocol.http.BufferedHttpServletResponse.writeTo(BufferedHttpServletResponse.java:552) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:341) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:124) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at wicket.quickstart.TakpServlet.service(TakpServlet.java:58) 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.headerComplete(HttpConnection.java:751) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500) 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) Caused by: java.io.IOException: Broken pipe at sun.nio.ch.FileDispatcher.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104) at sun.nio.ch.IOUtil.write(IOUtil.java:60) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334) at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:165) at org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:192) at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:590) ... 28 more # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2b2290b73360, pid=22478, tid=1082333536 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b12 mixed mode linux-amd64) # Problematic frame: # V [libjvm.so+0x4d3360] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x2aaabe6da800): JavaThread CompilerThread1 daemon [_thre ad_in_native, id=22489, stack(0x40731000,0x40832000)] Current CompileTask: C2:1729 org.apache.wicket.extensions.yui.calendar.DatePicker.renderHead(Lor g/apache/wicket/markup/html/IHeaderResponse;)V (706 bytes) siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x000 0002c Registers: RAX=0x2aaac6a2d7b8, RBX=0x066b, RCX=0x2aaac4e65370, RDX=0x00 08 RSP=0x4082dca8, RBP=0x4082def0, RSI=0x2aaac7500020, RDI=0x00 00 R8 =0x3053, R9 =0x2aaac6a2d7e8, R10=0x2aaac6c74e20, R11=0x00 002aaac74a5700 R12=0x4082eb78, R13=0x008d, R14=0x, R15=0x00 002aaac71992c0 RIP=0x2b2290b73360, EFL=0x00010202, CSGSFS=0xe033, ERR=0 x0004 TRAPNO=0x000e Top of Stack: (sp=0x4082dca8) 0x4082dca8: 2b2290bdac88 2aaa0001 0x4082dcb8: 2aaac62dff00 4082de60 0x4082dcc8: 0080 4082dde0
Re: JavaScript Framework Dependencies / Wicket Stuff commit access
you have svn. nino can set you up with the rest soon. -igor On Sun, Nov 2, 2008 at 1:33 PM, Uwe Schäfer [EMAIL PROTECTED] wrote: Igor Vaynberg schrieb: i´m just wondering why there isn´t a project like org.wicketstuff.javascript.mootools/jquery/extjs/whatever why? because you havent built it yet. wicketstuff is open for participation, feel free. the answer i was hoping for ;) i´d like to ask for permission to commit org.wicketstuff.js.mootools project then and maybe some simple behaviours using it afterwards. sourceforge/teamcity/jira acount: uweschaefer cu uwe - 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]
Re: Session destruction due to timeout...
Mendeleev wrote: I passed the application key and it worked. Thanks a lot for the help. Would you be able to post your solution. I am trying to solve the same problem. Right now I am using the solution posted on this thread by Nino. Do you have an alternate way of solving this problem without having to worry about issues when clustering? Johan Compagner wrote: no you cant and Application.get() will never work then because the auto destruct of a container doesnt do that in a request ofcourse but just somewhere on some thread. if you need an application object you could try: Application.get(String applicationKey) The session object is gone so you cant access it anymore. On Wed, Oct 15, 2008 at 10:40 AM, Mendeleev [EMAIL PROTECTED] wrote: I need to add functionality to my Wicket application that allows me to record in the MySQL database the exact time a user logs out of the application. This includes recording the time the session is destroyed by the web container due to user inactivity. I tried: 1. An implementation of HttpSessionListener 2. Extending the HttpSessionStore class 3. WebApplication.sessionDestroyed(String sessionid) 4. An implementation of HttpSessionBindingListener All of these do not work in my case, because the methods are called AFTER the session is already destroyed. At that time, the hibernate session that connects to the database, does not exist anymore. I cannot reopen it, because the Application.get() method returns null at this time. My question is: is there any way that I can record the destruction right before it happens? Is there some sort of a listener I can implement? If not, how is the wicket application notified that the user navigates away from the page, starting a period of inactivity? If there is a way I can register that happening, I can solve the problem by adding a timer. Thanks, Drago -- View this message in context: http://www.nabble.com/Session-destruction-due-to-timeout...-tp19989230p19989230.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] -- View this message in context: http://www.nabble.com/Session-destruction-due-to-timeout...-tp19989230p20296278.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]
Re: Testing + IFrame
On Fri, 31 Oct 2008, Bert van Heukelom wrote: I want to test an ajax upload component that uses an IFrame. I have difficulties when trying to access Components via their path that are contained in the IFrame. I manage to a reference of the Iframe but can not find a path-string that accesses a component (namly a form) within the Iframe. Try doing wicketTester.debugComponentTrees() (or debugging the exact hierarchy by yourself). FormTester f = wicketTester.newFormTester(path:to:my:iframe:and:to:its:inner:form); Long component paths like this are a bit problematic anyway. You could try digging your Form up with a visitor to make it less dependent on the path. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should/Could ServletWebRequest.isAjax be cached?
On Sun, 02 Nov 2008, Martin Makundi wrote: The profiler shows that for a (large) page, 40% of the effort (20 seconds per such particular page) goes into just parsing the tags and does not seem to process any logic. So, some streamlining might be in order there, even after this particular issue. Do you have a lot of Ajax updates of small components without their own markup? If that is the case, then this issue https://issues.apache.org/jira/browse/WICKET-1857 might be hitting you as well and it would be interesting to see if your problem still occurs on trunk (or 1.4-RC1). The actual parsing results should be cached by IMarkupCache as far as I know, so if the parsing is really the issue you could try finding out why is the cache not working (and/or provide a reproduceable test case in a quickstart). Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should/Could ServletWebRequest.isAjax be cached?
So, some streamlining might be in order there, even after this particular issue. Do you have a lot of Ajax updates of small components without their own markup? https://issues.apache.org/jira/browse/WICKET-1857 might be hitting you as well and it would be interesting to see if your problem still occurs on trunk (or 1.4-RC1). Not really, I have large chunks (containers.. actually a ListView...). I had a look at the debug output and there is one DEBUG - MarkupCache- Markup not found: org.apache.wicket.markup.html.form.Formfi_FIhtml and some DEBUG - ResourceStreamLocator - Attempting to locate resource 'org/apache/wicket/markup/html/form/Form_fi_FI.html' on or similar Most of the lines in the debug log consist of: DEBUG - MarkupContainer- Rendering raw markup and DEBUG - Component - Begin render [MarkupContainer [Component id =xx The actual parsing results should be cached by IMarkupCache as far as I know, so if the parsing is really the issue you could try finding out why is the cache not working (and/or provide a reproduceable test case in a quickstart). Can you be more specific about this? In what context should the parsing results be cached? You could try ajax-updating a large web page, say having a table with 2000+ rows, and profile it. Do the results look ok for you? I will have a look, but I am not yet very familiar with Wicket internals... the 'what should be''s and nots ** Martin -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - 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]
Re: Moving from Tapestry to Wicket?
I can vouch for the fact that Wicket's learning curve, compared to Tapestry's, is MUCH, MUCH easier for an object-oriented Java programmer. We used Tapestry at my last place of employment, and I hated it. When I left, I chose Wicket, and for the past several years have been enjoying UI development for the first time in my web app career. You can get up and running in Wicket very quickly, and can really generate some apps quickly. The biggest thing is to make sure you have a solid understanding of how to effectively use models before you begin a project - or you'll kick yourself later. I'm sure you'll enjoy your Wicket development experience - and the list is very active and friendly - let us know if you need any help along the way. -- Jeremy Thomerson http://www.wickettraining.com On Sun, Nov 2, 2008 at 10:23 AM, GK1971 [EMAIL PROTECTED] wrote: Hi Eelco, You are correct - right now my main worry is about development cost. Hardware cost is cheaper IMHO than having developers struggle with a hard framework and spending too much time trying to maintain and write code based around a hard framework. Honestly in our application (we have a roadmap for scalability) we are likely to get several hundred concurrent sessions per server with a few kb of state stored in the HTTPSession. Its not that much. What I was more concerned about was Page storage and storage that I can't control (for example, if I couldn't control IModel storage I would be concerned). We are unlikely to have spikes of traffic, but we are more likely to have dribs and drabs of users who potentially keep sessions open for perhaps minutes to hours. For our initial scaling the client will have an affinity to a specific server. We can control the number of users that we have on a server. We can then scale our servers horizontally if we hit a scaling issue on one of the servers. I'm starting not to worry about it too much. Honestly - I really face the same issues with Tapestry. What I don't face with Wicket is the development cost because it appears to be (I played with it yesterday) a very intelligent architecture. I was happy playing yesterday and even migrated our login page over very quickly. Of course I have to figure out how to handle my 'remember me' cookie and hit the database, but it all seems rather nice. Cheers, Graeme. Eelco Hillenius wrote: I have a complex table and many links on the page that are not book-markable. Will that be a problem in terms of too much session information? The default session store in Wicket saves history in some temp files and only holds the current page in memory (well, the current page of any page map in case you use more). Say that's a very heavy page, taking up to 100K. And say you run a VM with 1 GB of dedicated memory. You can support close to 10,000 concurrent sessions (close, because obviously, you'll use memory for other things than just sessions). Changes are that you run into bottlenecks with processors and database utilization long before you run out of memory for one box. The only kind of web sites I probably wouldn't recommend Wicket as used by default for are sites like Google, Yahoo and CNN etc, where you can have enormous spikes in traffic that are very short lived. But... the good news with Wicket then again is that you can build your app entirely using bookmarkable pages (even stateless if you want, so that you can avoid *any* memory usage) so that clustering will be easy and cheap. On top of that, you can plug in your own implementations of things like session store so that you can decide when/ how/ where state should be kept. You have to weigh the benefits of the stateful programming model against your technical requirements. But you can use Wicket for most use cases if you give it a bit of thought. Would it be conceptually easy for me to write Javascript/AJAX and hook them into Wicket in a simple way? Yeah, that's fairly simple. You can either write snippets that are used by components/ behaviors that integrate with our regular AJAX engine, or you can even plugin your own engine if you'd prefer that. Its all about cost. The funny thing is that in most discussions out there people focus on the cost of servers/ memory/ etc. While probably for most people - basically for anything that doesn't have the size of Google - development and maintenance cost is often the highest component. So a good development model makes sense. we have absolute faith that it will have a lot of users according to our business plan. May I ask what you think is a lot (say hits per second and concurrent sessions)? Thousands? Tens of thousands? Hundred of thousands? Even millions? If you're talking about really large numbers, you need to be aware of the choices you make in your app, not only for Wicket obviously, and test for scalability from the start. Though if you're
Re: Broken pipe
My latest application also runs on 64bit (Ubuntu 8.04). The JVM crashed regularly (in the compiler) until I upgraded to Java 6u10. Regards, Erik. Martin Makundi wrote: Hi! I quite often suffer this exception.. anybody have similar experiences and know of a workaround? It crashes the jvm.. 2008-11-02 18:48:02,819 4[btpool0-4] ERROR TakpServlet - Faltal error, servlet service halted. org.mortbay.jetty.EofException at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:657) at org.mortbay.jetty.AbstractGenerator$Output.blockForOutput(AbstractGenerator.java:539) at org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:560) at org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:828) at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:617) at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:578) at org.apache.wicket.protocol.http.BufferedHttpServletResponse.writeTo(BufferedHttpServletResponse.java:552) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:341) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:124) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at wicket.quickstart.TakpServlet.service(TakpServlet.java:58) 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.headerComplete(HttpConnection.java:751) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500) 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) Caused by: java.io.IOException: Broken pipe at sun.nio.ch.FileDispatcher.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104) at sun.nio.ch.IOUtil.write(IOUtil.java:60) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334) at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:165) at org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:192) at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:590) ... 28 more # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2b2290b73360, pid=22478, tid=1082333536 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b12 mixed mode linux-amd64) # Problematic frame: # V [libjvm.so+0x4d3360] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x2aaabe6da800): JavaThread CompilerThread1 daemon [_thre ad_in_native, id=22489, stack(0x40731000,0x40832000)] Current CompileTask: C2:1729 org.apache.wicket.extensions.yui.calendar.DatePicker.renderHead(Lor g/apache/wicket/markup/html/IHeaderResponse;)V (706 bytes) siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x000 0002c Registers: RAX=0x2aaac6a2d7b8, RBX=0x066b, RCX=0x2aaac4e65370, RDX=0x00 08 RSP=0x4082dca8, RBP=0x4082def0, RSI=0x2aaac7500020, RDI=0x00 00 R8 =0x3053, R9 =0x2aaac6a2d7e8, R10=0x2aaac6c74e20, R11=0x00 002aaac74a5700 R12=0x4082eb78, R13=0x008d, R14=0x, R15=0x00 002aaac71992c0 RIP=0x2b2290b73360, EFL=0x00010202, CSGSFS=0xe033, ERR=0 x0004 TRAPNO=0x000e Top of Stack:
Re: Broken pipe
What is your exact version, mine is: java version 1.6.0_10-beta Java(TM) SE Runtime Environment (build 1.6.0_10-beta-b25) Java HotSpot(TM) 64-Bit Server VM (build 11.0-b12, mixed mode) Linux version 2.6.18-xenU (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) ** Martin 2008/11/3 Erik van Oosten [EMAIL PROTECTED]: My latest application also runs on 64bit (Ubuntu 8.04). The JVM crashed regularly (in the compiler) until I upgraded to Java 6u10. Regards, Erik. Martin Makundi wrote: Hi! I quite often suffer this exception.. anybody have similar experiences and know of a workaround? It crashes the jvm.. 2008-11-02 18:48:02,819 4[btpool0-4] ERROR TakpServlet - Faltal error, servlet service halted. org.mortbay.jetty.EofException at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:657) at org.mortbay.jetty.AbstractGenerator$Output.blockForOutput(AbstractGenerator.java:539) at org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:560) at org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:828) at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:617) at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:578) at org.apache.wicket.protocol.http.BufferedHttpServletResponse.writeTo(BufferedHttpServletResponse.java:552) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:341) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:124) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at wicket.quickstart.TakpServlet.service(TakpServlet.java:58) 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.headerComplete(HttpConnection.java:751) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500) 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) Caused by: java.io.IOException: Broken pipe at sun.nio.ch.FileDispatcher.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104) at sun.nio.ch.IOUtil.write(IOUtil.java:60) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334) at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:165) at org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:192) at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:590) ... 28 more # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2b2290b73360, pid=22478, tid=1082333536 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b12 mixed mode linux-amd64) # Problematic frame: # V [libjvm.so+0x4d3360] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x2aaabe6da800): JavaThread CompilerThread1 daemon [_thre ad_in_native, id=22489, stack(0x40731000,0x40832000)] Current CompileTask: C2:1729 org.apache.wicket.extensions.yui.calendar.DatePicker.renderHead(Lor g/apache/wicket/markup/html/IHeaderResponse;)V (706 bytes) siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x000 0002c Registers: RAX=0x2aaac6a2d7b8, RBX=0x066b, RCX=0x2aaac4e65370, RDX=0x00 08 RSP=0x4082dca8, RBP=0x4082def0, RSI=0x2aaac7500020,
Re: Broken pipe
I have: $ java -version java version 1.6.0_10-rc Java(TM) SE Runtime Environment (build 1.6.0_10-rc-b28) Java HotSpot(TM) 64-Bit Server VM (build 11.0-b15, mixed mode) $ uname -a Linux server #1 SMP Wed May 28 20:21:05 UTC 2008 x86_64 GNU/Linux Regards, Erik. Martin Makundi wrote: What is your exact version, mine is: java version 1.6.0_10-beta Java(TM) SE Runtime Environment (build 1.6.0_10-beta-b25) Java HotSpot(TM) 64-Bit Server VM (build 11.0-b12, mixed mode) Linux version 2.6.18-xenU (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) ** Martin 2008/11/3 Erik van Oosten [EMAIL PROTECTED]: My latest application also runs on 64bit (Ubuntu 8.04). The JVM crashed regularly (in the compiler) until I upgraded to Java 6u10. Regards, Erik. Martin Makundi wrote: Hi! I quite often suffer this exception.. anybody have similar experiences and know of a workaround? It crashes the jvm.. 2008-11-02 18:48:02,819 4[btpool0-4] ERROR TakpServlet - Faltal error, servlet service halted. org.mortbay.jetty.EofException at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:657) at org.mortbay.jetty.AbstractGenerator$Output.blockForOutput(AbstractGenerator.java:539) at org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:560) at org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:828) at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:617) at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:578) at org.apache.wicket.protocol.http.BufferedHttpServletResponse.writeTo(BufferedHttpServletResponse.java:552) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:341) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:124) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at wicket.quickstart.TakpServlet.service(TakpServlet.java:58) 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.headerComplete(HttpConnection.java:751) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500) 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) Caused by: java.io.IOException: Broken pipe at sun.nio.ch.FileDispatcher.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104) at sun.nio.ch.IOUtil.write(IOUtil.java:60) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334) at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:165) at org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:192) at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:590) ... 28 more # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2b2290b73360, pid=22478, tid=1082333536 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b12 mixed mode linux-amd64) # Problematic frame: # V [libjvm.so+0x4d3360] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x2aaabe6da800): JavaThread CompilerThread1 daemon [_thre ad_in_native, id=22489, stack(0x40731000,0x40832000)] Current CompileTask: C2:1729 org.apache.wicket.extensions.yui.calendar.DatePicker.renderHead(Lor g/apache/wicket/markup/html/IHeaderResponse;)V (706 bytes) siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR),
Re: testing borders with WicketTester
No, I think you misunderstood me, when I wrote about empty body I was thinking about testing, I know that border without its body works like panel and shouldnt be used in such case. I was writing about borders which have bodies, but during testing I was interested in testing such borders with some 'stub' (ie empty) body. jwcarman wrote: Are you sure you don't want to use markup inheritance rather than borders? On Sun, Nov 2, 2008 at 5:57 AM, Daniel Lipski [EMAIL PROTECTED] wrote: Sorry, but I dont get your point... What do you mean self contained (in terms of Wicket API) ? Im sure there is a lot of user created border components which contain a lot of surrounding markup and components and it is very desireble(at least for me :)) to be able to 'unit' test such components with Wicket tester, regardles (i.e with empty) to border body. Does method Im looking for was not provided because of technical problems ? If so what is the simplest way to test border components (surrounding markup and components) with i.e empty body ? Regards Daniel Lipski igor.vaynberg wrote: borders are not meant to be self-contained like panels. they are meant to be used within something that contains markup, eg page or panel. -igor On Fri, Oct 31, 2008 at 8:14 AM, dlipski [EMAIL PROTECTED] wrote: Hi Is it possible (if not why?) to test Border components in a way similar to testing Panels ? -WicketTester.startPanel(TestPanelSource) ? Its strange but I cant find corresponding method for Borders. Thanks in advance. Daniel Lipski -- View this message in context: http://www.nabble.com/testing-borders-with-WicketTester-tp20268028p20268028.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/testing-borders-with-WicketTester-tp20268028p20288374.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/testing-borders-with-WicketTester-tp20268028p20298317.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]
