manage page ids in performance test loop
Hi community, I am doing performance tests (Jmeter) on a wicket application and having some troubles with the page version id. As I said I am using Jmeter and sending HTTP requests to the server with many users simultaneously. Example : myapp:8080/client/wicket/page?3-1.IBehaviorListener.0-form-createSomething-r-3-w-i-headerLabel-link It something like this : 1. Login : page id 0 2. Do operation 1 : page id 1 3. Do operation 2 : page id 2 4. Do operation 3 : page id 2 5. Logout : page id 2 It works fine for one run but I want of course to build in a loop for the operations (2-4). So since the user is not logged out the page version continuously increment. My problem is that I can not request source changes here. This part of the application is managed by another team and is complicated and time consuming to get a CR there and it will come with some new version 1-2 months from now. And the question: does someone has an experience with managing this id in such tests ? Is there some way to get the page version dynamically from somewhere (previews page ?) or ignore it completely ? I can try calculating it somehow but it will be test structure dependent and for every test change I must change also this calculation algorithm, so it is possible maybe but is ugly. Thanks everyone in advance. Regards tsv -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/manage-page-ids-in-performance-test-loop-tp4653174.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JSON response in wicket = 6.0.0
Hello Ernesto,
I sometimes get confused myself. ;-) I think that I don't understand
well this piece of code:
@Override
public final void onRequest()
{
WebApplication app =
(WebApplication)getComponent().getApplication();
AjaxRequestTarget target =
app.newAjaxRequestTarget(getComponent().getPage());
RequestCycle requestCycle = RequestCycle.get();
requestCycle.scheduleRequestHandlerAfterCurrent(target);
respond(target);
}
Because the AjaxRequestTarget is really a handler like
TextRequestHandler but I don't know the
call machanism.
What does the requestCycle.scheduleRequestHandlerAfterCurrent(target);
here and when used
with a TextRequestHandler. What's the difference?
Is there any way where this mechanism is explained?
Thank you a lot!
El sáb, 20-10-2012 a las 18:31 +0200, Ernesto Reinaldo Barreiro
escribió:
or your question is why this works?
On Sat, Oct 20, 2012 at 6:18 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Gonzalo,
You want to use AbstractDefaultAjaxBehavior as context to serve some
JSON? Then what you do is
add(behavior = new AbstractDefaultAjaxBehavior() {
@Override
protected void respond(AjaxRequestTarget target) {
TextRequestHandler handler = new TextRequestHandler(...);
RequestCycle.get().scheduleRequestHandlerAfterCurrent(handler);
}
});
then use use behavior.getCallbackUrl() to generate the URL you need to use
on client side to retrieve that JSON.
On Sat, Oct 20, 2012 at 5:57 PM, Gonzalo Aguilar Delgado
gagui...@aguilardelgado.com wrote:
Hello again,
Sorry. I was thinking about extending AbstractAjaxBehavior directly. It
seems to have cleaner code but I loss some functionality.
Could it be right?
And doing like you said. The getRequestHandler(); returns your
TextRequestHandler. Do I need the stuff inside
AbstractDefaultAjaxBehavior?
Functions like updateAjaxAttributes, renderAjaxAttributes,
appendListenerHandler, getCallbackFunction and so on, does not seem
useful for me now.
public final void onRequest()
{
// WebApplication app =
(WebApplication)getComponent().getApplication();
// AjaxRequestTarget target =
app.newAjaxRequestTarget(getComponent().getPage());
//
// RequestCycle requestCycle = RequestCycle.get();
// requestCycle.scheduleRequestHandlerAfterCurrent(target);
//
// respond(target);
IRequestHandler handler = getRequestHandler();
if(handler!=null)
RequestCycle.get().scheduleRequestHandlerAfterCurrent(handler);
}
El sáb, 20-10-2012 a las 16:08 +0200, Ernesto Reinaldo Barreiro
escribió:
on the respond method of your AbstractDefaultAjaxBehavior
On Sat, Oct 20, 2012 at 4:07 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Try the following
TextRequestHandler textRequestHandler = new
TextRequestHandler(application/json, UTF-8, Your JSON HERE);
RequestCycle.get().scheduleRequestHandlerAfterCurrent(textRequestHandler);
On Sat, Oct 20, 2012 at 4:00 PM, Gonzalo Aguilar Delgado
gagui...@aguilardelgado.com wrote:
Hello,
I was looking to some code and googling around but cannot find a
suitable solution for my problem.
I have an AbstractDefaultAjaxBehavior that I'm implemented the
function
respond(AjaxRequestTarget target) like this
---
@Override
protected void respond(AjaxRequestTarget target) {
JsonChoiceRendererT jsonRenderer = new
JsonChoiceRendererT(getChoices());
target.appendJavaScript(jsonRenderer.renderJsonArray(getComponent(),
getRenderer()));
}
---
But this is not a JSON response when it is called from javascript. I
want to respond with an application/json response.
I saw something like:
RequestCycle requestCycle = RequestCycle.get();
requestCycle.getResponse().setCharacterEncoding(UTF-8);
requestCycle.getResponse().setContentType(application/json;);
But it means that I have to override the final void onRequest() of
the
AbstractAjaxBehavior class, but this is final so I cannot.
What's the best way to do it with newer versions of wicket?
Thank you a lot in advance.
--
Regards - Ernesto Reinaldo Barreiro
Antilia Soft
http://antiliasoft.com
--
Regards - Ernesto Reinaldo Barreiro
Antilia Soft
http://antiliasoft.com
Re: JSON response in wicket = 6.0.0
Hi,
On Sun, Oct 21, 2012 at 10:57 AM, Gonzalo Aguilar Delgado
gagui...@aguilardelgado.com wrote:
Hello Ernesto,
I sometimes get confused myself. ;-) I think that I don't understand
well this piece of code:
@Override
public final void onRequest()
{
WebApplication app =
(WebApplication)getComponent().getApplication();
AjaxRequestTarget target =
app.newAjaxRequestTarget(getComponent().getPage());
RequestCycle requestCycle = RequestCycle.get();
requestCycle.scheduleRequestHandlerAfterCurrent(target);
respond(target);
}
AJAX requests are handled int two steps (please Martin and/or other core
developers correct me if I'm saying something wrong;-). First is is
executed ListenerInterfaceRequestHandler (which delegates
on IBehaviorListener#onRequest). So, there you a new request handler is
scheduled after current, so once wicket finishes processing current request
handler it will start processing the new scheduled request handler (that
will produce the AJAX output). This technique is used in many places on the
framework, Eg. DownloadLink#click()
public void onClick()
{
final File file = getModelObject();
if (file == null)
{
throw new IllegalStateException(getClass().getName() +
failed to retrieve a File object from model);
}
String fileName = fileNameModel != null ? fileNameModel.getObject() : null;
if (Strings.isEmpty(fileName))
{
fileName = file.getName();
}
fileName = UrlEncoder.QUERY_INSTANCE.encode(fileName,
getRequest().getCharset());
IResourceStream resourceStream = new FileResourceStream(
new org.apache.wicket.util.file.File(file));
getRequestCycle().scheduleRequestHandlerAfterCurrent(
new ResourceStreamRequestHandler(resourceStream)
{
@Override
public void respond(IRequestCycle requestCycle)
{
super.respond(requestCycle);
if (deleteAfter)
{
Files.remove(file);
}
}
}.setFileName(fileName)
.setContentDisposition(ContentDisposition.ATTACHMENT)
.setCacheDuration(cacheDuration));
}
Because the AjaxRequestTarget is really a handler like
TextRequestHandler but I don't know the
call machanism.
Look at the code RequestCycle#processRequestAndDetach and the calls it
makes.
What does the requestCycle.scheduleRequestHandlerAfterCurrent(target);
here and when used
with a TextRequestHandler. What's the difference?
There is no difference, you tell wicket that after current handler it
should discard the results and execute next handler. In your case instead
of returning an AJAX response return some text (JSON) response.
Is there any way where this mechanism is explained?
I don't know if Martin or other core developers explain this somewhere?
Thank you a lot!
You are welcome:-)
--
Regards - Ernesto Reinaldo Barreiro
Antilia Soft
http://antiliasoft.com
RE: Regression when using wicket:enclosure with non wicket namespace in 6.0
This bug seems to be a much more fundamental regression. It seems any page that specifies its own namespace fails - regardless of whether it has an enclosure or not. JIRA issue raised and QuickStart provided here: https://issues.apache.org/jira/browse/WICKET-4829 Regards, Chris -Original Message- From: Chris Colman [mailto:chr...@stepaheadsoftware.com] Sent: Sunday, 21 October 2012 2:38 AM To: users@wicket.apache.org Subject: Regression when using wicket:enclosure with non wicket namespace in 6.0 We have a panel with an enclosure that worked fine in 1.5 but now fails in 6.0 The page uses a non wicket namespace: i.e. instead of using wicket: ... everywhere it uses, for example mynamespace: ... and adds xmlns:mynamespace to the html tag to declare the non standard namespace. If we remove the namespace declaration from the html tag and rename all the mynamespace: tags to wicket: then the enclosure works fine. I remember a similar problem happened earlier in 1.5 that was caused by some Wicket code hardcoding the namespace to be 'wicket' instead of checking the namespace declared for each individual markup file. This problem was eventually fixed in 1.5. Here is a link to that issue: https://issues.apache.org/jira/browse/WICKET-4330 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Released wicket-source for Wicket 6
Wicket-Source is now compatible with Wicket 6. dependency groupIdnet.ftlines.wicket-source/groupId artifactIdwicket-source/artifactId version6.0.0.8/version /dependency Wicket-Source lets you click through from the rendered web page back to the exact line of Wicket source code that produced it. For an introduction and screenshots, here's the prior announcement. https://www.42lines.net/2012/01/31/announcing-wicket-source/ It is available for Wicket 1.4, 1.5, and 6.x. Browser plugins are available for Firefox and Chrome. Eclipse and IntelliJ are supported for opening Java files. Issues/bugs can be reported here: https://github.com/42Lines/wicket-source/issues
